DEV Community

Ioneyrezende
Ioneyrezende

Posted on

19.4 million BIND fingerprints, and the two facts a scan cannot tell you about CVE-2026-94300

#zoomeye #bind9 #dns #cve202694300

19.4 million BIND fingerprints, and the two facts a scan cannot tell you about CVE-2026-94300

A ZoomEye search for app="ISC BIND" returns 19,459,958 matching assets, measured on 22 October 2026 at 05:35 UTC. The number is large enough for a board slide and imprecise enough to mislead if presented as a risk figure. Four BIND 9 vulnerabilities published by ISC on 21 October illustrate why.

The measurement, stated honestly

The query app="ISC BIND" counts assets that ZoomEye identifies as running BIND. The search link appears in the references.
Three limits apply to that count, and each one matters for this advisory set in particular. First, a fingerprint identifies the software, not the version, so the count cannot separate BIND 9.18.50 and earlier from 9.20.30 and later. Second, it does not distinguish an authoritative-only server from a recursive resolver. Third, BIND is often bound to a loopback address behind a front-end that answers on port 53, which means the population visible to an internet scanner is a subset of the population that exists.
ISC's own framing helps here. BIND is one of the most widely used DNS servers on the internet. A count of nineteen million matching assets is consistent with that assessment. It is not evidence that nineteen million resolvers carry CVE-2026-94300.

The four flaws, with their preconditions

CVE CVSSv3 Precondition described by ISC
CVE-2026-94300 8.1 Attacker must capture a GSS-TSIG signed UDP message
CVE-2026-19630 7.5 A malicious DNS message; no further precondition stated
CVE-2026-97313 7.5 Recursive server with two RPZ zones using different recursive-only settings
CVE-2026-96888 7.5 Resolver with both a redirect zone and strict QNAME minimisation

The preconditions explain why the population count and the risk count diverge. CVE-2026-94300, the memory-corruption flaw that can lead to remote code execution, requires the attacker to capture a signed GSS-TSIG message first. The advisory then describes crafted queries to a zone the attacker controls as the path toward code execution. An environment that never enabled GSS-TSIG for dynamic updates is not on that path, and no internet scan reports whether it did.
CVE-2026-97313 and CVE-2026-96888 are configuration-dependent crashes. Both are reachable by ordinary query patterns once the configuration condition exists, which makes them the two flaws an organisation can rule out this week.
CVE-2026-19630 has the shortest precondition list: a malicious DNS message that makes BIND consume disproportionate CPU and memory. ISC found it in internal testing. For a resolver serving a large user population, that is the entry with the widest applicability.

The branch that has no fixed release

Fixed releases are 9.20.30 and 9.21.27, with 9.20.30-S1 for preview edition users. The 9.18 branch appears in the affected range and has no fixed release listed in the material reviewed. That asymmetry outweighs any single CVSS score, because it converts a patching task into a migration project for every organisation still running 9.18.
ISC states it is not aware of any active exploits for these four vulnerabilities, and no public proof of concept has been confirmed. The reporting also lists no workarounds, which means the only lever available before an upgrade is configuration review.

Using the exposure number for something it can support

The useful application of a nineteen-million asset count is trend and prioritisation, not risk scoring.
Repeat the same query at intervals with the same dork and the same measurement scope, and the delta describes how the visible BIND population changes. That is a coarse signal about exposure drift across the internet, and ZoomEye is well suited to producing it because the query and collection time are recorded with the result.
For prioritisation, the count supports another argument. If roughly nineteen million assets present a BIND fingerprint to a public scanner, then DNS infrastructure is not a niche exposure, and a resolver outage is a shared event rather than a local one. That reasoning justifies treating resolver patching as a service availability decision, which is often what gets it scheduled.

Four checks that belong beside the count

  1. List every RPZ zone on each recursive server and compare recursive-only settings. A pair of zones with different settings is the condition behind CVE-2026-97313.
  2. Check whether redirect zones and strict QNAME minimisation are both enabled on the same resolver, the condition behind CVE-2026-96888.
  3. Inventory GSS-TSIG usage. If signed updates are in use, review where those messages travel and whether the keys are still required.
  4. Record the branch and reported version of every resolver after upgrading. The 9.18 gap is the finding that returns at the next audit.

What the data cannot establish

The count does not report versions, does not distinguish recursive from authoritative roles, does not reveal GSS-TSIG configuration, and does not measure how many of those assets are reachable in a way that matters. The reporting behind the advisory set does not quantify GSS-TSIG deployment among internet-facing resolvers either. Both gaps point the same way: the internet count sizes the population, and internal configuration inventory answers the question.

References

Top comments (0)