DEV Community

kozhevniko
kozhevniko

Posted on

5,873,669 Hosts on Port 1433: The Database Port That Still Faces the Internet

5,873,669 Hosts on Port 1433: The Database Port That Still Faces the Internet

Database exposure is among the oldest findings in internet measurement and among the most persistent. A query for port="1433", the default Microsoft SQL Server port, returned 5,873,669 matching assets on 23 September 2026. The number is worth reading against an exploited vulnerability in the same product that re-entered CISA's Known Exploited Vulnerabilities catalog in August 2026.

What was measured

The query was executed once against the ZoomEye index on 23 September 2026: port="1433". It returned 5,873,669 matching assets. The unit here is different from a product fingerprint query. A port query counts listening services on that port, which includes SQL Server instances, other services bound to the same port, and hosts that respond in a way the index classifies as matching.
That distinction shapes how the number should be read. A port count is a statement about listening services, not about a product population, and it should not be described as a count of SQL Server deployments.

What the count supports

The figure supports the conclusion that inbound database connectivity from untrusted networks remains a common architectural choice. That is a finding about network design rather than about a product, and it explains why database flaws remain productive for attackers despite years of guidance recommending against direct exposure.
It also supports a proportionality argument. CVE-2019-1068 was added to the KEV catalog on 26 August 2026 with a remediation deadline of 29 August 2026. CISA's description states that it allows an attacker to execute code in the context of the SQL Server Database Engine service account. The vendor advisory has been available since 2019. A vulnerability with a seven-year-old fix in a product class with millions of listening services is a favourable combination for an attacker and an unflattering one for defenders.
The count also usefully separates exposure from exploitability. The flaw requires a reachable instance and the ability to interact with it. Millions of listening services provide the reachability component; the remaining variables are configuration.

What the count cannot support

The number does not indicate which services are actual SQL Server instances. Port 1433 is registered to SQL Server, and other software does bind it, so a portion of the matches describes something else.
It does not indicate authentication configuration. An instance that accepts only Windows authentication, with network access controlled by firewall rules and reachable only from application servers, presents a different risk from a mixed-mode instance with a weak administrative password. The port count is silent on both.
It does not indicate patch level. SQL Server versions span more than a decade of releases, some of them out of support. The count of listening services carries no version detail, and any claim about the vulnerable subset would be an extrapolation.
It does not measure exploitation. CISA added CVE-2019-1068 because evidence of exploitation exists, not because the exploitation was observed within this population.

Turning a port count into an inventory

A port query becomes useful when combined with scope. Two applications are worth running.
The first is self-directed. Restricting the same query to an organisation's own address ranges answers a specific question: which of our database services are reachable from outside the perimeter? The answer is frequently different from what the asset register says, because a database service published for a temporary integration often stays published after the project ends.
The second is volumetric. Comparing the query result over time shows whether exposure in this category is changing. A stable figure of this size describes a durable property of internet architecture rather than a transient misconfiguration spike.

The recommendation that keeps being ignored

The guidance for database exposure remains the same: keep database services on networks that only the applications using them can reach. The measurement demonstrates that this guidance competes with a simpler alternative, which is to publish the service and rely on the database's own authentication. That trade-off works until it does not, and when it fails, the failure happens in the context of the database engine service account.

References

Top comments (0)

Some comments may only be visible to logged-in visitors. Sign in to view all comments.