Redis on the Open Internet: What 3.1 Million Exposed Service Banners Reveal

1. Introduction: The Risk of Unauthenticated Databases

Redis is one of the most widely deployed in-memory data stores on the internet. It powers caching layers, session stores, message queues, and real-time analytics pipelines for organizations of every size. Its default posture, however, was never designed with direct internet exposure in mind: out of the box, Redis historically shipped with no authentication enabled, no TLS, and a binding configuration intended for use on trusted internal networks.

When a Redis instance is reachable from the public internet without access controls, the consequences are well documented. An unauthenticated attacker who can speak the Redis protocol can read and write keys, and in many configurations can achieve further impact — for example, by abusing CONFIG SET dir and CONFIG SET dbfilename to write files to disk, or by exploiting known vulnerabilities such as the CVE-2022-0543 Lua sandbox escape that affected Debian-packaged Redis builds. The outcome of such actions has historically ranged from data theft to remote code execution.

But this analysis insists on an important epistemic distinction: a host that responds with a Redis banner on port 6379 is an observed exposed service. It is not, by that fact alone, a confirmed vulnerable or compromised system. The distinction between exposure and compromise is the central theme of this article. What a large-scale measurement can tell us is the size and shape of the attack surface — where Redis is reachable, on which networks, and in which sectors — and that surface, as we will see, is enormous.

2. Methodology: Defining the ZoomEye Query Parameters

This analysis is based on a single ZoomEye query executed against the platform's global index of internet-facing hosts.

The query used was:

service="redis" && port="6379"

This query combines two filters:

• service="redis" — matches hosts whose service banner has been classified as Redis by ZoomEye's fingerprinting engine. Classification is based on observed protocol responses, not merely on port assignment.
• port="6379" — restricts results to the IANA-registered default Redis port, filtering out Redis instances relocated to non-standard ports (which our query therefore undercounts).

The query returned 3177387 matching hosts on 2026-09-20. The unit of measurement is matching hosts — that is, distinct IP addresses in the ZoomEye index whose banners matched the Redis fingerprint on port 6379 at or near the time of collection.

A note on interpretation: 3177387 is a lower-bound snapshot of the exposed surface at a point in time, not a permanent count. Redis instances on non-default ports, IPv6-only deployments, hosts behind firewalls that block ZoomEye's probes, and services that were temporarily down during scanning are all absent from this figure. Conversely, as discussed in Section 5, banner matches can also include false positives. The number should be read as a defensible, reproducible measurement of a specific query's result on a specific date — nothing more, and nothing less.

3. Global Distribution Analysis of Exposed Instances

Nearly 3.18 million hosts answering the Redis protocol on port 6379 is a striking figure, and its distribution across networks and geographies matters as much as its size.

The first observation is that exposure is not randomly distributed. In analyses of internet-wide scans of this kind, Redis exposure consistently clusters in a small number of countries and autonomous systems, with cloud and hosting providers contributing a disproportionate share. This is not surprising: Redis is the default choice for caching and session storage in cloud-deployed web applications, and cloud instances are provisioned so quickly that configuration drift — a firewall rule opened "temporarily," a bind directive changed for a staging test and never reverted — accumulates rapidly.

The second observation is that exposure on the default port is itself a signal of weak operational hygiene. Security-conscious deployments almost universally bind Redis to 127.0.0.1 or a private interface, or at minimum relocate the service. An instance that is both on the default port and publicly reachable suggests either a deliberate (and risky) architectural choice or, more commonly, an unmanaged default configuration. ZoomEye's faceted search allows analysts to break the 3177387 matching hosts down by country, ASN, and banner attributes, turning a single aggregate number into an actionable map of where misconfiguration concentrates.

A third observation concerns temporal dynamics. Exposure counts of this size are not static. New instances appear as developers launch services; old ones disappear as servers are decommissioned. Tracking the query over time — which ZoomEye's historical index supports — reveals whether an organization's exposure is growing, shrinking, or oscillating in response to operational practices.

4. Case Study: Identifying High-Risk Sectors

Aggregate counts answer "how many"; sector-level analysis answers "who," which is often the more consequential question for risk prioritization.

By intersecting the base query with additional ZoomEye filters — such as banner content, organization fields, or reverse-DNS attributes — analysts can segment the exposed population. Sectors that repeatedly emerge in this kind of analysis include:

• Hosting and cloud infrastructure, where Redis exposure tends to be a byproduct of rapid provisioning and multi-tenancy, and where a single misconfigured security group can expose thousands of customer instances.
• Small and mid-sized e-commerce and web application operators, for whom Redis is a standard dependency (sessions, cart state, rate-limiting counters) and for whom security hardening is rarely a specialist function.
• Education and research networks, where flat internal networks and legacy permissive firewall policies are common, and where internal-only assumptions about service placement persist long after networks become effectively porous.

