CVE-2026-3104
Isc Bind 9.20.0 – 9.20.21
Raw vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HSummary
CVE-2026-3104 is a high-severity Missing Release of Resource after Effective Lifetime (CWE-772) vulnerability in Isc Bind. Its CVSS base score is 7.5 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Endpoint Denial of Service (T1499); ranked at the 50th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SA-15 (Development Process, Standards, and Tools) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-3104 is a memory leak vulnerability (CWE-772) in the BIND resolver, triggered by querying a specially crafted domain. It affects BIND 9 versions 9.20.0 through 9.20.20, 9.21.0 through 9.21.19, and 9.20.9-S1 through 9.20.20-S1. Versions 9.18.0 through 9.18.46 and 9.18.11-S1 through 9.18.46-S1 are not affected. The issue has a CVSS v3.1 base score of 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H), indicating high availability impact with no confidentiality or integrity effects.
An unauthenticated attacker with network access can exploit this vulnerability remotely with low complexity and no user interaction required. By repeatedly querying the malicious domain, the attacker induces a memory leak in the BIND resolver, potentially leading to denial-of-service through gradual resource exhaustion and service degradation or crash.
ISC advisories recommend upgrading to patched versions BIND 9.20.21 or 9.21.20, available at the respective download links. Additional details are provided in the ISC knowledge base article at https://kb.isc.org/docs/cve-2026-3104.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-15410
Vulnerability Data
A specially crafted domain can be used to cause a memory leak in a BIND resolver simply by querying this domain. This issue affects BIND 9 versions 9.20.0 through 9.20.20, 9.21.0 through 9.21.19, and 9.20.9-S1 through 9.20.20-S1. BIND 9 versions…
more
9.18.0 through 9.18.46 and 9.18.11-S1 through 9.18.46-S1 are NOT affected.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Mitigating Controls (NIST 800-53 r5) AI
Developer testing and evaluation can discover missing resource releases through dynamic analysis or stress testing.
Requiring documented development standards and tools can mandate explicit resource-release patterns in code.
Engineering principles applied during development can require explicit resource-release patterns that stop memory leaks from being coded.
Resource-quota allocation limits the blast radius of an unreleased-resource exhaustion condition.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Lifecycle management explicitly requires handling resources through end-of-life including release.
Secure SDLC practices directly prevent missing resource-release defects during development.
Runtime monitoring may surface resource-exhaustion symptoms but does not address release logic.
Capacity monitoring can detect exhaustion caused by unreleased resources but does not prevent the root defect.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Explicit information-deletion requirements directly address timely release of resources after use.
Security testing in development can detect unreleased memory, providing partial coverage of the weakness.
Secure-SDLC practices include resource-management reviews, yet the control covers the entire lifecycle, not just this weakness.
Application security requirements can specify explicit memory-release rules, partially mitigating the weakness.
Secure system architecture and engineering principles include resource-management guidelines that address memory leaks.
Secure-coding rules can mandate explicit resource-release patterns, but the control is broader than this single weakness.