DEV Community
DEV Community订阅

Four BIND 9 flaws, no workarounds: planning for a resolver that cannot fail over

ISC disclosed four high-severity BIND 9 vulnerabilities on 21 October 2026. None has a documented workaround. For an organisation running a shared recursive resolver, that combination removes every option except upgrading, so sequencing matters more than severity.

The four flaws

CVE CVSSv3 Weakness class Effect
CVE-2026-94300 8.1 CWE-362, race condition Memory corruption via replayed GSS-TSIG messages; possible remote code execution
CVE-2026-19630 7.5 CWE-407, inefficient algorithm Disproportionate CPU and memory consumption
CVE-2026-97313 7.5 CWE-617, reachable assertion Recursive server exits on certain query patterns
CVE-2026-96888 7.5 CWE-476, null pointer dereference Resolver aborts with an assertion failure

CVE-2026-94300 is the one to read twice. Replaying GSS-TSIG signed UDP messages can corrupt memory in the named process. An attacker must first capture a signed message, and the advisory notes that crafted queries to a zone they control may then lead to remote code execution. Dave Aitel of OpenAI is credited with independent discovery. Two conditions are worth separating here: capturing a signed GSS-TSIG message is a prerequisite, and the reporting does not state how widely GSS-TSIG is deployed in internet-facing resolvers.
The other three are availability flaws with configuration-dependent triggers. CVE-2026-19630 needs only a malicious DNS message to make BIND consume disproportionate CPU time and memory; ISC found it in internal testing. CVE-2026-97313 affects a recursive server running two RPZ zones with different recursive-only settings, which may exit on certain query patterns. CVE-2026-96888 affects a resolver configured with both a redirect zone and strict QNAME minimisation, which may abort with an assertion failure. Vitaly Simonovich reported both crash bugs.

Affected versions

Depending on the flaw, the affected range runs from BIND 9.11.0 or 9.16.0 through 9.18.50, plus 9.20.0 through 9.20.29 and 9.21.0 through 9.21.26. Matching BIND Supported Preview Edition releases in the -S1 line are also affected. Fixed releases are 9.20.30 and 9.21.27, with 9.20.30-S1 for preview edition users.
The 9.18 branch has a longer history and no fixed release listed in the material reviewed here. Organisations still on 9.18 need a migration plan, not another patch cycle, and that changes the shape of the work.

Why resolver failures are not local events

ISC states it is not aware of any active exploits for these four BIND 9 vulnerabilities, and no public proof of concept has been confirmed. That status lowers urgency and leaves the architecture problem untouched.
A resolver is a shared dependency. When one goes down, every user behind it loses name resolution, and most online services stop working for them before any local application reports an error. For an ISP or an enterprise running a shared resolver, a single crash can cut off resolution for an entire population. The two configuration-dependent crash bugs deserve attention despite their lower scores, because ordinary query patterns reach them without an attacker who has already captured signed traffic.

Auditing your own configuration against the triggers

Two of the four flaws can be checked without waiting for a patch window.

  1. List every RPZ zone on each recursive server and compare the 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. That combination is the condition behind CVE-2026-96888.
  3. Inventory GSS-TSIG usage separately. If signed updates are in use, review where those messages travel and whether the signing keys are still required. Removing a configuration condition reduces exposure to the crash bugs. It does not remediate the memory-corruption flaw, and the reporting describes no workaround for any of the four.

What to record for the next review

Write down the BIND version each resolver reports after the upgrade, the branch each host is on, and which hosts still depend on 9.18. The 9.18 gap will resurface at the next audit, and a documented migration date defends it better than a note that the branch is unsupported.

What remains uncertain

The reporting does not quantify how many internet-facing resolvers use GSS-TSIG, does not state whether the memory-corruption flaw can be triggered without a captured signed message, and does not give a fixed release for 9.18. It also does not measure how much traffic a single malicious message can force the resolver to process. Plan against those gaps rather than assuming the lower scores make the crash bugs irrelevant.

References

参与讨论