Redis, MySQL and PostgreSQL on the Open Internet: 529,000 Reachable Database Ports

Database ports are the most reliable exposure signal on the internet, because they change slowly and the default ports are almost never moved. A set of ZoomEye host searches collected on 18 September 2026 returned 501,664 observable services on port 6379, 27,971 on port 3306 and 26,089 on port 5432. That is roughly 555,000 reachable endpoints across Redis, MySQL and PostgreSQL defaults.
The numbers are large enough to be worth decomposing, and the decomposition is more interesting than the total.

Why Redis dominates

Port 6379 accounts for about 90% of the three-port total. Redis has a specific combination of properties that explain this. It binds to all interfaces by default in many packaged builds. It has no authentication enabled by default. It is frequently deployed as a cache or queue by application teams who treat it as an internal component and do not route it through the network team's firewall review.
The security model of Redis assumes a trusted network. The default configuration has no password, and the protected-mode setting that restricts access to loopback was introduced as a mitigation rather than as the original design. When a Redis instance is reachable and unauthenticated, an attacker can read the keyspace, write to it, and in many configurations use it to write files or load modules, which converts a cache into an execution primitive.

Why MySQL and PostgreSQL are lower but not low

27,971 MySQL endpoints and 26,089 PostgreSQL endpoints are smaller populations, and both databases have authentication enabled by default. That changes the nature of the exposure. A reachable MySQL or PostgreSQL instance is not automatically an open database; it is an authentication surface that is reachable from the internet.
The risk profile is different in three ways. Brute force and credential stuffing become viable against a reachable login endpoint. Unpatched server versions become remotely exploitable without credentials, which is how the MongoDB zlib decompression flaw worked. And configuration mistakes, such as a pg_hba.conf entry that trusts a wide subnet or a MySQL user with a wildcard host grant, turn an authenticated service into an unauthenticated one.

Reading the numbers as a population, not a verdict

None of these counts describe vulnerable systems. They describe services that answered on a default port from the public internet. A Redis instance with a strong password, TLS and a firewall rule allowing only application hosts is still an observable service on 6379, and it is not a problem.
The useful interpretation is distributional. If an organisation finds that its own address space contributes to the 501,664 figure, that is a finding worth acting on, because the default Redis posture is unauthenticated. If the organisation's Redis instances are bound to loopback or a private interface, the global number is someone else's problem.

A practical check

The check that matters takes an afternoon. Enumerate every listening service on 6379, 3306 and 5432 across the estate. For each, record the bind address, whether authentication is enabled, and whether the port is reachable from outside the network. The three answers determine the remediation: bind to a private interface, enable authentication, and restrict the port at the perimeter.
For Redis specifically, the compensating controls are worth knowing because they are quick. Enable requirepass or, better, use ACLs. Leave protected-mode enabled. Bind to a specific interface rather than all interfaces. Rename or disable the dangerous administrative commands where the application does not need them.

What this measurement supports

The defensible claim is narrow: default database ports remain widely reachable, and Redis specifically accounts for the overwhelming majority of that reachability. The claim that follows from it is also narrow: for organisations that do not know where their Redis instances are bound, the measurement is a reason to find out.

References

• ZoomEye host search, dorks port:6379 (501,664), port:3306 (27,971), port:5432 (26,089), collected 18 September 2026
• Redis documentation on protected-mode, ACLs and requirepass
• PostgreSQL documentation on pg_hba.conf authentication methods