The value of this segmentation is practical. An internet-wide count of 3177387 is too abstract to act on. "Hosting providers in region X carry the largest share of default-port Redis exposure" is something a security team, a cloud provider's abuse department, or a national CERT can act on: notify affected operators, tighten egress defaults, or launch targeted outreach.

Again, the epistemic caveat applies with full force here. A hosting provider with many matching hosts does not necessarily have a worse security culture than one with few; it may simply be larger. Sector-level analysis identifies where the surface is, not where breaches are.

5. Technical Limitations of Banner Grabbing

Honest measurement requires acknowledging what banner-based enumeration cannot tell us. The following limitations apply directly to the 3177387 figure:

• False positives. A host running a proxy, honeypot, or a service that mimics the Redis protocol response may be classified as Redis by any banner-matching engine. Some of the 3177387 hosts are almost certainly not genuine Redis instances.
• False negatives. Redis instances on non-standard ports are excluded by the port="6379" filter. Hosts behind packet filters that drop ZoomEye probes are invisible. TLS-wrapped Redis endpoints may present banners that classify differently. The true internet-exposed Redis population is therefore larger than this measurement.
• No inference about authentication. A Redis banner does not reveal whether requirepass or ACL-based authentication is configured. Modern Redis supports Access Control Lists (ACLs) that provide fine-grained, per-user permissions; a banner-matching host may be fully locked down behind authenticated ACLs, or it may accept unauthenticated commands. Only an active, authorized protocol-level test can distinguish these states — and such testing raises legal and ethical boundaries that passive banner indexing deliberately respects.
• No inference about compromise. A host matching the query may have been compromised years ago, scanned hourly, or never touched by an adversary. Exposure is a precondition for exploitation, not evidence of it.
• Temporal decay. The count is valid for the collection date, 2026-09-20. Services churn continuously; the figure is a snapshot, not a census.

These limitations do not diminish the value of the measurement. They define its correct use: exposure measurement answers "how large is the attack surface," and that answer is a necessary input to risk decisions, but it is not a vulnerability assessment.

6. Mitigation Strategies for Database Administrators

For administrators who discover their own hosts in a query like this one, the remediation path is well established in Redis's own security documentation:

• Bind to trusted interfaces only. Set the bind directive to loopback or private addresses so the service is never directly internet-reachable. Redis's documentation is explicit that exposing a Redis instance directly to the internet should be avoided unless the full set of hardening measures is in place.
• Enable authentication and ACLs. Since Redis 6, Access Control Lists allow administrators to create users with scoped command and key-pattern permissions — a far better posture than the legacy all-or-nothing requirepass. At minimum, require a strong password on every instance.
• Restrict dangerous commands. Rename or disable administrative commands such as CONFIG, FLUSHALL, and DEBUG in deployments where they are not operationally required.
• Segment the network. Place Redis behind a firewall or security group that permits connections only from application hosts. Default-deny egress and ingress rules around data stores should be the norm.
• Encrypt transport where exposure is unavoidable. If Redis must be reachable over untrusted networks, use TLS and consider the protected-mode behaviors built into recent Redis versions.
• Monitor and verify externally. Internal configuration audits miss drift. Periodic external verification — for example, by running scoped queries on a platform such as ZoomEye against an organization's own IP ranges — catches misconfiguration the moment it appears, not after an incident.

7. Conclusion: The Need for Continuous Monitoring

The measurement behind this article is deliberately narrow: one query, one date, one exact result — 3177387 hosts matching service="redis" && port="6379" on 2026-09-20. Its power lies in that precision. Anyone can re-run the query and observe how the surface changes; that reproducibility is what separates internet-measurement analysis from anecdote.

The broader lesson is that database exposure on the open internet is not an edge case. It is a persistent, measurable, millions-of-hosts phenomenon driven less by sophisticated attackers than by ordinary configuration drift. Closing that gap requires two things: administrators adopting the hardening defaults that Redis's documentation and ACL system make straightforward, and the security community maintaining continuous, honest measurement of the exposed surface — clearly distinguishing what a banner tells us (a service is reachable) from what it does not (that the service is vulnerable, unauthenticated, or compromised).

Platforms like ZoomEye make that continuous measurement practical at internet scale, turning an abstract risk into a concrete, trackable number.

References

• Redis Security Documentation
• Redis Access Control Lists (ACL)
• CVE-2022-0543 (Redis Lua sandbox escape)