CVE-2026-3119
Crash Vulnerability in BIND 9 Named via Signed TKEY Queries
Publication date: 2026-03-25
Last updated on: 2026-03-25
Assigner: Internet Systems Consortium (ISC)
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| isc | bind | From 9.20.0 (inc) to 9.20.20 (inc) |
| isc | bind | From 9.21.0 (inc) to 9.21.19 (inc) |
| isc | bind | From 9.20.9-s1 (inc) to 9.20.20-s1 (inc) |
| isc | bind | From 9.18.0 (inc) to 9.18.46 (inc) |
| isc | bind | From 9.18.11-s1 (inc) to 9.18.46-s1 (inc) |
| isc | bind | From 9.20.9-S1 (inc) to 9.20.20-S1 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-617 | The product contains an assert() or similar statement that can be triggered by an attacker, which leads to an application exit or other behavior that is more severe than necessary. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-3119 is a vulnerability in the BIND 9 DNS server daemon named that can cause it to crash under certain conditions.
The issue occurs when named processes a correctly signed DNS query containing a TKEY record with a valid transaction signature (TSIG) from a key declared in the named configuration.
If these conditions are met, named may terminate unexpectedly, causing a denial of service.
How can this vulnerability impact me? :
This vulnerability impacts the availability of the DNS service by causing the named daemon to crash.
Since the crash happens remotely and requires only low privileges with no user interaction, an attacker could exploit this to cause a denial of service.
The confidentiality and integrity of the DNS service are not affected by this vulnerability.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability occurs when the DNS server daemon named processes a correctly signed query containing a TKEY record with a valid transaction signature (TSIG) from a key declared in the named configuration.
To detect this vulnerability on your system, you should check if your BIND version is within the affected ranges: 9.20.0 through 9.20.20, 9.21.0 through 9.21.19, or 9.20.9-S1 through 9.20.20-S1.
You can verify the BIND version installed by running the command: `named -v` or `named -V`.
To detect if your system is receiving queries with TSIG-signed TKEY records that might trigger the crash, you can enable detailed query logging in named and filter logs for TSIG and TKEY records.
Example commands to check logs or capture network traffic include:
- Enable query logging in named.conf with `logging` options to capture TSIG-signed queries.
- Use `tcpdump` or `wireshark` to capture DNS traffic and filter for TKEY records: `tcpdump -i <interface> -nn -s0 -v port 53 and udp` and then analyze for TSIG and TKEY.
- Use `rndc` commands to check the status of keys configured in named.
However, no specific detection commands or scripts are provided in the available resources.
What immediate steps should I take to mitigate this vulnerability?
The recommended immediate mitigation is to remove any TSIG keys that could be exploited by an attacker, thereby preventing the vulnerable code path from being reached.
The definitive solution is to upgrade BIND to a patched version that addresses this vulnerability.
- Upgrade to BIND version 9.20.21, 9.21.20, or 9.20.21-S1 for the Supported Preview Edition.
- Remove or disable TSIG keys in the named configuration that are not necessary or could be exploited.
These steps will help prevent named from crashing due to processing maliciously crafted TSIG-signed TKEY queries.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
This vulnerability causes a denial of service (availability impact) by crashing the named DNS server when processing certain authenticated queries. It does not affect confidentiality or integrity of data.
Since the vulnerability impacts availability but not confidentiality or integrity, it may affect compliance with standards that require high availability and reliable service, but it does not directly expose personal or sensitive data.
No specific information is provided about direct impacts on compliance with GDPR, HIPAA, or other regulations.