BIND 9 CVE-2026-94300: GSS-TSIG Replay Memory Corruption Explained

CVE-2026-94300 is a High severity BIND 9 flaw (CVSS 8.1) in which a replayed GSS-TSIG signed UDP message can corrupt memory in named and, according to ISC, potentially lead to remote code execution. It matters for DNS servers that accept Kerberos signed dynamic updates. Upgrade to BIND 9.20.30 or 9.21.27, or your distribution's patched package.

ISC published the advisory on 21 October 2026 alongside three other High severity fixes, all denial of service bugs rated 7.5. ISC says it is not aware of active exploits for any of the four, and none has a workaround. The awkward detail is that the affected range runs from BIND 9.11.0 through 9.18.50, and ISC's 9.18 branch reached end of life in June 2026, so there is no upstream 9.18 fix. If you run 9.18 from source or from ISC's own packages, your path is a move to 9.20.

This post covers the full technical record from ISC and the distributions, how GSS-TSIG works and why replay inside the key lifetime is the problem, how to find every named you run (including the ones inside appliances and containers), platform by platform patch commands for Debian, Ubuntu, RHEL and Amazon Linux, what has changed since the first reports, and what is still unknown. There is no exploit detail here.

What happened

ISC, which maintains BIND 9, released BIND 9.20.30 (stable) and 9.21.27 (development) on 21 October 2026 with fixes for four vulnerabilities. ISC's change log for the CVE-2026-94300 advisory shows version 1.0 as an early notification on 14 October and version 2.0 as public disclosure on 21 October. Debian shipped a fixed package for its stable release the same evening. Red Hat rated the flaw Important and published a mitigation. Amazon Linux lists all its releases as pending a fix.

The finder credit, as ISC states it: the flaw was found in ISC's internal testing, and ISC thanks Dave Aitel from OpenAI, who "independently discovered and responsibly reported the issue to ISC." The two DoS bugs that involve RPZ and redirect zones are credited by ISC's advisories to Vitaly Simonovich. ISC's advisory for CVE-2026-19630 says it was found in internal testing and lists no external credit.

Timeline

Times are UTC and are given only where a source published them.

Technical details

The four CVEs in the 21 October release

Everything in this table comes from ISC's knowledge base articles unless noted. CWE values are listed per source, because sources differ.

GitLab issue numbers come from the BIND 9.20.30 change log, which ISC publishes on Read the Docs.

Affected and fixed versions, straight from ISC

Three points about that table.

First, there is no 9.18 row in the fixed column. ISC's download page lists the 9.18 branch with status EOL, current version 9.18.50, and an end of life date of Q2 2026. ISC's 10 June blog called the June release the last 9.18 maintenance version, and the 23 June bind-users post said 9.18 will not be maintained or patched. So on ISC's own terms, 9.18.50 is affected and will stay affected.

Second, 9.20 is now the branch to be on. ISC's download page lists 9.20.30 as Current Stable, also marked as the Extended Support Version, with end of life in Q2 2028. 9.21.27 is the development branch.

Third, the 9.20.30-S1 build is the Supported Preview Edition, which ISC provides to eligible support customers. If you have never heard of the S editions, you are on the open source releases.

What each fix changed, per the 9.20.30 change log

