CERT-In note sorts 14 ISC BIND CVEs into memory, resource and trust flaw classes

What CERT-In published

India's CERT-In has issued a high-severity vulnerability note covering fourteen security flaws in ISC BIND, and instead of settling for a vague "multiple vulnerabilities" label it names the underlying weakness behind each one. The note, CIVN-2026-0467, is dated 21 September 2026 and lists CVE-2026-19033, CVE-2026-19662, CVE-2026-19666, CVE-2026-19667, CVE-2026-19668, CVE-2026-19941, CVE-2026-75029, CVE-2026-76163, CVE-2026-77119, CVE-2026-77692, CVE-2026-78301, CVE-2026-80274, CVE-2026-81563 and CVE-2026-81736.

According to the note, the batch stems from a broad spread of weaknesses: use-after-free, null pointer dereference, memory not released after its effective lifetime, a numeric truncation error, a reachable assertion, heavy resource consumption inside a loop, asymmetric resource consumption in the form of amplification, inefficient algorithmic complexity, an origin validation error, insufficient verification of data authenticity, and acceptance of extraneous untrusted data alongside trusted data.

Three buckets of failure

A dev.to analysis of the advisory groups those weaknesses into three categories, each with a distinct operational signature.

The first is memory safety: the use-after-free, null dereference, unreleased memory and truncation issues. Per the analysis, these typically abort the process when a malformed message reaches the affected code path, which makes them denial-of-service primitives.

The second is resource exhaustion: loop-driven consumption, amplification and algorithmic complexity. These degrade service rather than killing it, so they show up as latency and load rather than a clean outage.

The third is trust-boundary failure: origin validation, authenticity verification and untrusted-data mixing. These are the candidates for spoofing or cache poisoning, producing wrong answers that are harder to detect and persist longer than an outage.

Triggering any of the flaws requires a specially crafted message — a DNS query or response, DNSSEC-related records, zone-transfer data, a TKEY request, SVCB/HTTPS records, or a DNS-over-HTTPS request. The key precondition is that the server processes that message type from an untrusted source. CERT-In reports no active exploitation of the fourteen CVEs and publishes no per-CVE severity ratings.

Scope and exposure

The affected releases named in the note span BIND 9.11.0 through 9.18.50, 9.20.0 through 9.20.27 and 9.21.0 through 9.21.25, plus Supported Preview Edition 9.11.3-S1 through 9.18.50-S1 and 9.20.9-S1 through 9.20.27-S1. Because CERT-In does not map individual CVEs to specific releases, the dev.to write-up advises treating these ranges as a prompt to consult ISC's advisory index rather than as a fixed patched/unpatched boundary.

For scale, the write-up cites ZoomEye counting 19,364,144 assets fingerprinted as ISC BIND. That figure is a product exposure estimate, not a vulnerability count, and it includes servers that may never accept untrusted input in the first place.

Recommended actions

The core fix is to move to the builds named in ISC's advisories. Beyond patching, the dev.to analysis recommends shrinking the attack surface reachable from untrusted sources:

• Close recursion to the open internet.
• Require TSIG authentication for zone transfers.
• Disable dynamic updates that are not in use.
• Rate-limit DNS-over-HTTPS.

It also suggests instrumenting resolvers so that unexpected process restarts and query-latency outliers raise alerts, since those are the observable signatures of the memory-safety and resource-exhaustion families respectively.

Why it matters

BIND sits under a vast amount of internet-facing DNS infrastructure, as the ZoomEye fingerprint count illustrates. The practical value of this advisory is that it goes beyond CVE counting: knowing the weakness class tells an operations team what to watch for after patching, or before it. Crashes point at the memory bugs, saturation points at the resource bugs, and — most insidiously — subtly incorrect answers point at the trust-boundary bugs, which no uptime monitor will ever catch. Since exploitation hinges on nothing more than a crafted message reaching the right code path from an untrusted source, the note is as much a call to tighten which inputs your resolvers accept as it is a call to update software.