BIND 9 CVE-2026-94300: Fixed Versions and How to Check Your Exposure

Last updated: 22 October 2026. We update this post when ISC, Red Hat or the Linux distributions publish new fixes or exploitation reports.

What Is CVE-2026-94300?

ISC published the advisory on 21 October 2026. It says replaying a signed GSS-TSIG message sent over UDP can corrupt memory in named.

An attacker who has captured an earlier signed message can send it again while the negotiated key is still valid. If the attacker also sends crafted queries to a zone they control, ISC says they may potentially achieve remote code execution. The advisory lists the impact as memory corruption, leading to a program abort or possible code execution.

ISC rates it High and exploitable remotely, with a CVSS score of 8.1. The vector is network, high attack complexity, no privileges and no user interaction. Red Hat rates it Important rather than Critical because exploitation depends on capturing an active key within its validity window. Read more in our CVE-2026-94300 reference page.

The advisory title speaks of concurrent GSS-TSIG messages, while its description is about replayed ones. Both refer to the same CVE, and the fix is the same.

Which BIND 9 Versions Are Affected, and What Fixes Them?

The table follows ISC’s advisory. Pick the row for the branch you run and move to the version in the last column.

The 9.18 line deserves a second look. ISC’s download page lists 9.18.50 as end of life, and the advisory notes that ISC patches only currently supported versions. If you still run 9.18 or anything older, plan a move to 9.20. Do not wait for a 9.18 patch that the advisory does not list.

Distribution packages may use their own version numbers. The Debian tracker lists the trixie security build 1:9.20.30-1~deb13u1 as fixed (advisory DSA-6576-1), while bookworm, which ships 9.18, is still shown as vulnerable. Check your vendor’s tracker, not only the upstream number.

Is Your DNS Server Exposed?

ISC’s advisory does not name the configuration that must be present. Red Hat’s statement fills the gap. It says BIND on Red Hat Enterprise Linux does not enable GSS-TSIG by default. The risk falls mainly on servers tied to Kerberos identity systems such as FreeIPA or Active Directory.

It adds that deployments which do not negotiate GSS-TSIG keys, or which limit dynamic DNS access to trusted networks, are not exposed to this attack vector. ISC says nothing either way about that, so treat it as Red Hat’s view for its own builds.

The BIND reference manual describes tkey-gssapi-keytab as the setting that names the Kerberos keytab file used for GSS-TSIG updates. Red Hat names this directive and tkey-gssapi-credential as the ones to remove to turn GSS-TSIG off. Run these on each server:

named -v
rndc version
named-checkconf -p -x | grep tkey-gssapi

The first command prints the version of the installed named, and rndc version prints the version of the running one. The last command prints the configuration with all included files and shows any GSS-TSIG directive. If the command prints no error and no line, no GSS-TSIG directive was found. named-checkconf -p prints the configuration only when it finds no errors.

Many teams do not know where every BIND server sits. Servers on public addresses are the first to find, and External Attack Surface Management exists for that job. BIND can also report a different version string than the real one through its version option, so confirm on the host.

Is CVE-2026-94300 Being Exploited?

ISC states it is not aware of any active exploits, and the flaw was found in internal testing.

The CISA coordinator entry on the CVE record, dated 21 October, marks exploitation as none, automatable as no and technical impact as total. The CISA Known Exploited Vulnerabilities catalog, as released on 21 October at 14:04 UTC, does not list it.

On X we counted 82 distinct posts that mention the CVE or BIND GSS-TSIG between 21 and 22 October, 37 in English and 33 in Japanese. The Japan Registry Services (JPRS) posted an urgent notice on 22 October that strongly recommends upgrading, and CERT.LV posted an alert the same day. These are alerts, not reports of attacks.

We also searched our Blackhole dark web and Telegram monitoring for the CVE id. It found two posts between 21 and 22 October, both automatic relays of the advisory or the CVE record.

What Should You Do Now?

1. List every BIND 9 server, including those inside Active Directory or FreeIPA setups, and record the version with the commands above.
2. Look for tkey-gssapi-keytab or tkey-gssapi-credential in the effective configuration. Servers with either one go first.
3. Upgrade to 9.20.30, 9.21.27 or 9.20.30-S1, or to your distribution’s fixed build. Restart named and confirm the running version.
4. If you cannot upgrade yet, treat Red Hat’s advice as a stopgap, not a fix. Red Hat says to remove the GSS-TSIG directives and restart, or to limit port 53 to trusted network segments with a firewall. Removing GSS-TSIG stops Kerberos-authenticated dynamic DNS updates, which can break Active Directory or IdM enrollment.
5. Note that ISC itself lists no workarounds. Plan the upgrade within your normal patch management window for a High-rated flaw, and sooner for servers that sit on the internet.

What Else Did ISC Fix on 21 October?

Three other advisories came out the same day, all fixed by the same releases. All three are rated High with a CVSS score of 7.5 and are denial of service issues.

• CVE-2026-19630: a resolver does unlimited extra work on certain inbound DNS messages, so a message with many of those structures can use up CPU and memory.
• CVE-2026-96888: a resolver with both a redirect zone and qname-minimization strict can abort with an assertion failure.
• CVE-2026-97313: a recursive server with at least two RPZ zones can exit after one query with recursion desired and one without. One zone must use the default recursive-only yes and the other recursive-only no.

GSS-TSIG has been in ISC’s advisories before. In May 2026 ISC fixed CVE-2026-3039, a memory exhaustion flaw in GSS-API TKEY negotiation, and said such servers are typically found in Active Directory integrated or Kerberos-secured DNS setups.

Timeline

1. 20 May 2026ISC fixes CVE-2026-3039A memory exhaustion bug in GSS-API TKEY negotiation, fixed in 9.18.49, 9.20.23 and 9.21.22.
2. 14 Oct 2026Early notificationISC’s revision history lists an early notification for CVE-2026-94300.
3. 21 Oct 2026Public disclosureISC publishes the advisory and releases 9.20.30, 9.21.27 and 9.20.30-S1. The CVE record is published the same day.
4. 21 Oct 2026KEV checkThe CISA catalog release of 14:04 UTC does not list the CVE. CISA marks exploitation as none.
5. 22 Oct 2026AlertsJPRS and CERT.LV post alerts on X.

Credit goes to the finders as ISC names them: the flaw was found in ISC’s internal testing and independently reported by a researcher at OpenAI.