• CVE-2026-94300 (GL #6320): ISC's entry is about remote termination of named under concurrent GSS-TSIG traffic. It says concurrent signed messages that share a GSS-TSIG session negotiated through TKEY could corrupt Kerberos state and crash named. Access to that state is now serialized.
• CVE-2026-19630 (GL #5932): crafted DNS messages could exhaust CPU while being parsed. Name expansion per message is now bounded, and named answers FORMERR when the bound is exceeded. LinuxCompatible describes the trigger as excessive name compression.
• CVE-2026-96888 (GL #6386): processing an NXDOMAIN response with a redirect zone could crash named when qname-minimization is set to strict.
• CVE-2026-97313 (GL #6408): named could terminate when resuming from a query initiated by RPZ processing.

The same release also lists GSS-TSIG and TSIG related bug fixes that ISC did not file as security issues: GSS-TSIG keys now last as long as the negotiated context (MR !12783), and TSIG sessions are no longer lost across a reload (MR !12802). If you test 9.20.30 in a lab before rolling it out, include a Kerberos signed update after a reload in your test plan.

Scores and risk signals from other sources

OpenCVE also shows a Red Hat Hardened Images package bind-main-9.20.30-0.1.hum1 under advisory RHSA-2026:87309, and states that Red Hat lists RHEL 6 through 10 and OpenShift 4 packages as affected. We could not see a per product table on Red Hat's own CVE page, so treat that as unconfirmed until your Red Hat errata show it. Red Hat Bugzilla 2556407 depends on a Fedora tracker for bind (2558420, NEW) and a Fedora tracker for dhcp that Red Hat closed as NOTABUG (2558421).

Indicators of compromise

None have been published. ISC, Red Hat, Debian, Amazon and the Cyber Centre list no domains, IP addresses, hashes or signatures for this CVE, and no source we read reports exploitation or a public proof of concept. The detection section below is about crash signals and configuration exposure, not about known attacker infrastructure.

How GSS-TSIG works, and why replay matters

TSIG and TKEY in two paragraphs

DNS has a way to sign individual messages called TSIG. A client and server share a key, and each message carries a signature and a timestamp. Classic TSIG uses a static shared secret that an administrator generates with tsig-keygen and copies to both sides. That is fine for two servers doing zone transfers. It is painful for thousands of Windows clients that want to register their own A records.

GSS-TSIG, defined in RFC 3645, replaces the static secret with a security context negotiated through GSS-API, which in practice means Kerberos. The client and server run a TKEY exchange (TKEY mode 3) in which the client sends a GSS-API token and the server answers with its own, repeating until both sides have an established context. That context is identified by a key name. From then on, messages carry TSIG records with the algorithm name gss-tsig, signed with the context. RFC 3645 says the context "has a finite lifetime," set by the Kerberos mechanism, and that a server may end it at any time.

Where it shows up in real networks

You are using GSS-TSIG on a BIND server if its configuration contains tkey-gssapi-keytab or tkey-gssapi-credential. Red Hat's mitigation names exactly those two options. The common deployments are:

• Samba Active Directory domain controllers using the BIND9_DLZ back end. The Samba wiki tells administrators to add tkey-gssapi-keytab pointing at Samba's dns.keytab so Kerberos clients can update the zone.
• FreeIPA and Red Hat Identity Management. Red Hat names FreeIPA as one of the Kerberos integrated setups that carry the exposure.
• BIND servers that accept secure dynamic updates from Windows clients or Active Directory domain controllers, usually with update-policy rules that grant updates based on Kerberos principals.
• Appliances and IPAM products that embed BIND and offer an "Active Directory integration" or "secure DDNS" switch. Whether those use GSS-TSIG is a question for each vendor.

Why replay inside the key lifetime is the problem

ISC's description is short. An attacker who captures one GSS-TSIG signed UDP message can replay it while the negotiated TSIG key is still valid. Combined with crafted queries to a zone the attacker controls, that can corrupt named's memory, which may cause an abort and potentially remote code execution.

In plain terms, the signature on the captured message is genuine, because a real client produced it with a real Kerberos context. The bug is not that BIND accepts a forged signature. According to ISC's change log, the bug is that concurrent signed messages using the same negotiated session could touch shared Kerberos state at the same time, and that state was not protected against concurrent access. Hence CWE-362 (race condition) in the CVE record, CWE-415 (double free) also listed by the CNA, and ISC's fix, which serializes access.

That framing explains the score. The attack vector is the network and no privileges or user interaction are needed, which pushes the score up. Attack complexity is High, which pulls it down. Red Hat's statement spells out why: the attacker has to capture an active signed UDP message within its key's validity window and coordinate complex concurrent requests. Capturing a signed update usually means being on the path between a client and the DNS server, or having a foothold on a segment where that traffic flows. That is a real constraint, but it is the kind of constraint that an attacker already inside a Windows domain can often meet.

Two more points from the sources. LinuxCompatible says concurrent signed messages can terminate named, and describes a working path to remote code execution. ISC itself says RCE is potential. We follow ISC's wording. And no source says that GSS-TSIG over TCP is out of scope; ISC's description talks only about UDP messages, so do not assume that switching clients to TCP is a mitigation.

The three denial of service bugs, in plain language

• CVE-2026-19630 affects BIND as a resolver. ISC says inbound messages with a particular structure trigger extra processing that BIND did not limit, so a message with many of those structures uses disproportionate CPU and memory. There is no configuration precondition in ISC's text beyond being a resolver, which makes this the most broadly relevant of the four for availability.
• CVE-2026-97313 needs a recursive server that allows recursion and has at least two RPZ zones, one with recursive-only yes and one with recursive-only no. A recursion desired query followed by a non recursive query can make it exit on an assertion.
• CVE-2026-96888 needs a resolver with both a redirect zone and qname-minimization strict. Processing the redirect can trip an assertion and abort.

An assertion failure in BIND is deliberate: named stops rather than continue in a state it considers impossible. That is good for memory safety and bad for availability, because a supervisor that restarts named in a loop still leaves gaps in resolution.

Who is affected

The ISC Kea DHCP server is a separate product. Red Hat closed its Fedora dhcp tracker for this CVE as NOTABUG.

BIND 9.18 is end of life: what that means here

We checked ISC's own pages before writing this section, because a lot of production DNS still runs 9.18.

• ISC's download page shows 9.18 with status EOL, end of life Q2 2026, and 9.18.50 as its last version.
• ISC's 10 June 2026 blog, by Vicky Risk, says users are "strongly urged to migrate to BIND 9.20 as soon as possible," that 9.20 is already at Extended Support Version quality, and that ISC is working through a backlog of security bugs, many of them found through LLM analysis.
• The 23 June bind-users post says 9.18.50 is the last 9.18 release and that ISC recommends procedures that allow monthly BIND updates.
• ISC's public bind-esv package repositories switched from 9.18 to 9.20 in mid July. If you install from bind-esv and have not updated since, check the repository version before you update, as ISC advises.

What it does not mean: if your 9.18 comes from a Linux distribution, the distribution may still backport fixes to it. As of 22 October, Debian's tracker marks bookworm's bind9 (1:9.18.49-1deb12u1, and 1:9.18.49-1deb12u2 in bookworm security) as vulnerable with no fix listed. Keep an eye on your distribution rather than assuming either outcome.

The practical advice: if you build BIND yourself, or use ISC packages, plan the 9.18 to 9.20 migration as the fix for this CVE. ISC publishes a 9.18 to 9.20 significant changes article and known issues lists for both branches; read them before you change a production resolver.

What to do now

Step 1: find every named you run

The first job is a complete list. BIND hides in more places than the DNS team's two servers.

On each Linux host:

# Is named installed, and which version?
command -v named && named -v
named -V | head -n 3

# Package views
dpkg -l 'bind9*' 2>/dev/null | awk '/^ii/ {print $2, $3}'
rpm -qa 'bind*' 2>/dev/null | sort

# Any named binaries outside the package manager (source builds, vendor bundles)
sudo find / -xdev -type f -name named -perm -u+x 2>/dev/null

# Is it running, and as which unit?
systemctl list-units --type=service | grep -Ei 'named|bind9'

From the network, for servers you do not log in to:

# Many servers answer this; many hide or change it, so treat it as a hint only
dig @192.0.2.53 version.bind chaos txt +short

In containers and registries:

# Running containers that include named
docker ps --format '{{.ID}} {{.Image}}' | while read id img; do
  docker exec "$id" sh -c 'command -v named >/dev/null && named -v' 2>/dev/null \
    && echo "  ^ in $img ($id)"
done

# Kubernetes: pods whose images look like BIND
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{range .spec.containers[*]}{.image}{" "}{end}{"\n"}{end}' \
  | grep -Ei 'bind|named|dns'

For appliances, IPAM products and domain controller builds you did not assemble yourself, open a ticket with the vendor today and ask two questions: which BIND version is in the current firmware, and is GSS-TSIG used. If the vendor publishes an SBOM, search it for bind and named.

Step 2: check whether GSS-TSIG is configured

named-checkconf -p prints the full effective configuration with includes resolved. Search it for the GSS-TSIG options and for update policies based on Kerberos principals.

# Debian and Ubuntu: /etc/bind/named.conf ; RHEL family: /etc/named.conf
sudo named-checkconf -p /etc/named.conf 2>/dev/null || sudo named-checkconf -p /etc/bind/named.conf

sudo named-checkconf -p /etc/named.conf 2>/dev/null \
  | grep -nE 'tkey-gssapi-(keytab|credential)|tkey-domain|update-policy|krb5-|ms-self|ms-sub' 

If you run a Samba AD domain controller, also look at the Samba generated include file. The Samba wiki places it at /usr/local/samba/bind-dns/named.conf for source installs; distribution packages use their own paths.

grep -rn 'tkey-gssapi' /etc/bind /etc/named* /usr/local/samba/bind-dns 2>/dev/null

Any hit means CVE-2026-94300 applies to that server and it goes to the top of the list.

Step 3: check resolver settings for the DoS bugs

CONF=$(test -f /etc/named.conf && echo /etc/named.conf || echo /etc/bind/named.conf)

# CVE-2026-97313: two or more RPZ zones with different recursive-only settings
sudo named-checkconf -p "$CONF" | grep -nE 'response-policy|recursive-only'

# CVE-2026-96888: a redirect zone plus strict QNAME minimisation
sudo named-checkconf -p "$CONF" | grep -nE 'type redirect|qname-minimization'

# CVE-2026-19630: is this server a resolver at all?
sudo named-checkconf -p "$CONF" | grep -nE 'recursion|allow-recursion'

Do not remove RPZ or change QNAME minimisation as a "workaround". ISC lists no workarounds for these bugs, and changing resolver policy under pressure creates its own outages. Patch instead.

Step 4: patch, platform by platform

Debian 13 (trixie). DSA-6576-1 fixes all four CVEs in bind9 1:9.20.30-1~deb13u1.

sudo apt update
apt policy bind9
sudo apt install --only-upgrade bind9 bind9-utils bind9-libs
dpkg -l bind9 | awk '/^ii/ {print $3}'     # expect 1:9.20.30-1~deb13u1 or later
sudo systemctl restart named

Unstable is fixed in 1:9.20.30-1 per the Debian tracker. Debian 12 (bookworm) is marked vulnerable with no fix listed as of 22 October. Watch https://security-tracker.debian.org/tracker/CVE-2026-94300 and apply the update when a DSA appears. Until then, the network and configuration measures in step 5 are what you have.

Ubuntu. We found no Ubuntu Security Notice or Ubuntu CVE page for CVE-2026-94300 at the time of writing, and the most recent bind9 notice we found predates the disclosure. Check status and apply the fix when it lands:

apt policy bind9
sudo pro fix CVE-2026-94300          # Ubuntu Pro client reports whether a fix is available
sudo apt update && sudo apt install --only-upgrade bind9

RHEL, CentOS Stream, Rocky, AlmaLinux, Fedora. Red Hat rates the CVE Important. Use the CVE filter so you get the backported package rather than chasing the upstream version number.

rpm -qa 'bind*' | sort
sudo dnf updateinfo list --cve CVE-2026-94300
sudo dnf upgrade --cve CVE-2026-94300
sudo systemctl restart named        # or named-chroot if you run the chroot unit

If updateinfo shows nothing yet, the errata has not shipped for your release. On FreeIPA or IdM servers, plan the restart in a maintenance window: the restart briefly interrupts DNS, and IdM depends on it.

Amazon Linux. Amazon lists bind on AL2, AL2023 and the AL2027 Preview as Pending Fix. Check again before patching:

# Amazon Linux 2023
sudo dnf check-update --security
sudo dnf updateinfo list --cve CVE-2026-94300

# Amazon Linux 2
sudo yum updateinfo list cves | grep CVE-2026-94300

ISC packages and source builds. ISC's bind and bind-esv repositories now serve 9.20. For source, ISC publishes tarballs at downloads.isc.org/isc/bind9/9.20.30/. Verify the signature before you build:

curl -O https://downloads.isc.org/isc/bind9/9.20.30/bind-9.20.30.tar.xz
curl -O https://downloads.isc.org/isc/bind9/9.20.30/bind-9.20.30.tar.xz.asc
gpg --verify bind-9.20.30.tar.xz.asc bind-9.20.30.tar.xz

Containers. Rebuild every image that includes named from a base or package that carries the fix, push it, and roll the deployment. Then confirm the version inside the running container, not in the Dockerfile:

kubectl exec -n dns deploy/bind -- named -v

ISC's own release announcement said container images and packages would follow the source release later the same day, and that operating system builds may lag further.

Step 5: if you cannot patch today

ISC lists no workaround. Red Hat offers two mitigations for CVE-2026-94300, each with a cost.

1. Turn off GSS-TSIG if you do not need it. Remove or comment out tkey-gssapi-keytab and tkey-gssapi-credential in the configuration and any included files, check the configuration, and restart. Red Hat warns that this breaks Kerberos authenticated dynamic DNS updates, which can disrupt automated Active Directory or IdM enrollment.

   sudo named-checkconf /etc/named.conf && sudo systemctl restart named
   

2. Restrict who can reach port 53. Red Hat suggests limiting TCP and UDP port 53 to trusted network segments with host or network firewalls. On an internal DNS server that only domain members should reach, that is reasonable. On a server that answers the public internet, it is not an option.

Two more measures fit here, as defence in depth rather than fixes. Scope update-policy and allow-update to the principals and addresses that genuinely need to update each zone; that limits who produces signed update traffic in the first place. And put domain controllers and the DNS servers they update on a segment that general clients cannot sniff, since the attack starts with capturing a signed message.

Step 6: verify

named -v                                   # expect BIND 9.20.30 or your distro's fixed build
sudo rndc status | head -n 5               # confirms the running server, not just the binary on disk
dig @127.0.0.1 example.com A +short        # resolution still works

For GSS-TSIG servers, run one real signed update from a domain member (for example, ipconfig /registerdns on a Windows client, or nsupdate -g from a Linux host with a valid Kerberos ticket) and confirm the record appears. Then run rndc reload and repeat, since the release also changed TSIG behaviour across reloads.

Detection: what you can look for

With no published indicators, look for the effect the bugs have: named stopping unexpectedly.

# Crashes, assertion failures and aborts since the early notification date
sudo journalctl -u named -u bind9 --since "2026-10-14" \
  | grep -Ei 'assert|abort|exiting \(due to|core dump|signal'

# Core dumps captured by systemd
coredumpctl list named 2>/dev/null

# TSIG, TKEY and GSS messages, to see who sends signed traffic and whether it fails
sudo journalctl -u named --since "2026-10-14" | grep -Ei 'tsig|tkey|gss' | tail -n 50

If you collect DNS server logs centrally, two simple alerts help for the next few weeks: any named restart that was not part of a change, and a spike in TSIG verification failures or TKEY negotiations from a source that does not normally send them. Neither proves exploitation. Both tell you where to look.

What changed since the first reports

• Early notification to public. The KB change logs show early notification on 14 October and public disclosure on 21 October. Anyone who only watched public channels got the details on the 21st.
• Distributions moved at different speeds. Debian fixed trixie and unstable on the day. Bookworm, Amazon Linux and, as far as we could find, Ubuntu had not shipped fixes by 22 October.
• The severity label drifted in secondary coverage. ISC rates CVE-2026-94300 High and says RCE is potential. Red Hat says Important rather than Critical. Some secondary sites have described it as critical or as a zero day RCE. It is neither, on the primary sources: it was found before exploitation and ISC knows of no active exploits.
• A wrong CVE ID is circulating. At least one CVE mirror shows a truncated ID with a 7.5 score. The correct ID is CVE-2026-94300, scored 8.1.
• ISC's release cadence has changed. LinuxCompatible reports this as ISC's fourth monthly security release of 2026, that ISC now folds security fixes into every monthly release, and that ISC can no longer always say which minor version introduced a flaw, so its advice is to run the latest maintenance release on your branch. ISC's June blog ties that cadence to a backlog of bugs found through LLM analysis.

Disputes and inconsistencies in the sources

• Affected range in the Cyber Centre advisory. AV26-1072 lists 9.11.0 to 9.18.50 twice and 9.21.0 to 9.21.26, but not 9.20.0 to 9.20.29. ISC's KB lists 9.20.0 through 9.20.29 as affected. Go by ISC.
• Credit for CVE-2026-97313. ISC's KB article thanks Vitaly Simonovich. The 9.20.30 change log entry for the same fix says the issue was reported by "whisperer". We use ISC's advisory wording; the two may refer to the same person.
• CWE. The CNA record lists CWE-362 and CWE-415; Red Hat and OpenCVE show CWE-366. These are all race or memory management classes and do not change what you do.

Open questions

• Will any distribution backport to 9.18? Debian bookworm, Ubuntu LTS releases and RHEL releases built on older BIND branches all need either a backport or a rebase. None had published one for bookworm by 22 October.
• Which appliances embed an affected BIND with GSS-TSIG enabled? No appliance vendor advisory had appeared in the sources we read.
• How easy is the capture step in practice? Red Hat's statement describes the conditions. Nobody has published measurements, and we do not expect them to, given the risk.
• Will ISC publish a reproduction test? LinuxCompatible says ISC plans to publish reproduction tests with disclosures. We did not see one linked from the KB article.
• Exploitation status. ISC, CISA's SSVC entry and every distribution we read say none known. That can change; check the KB article and CISA's KEV catalog.

What would have helped

Practices any team can use

• A live inventory of DNS software, including the hidden copies. The difference between a calm and a chaotic 21 October was whether the team could answer "where is named, which version, and is GSS-TSIG on" in minutes. That list has to include domain controllers running Samba, IdM servers, IPAM appliances and container images, not just the two servers on the network diagram. Our guide to using SBOMs to find affected products fast applies directly.
• SBOMs from appliance vendors. If a vendor bundles BIND, its SBOM should say which version. Ask for it at procurement and at renewal.
• Staying on a supported branch. ISC announced the end of 9.18 in June, four months before this advisory. Teams already on 9.20 had a fix on day one. Teams on 9.18 from source had a migration project instead of a patch.
• Scoped dynamic update permissions. update-policy rules that grant each principal only the names it needs, and network placement that keeps signed update traffic off segments general clients can sniff, both make the capture step harder.
• A monthly patch slot for infrastructure daemons. ISC is now shipping security fixes monthly and attributes part of the volume to LLM assisted analysis. A quarterly change window for DNS no longer fits that rhythm. Our post on AI found vulnerabilities after PHP2Shell and PwnEscape covers what shorter windows mean for patch planning, and the October 2026 incident roundup shows the same pattern across other products.

Where Safeguard fits

Safeguard does not patch your DNS servers, detect exploitation on the wire, or change your firewall rules. A BIND server installed from an OS package on a VM is outside what Safeguard scans unless you scan it as part of an image or SBOM. Those steps are yours, using the vendor and distribution guidance above. Here is where it helps.

• See BIND in what you build. safeguard scan --image scans a container image, safeguard scan --sbom scans an SBOM file such as one an appliance vendor gives you, and safeguard scan --dir . scans a repository, with JSON results under ./output. If you ship DNS in containers, scanning the images shows their components and versions. Whether this specific advisory is matched depends on the vulnerability data for the OS package in question, so still confirm against the tables in this post.
• Answer "where is it" across projects. The platform shows which projects contain a given component and version, which turns an advisory into a list of affected images and products.
• Prioritise. Vulnerability matching against vulnerability databases, with reachability analysis for application code, helps you separate what needs attention today from the long tail.
• Stop regressions. Policies and gates evaluated in the platform, and safeguard exec in CI, can stop an image that still carries a vulnerable component from shipping after you have rebuilt.
• Do the change work with approval. The Safeguard CLI's assistant can edit files and run commands with your approval. You can ask it to bump a base image or package pin in your DNS Dockerfile, run named-checkconf, or draft the 9.18 to 9.20 configuration changes, and approve each step. Set /permissions to Ask or Strict for server work. The desktop and phone apps can send that work to a computer running the CLI and let you approve each command. Our post on the security aware coding assistant explains the permission modes.

Zero-Day Discovery and Gold

• Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode, and issues findings as SGZ advisories before they reach public CVE databases. It covers seven package ecosystems.
• Gold Open Source at gold.safeguard.sh is free with no login: CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, plus a free read API and a CI gate GitHub Action.
• Gold Registry at registry.safeguard.sh is the paid tier: hardened drop in components and container images held to zero exploitable critical or high CVEs, SLSA L3 or higher, Sigstore signed, with evidence pages. An artifact loses its badge if it regresses.

The habit they support is the one this advisory rewards: pull patched, signed components and images from a curated source, and be able to rebuild and redeploy within hours when an advisory lands. We are not claiming a Gold build of BIND exists for this CVE.

Common mistakes

• Reading the upstream version number on a distro package. A RHEL package called bind 9.16 or 9.18 may carry a backported fix; a Debian bookworm package at 9.18.49 is, as of 22 October, not fixed. Use dnf updateinfo and the Debian or Ubuntu trackers, not named -v alone.
• Assuming "we do not use GSS-TSIG" without checking. The Samba wiki's BIND9_DLZ instructions tell you to add tkey-gssapi-keytab, so many Samba DCs have it. Search the effective configuration with named-checkconf -p.
• Patching the binary and not restarting. The old process keeps running. rndc status and the process start time tell you what is live.
• Forgetting the container. A host package update does nothing for the named inside an image. Rebuild and redeploy.
• Treating 9.18 as "probably fine". ISC lists 9.18.50 as affected and the branch as end of life. If you depend on ISC for fixes, you need 9.20.
• Calling it exploited or critical in internal comms. That triggers the wrong playbook. It is High, not known to be exploited, and serious for Kerberos integrated DNS.
• Turning off RPZ or QNAME minimisation to dodge the DoS bugs. ISC lists no workaround. Patch instead.
• Restarting domain controller DNS in the middle of the day without warning. Plan it, start with secondaries, and test a signed update afterwards.

FAQ

Is CVE-2026-94300 being exploited?

ISC says it is not aware of any active exploits. CISA's SSVC entry records exploitation as none, and the CVE is not in CISA's KEV catalog as of 22 October. No source we read reports a public proof of concept.

Is this a critical, remote, unauthenticated RCE?

Not quite. ISC rates it High, CVSS 8.1, with attack complexity High. No privileges are needed in CVSS terms, but the attacker first has to capture a genuine GSS-TSIG signed UDP message and replay it while its key is valid, then send crafted queries involving a zone they control. ISC calls RCE potential.

My BIND server does not do dynamic updates. Am I affected?

For CVE-2026-94300, the vulnerable path requires GSS-TSIG, which you enable with tkey-gssapi-keytab or tkey-gssapi-credential. If neither appears in named-checkconf -p, that path is not in use. You should still upgrade, because CVE-2026-19630 affects resolvers without special configuration.

Who found it?

ISC says the flaw was found in its internal testing, and thanks Dave Aitel from OpenAI, who independently discovered and responsibly reported it. The RPZ and redirect bugs are credited to Vitaly Simonovich. ISC lists no external credit for CVE-2026-19630.

I run BIND 9.18. What now?

If your 9.18 comes from ISC or a source build, there is no fix and there will not be one: ISC ended 9.18 maintenance in June 2026 with 9.18.50. Move to 9.20.30. If it comes from a distribution, follow that distribution's tracker; Debian bookworm was still marked vulnerable on 22 October.

Is there a workaround?

ISC says none. Red Hat suggests disabling GSS-TSIG if you do not need it, or restricting port 53 to trusted segments, and warns that the first breaks Kerberos authenticated dynamic DNS updates.

Are the DoS bugs worth an emergency change on their own?

For resolvers, CVE-2026-19630 is the one to care about: a crafted message can exhaust CPU and memory, and there is no configuration precondition in ISC's text. The other two only matter with specific RPZ or redirect setups. Since all four are fixed in the same release, one upgrade covers them.

How do I know which version is actually running?

named -v shows the binary on disk. rndc status shows the running server's version and uptime. In containers, run the command inside the running container. On distro packages, the package changelog or dnf updateinfo shows whether the CVE is fixed even when the version string looks old.

Fix it without waiting for upstream

For BIND itself the fix has to come from ISC or your distribution, but the images and build pipelines that carry named are yours to rebuild. The same applies to every other open source component in them.

In incidents like this one, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

These are real product sessions on other examples. None of them shows this BIND advisory.

The CLI demo shows the assistant fixing a lodash CVE in a repository: it reads the finding and advisory, asks before each command, edits package.json, runs install and tests with your approval, and pushes nothing. For CVE-2026-94300 the same flow applies to the repository that builds your DNS container: ask it to move the image to a base or package with BIND 9.20.30, run named-checkconf against your configuration, and approve every command yourself.

Click through it at your own pace, or open it full screen.

The local runner demo shows setting up the runner on your own machine, approving it with its device code, and then scanning from the terminal. On 21 October that is how you would scan the DNS images and vendor SBOMs sitting on an internal build host, so the question "which of our images ship named" gets answered from your own network.

Click through it at your own pace, or open it full screen.

The mobile demo shows a real Android session that sends work to a computer running the CLI and approves a command on the phone with Allow once, Allow for turn or Deny. DNS restarts on domain controllers usually happen in an evening window; this is how the on call engineer can approve a version check or a restart from a phone without giving the assistant open permission.

Click through it at your own pace, or open it full screen.

To try it on your own systems, download Safeguard and read the CLI documentation.

Quick check

Sources

• ISC KB: CVE-2026-94300, Concurrent GSS-TSIG messages corrupt memory
• ISC KB: BIND 9 Security Vulnerability Matrix
• ISC KB: CVE-2026-19630, Amplified resource exhaustion in inbound message processing
• ISC KB: CVE-2026-97313, Specific RPZ configurations and query patterns may result in an unexpected exit
• ISC KB: CVE-2026-96888, named may terminate unexpectedly when a redirect zone is used with strict QNAME minimization
• ISC: BIND 9.20.30 change log
• ISC: Software downloads and branch status
• ISC blog: June 2026 release marks the End of Life for BIND 9.18
• bind-users: BIND 9.18 is now END of LIFE, bind-esv repos are changing
• Debian security tracker: CVE-2026-94300
• Debian DSA-6576-1: bind9 security update
• Red Hat: CVE-2026-94300
• Red Hat Bugzilla 2556407
• Amazon Linux Security Center: CVE-2026-94300
• Canadian Centre for Cyber Security: ISC BIND security advisory (AV26-1072)
• OpenCVE: CVE-2026-94300
• RFC 3645: GSS-TSIG
• Samba wiki: BIND9_DLZ DNS back end
• SecurityOnline: BIND 9 vulnerabilities, October 2026
• LinuxCompatible: ISC releases BIND 9.20.30 and 9.21.27

Last reviewed: 22 October 2026. This is a developing story; check the linked advisories for the latest status.