CVE-2026-94300 · ISC BIND 9 GSS-TSIG concurrent UDP message replay double-free

01 · The Real Story

This is a bank heist that only works if the vault uses a rare lock model that 90% of banks never installed

CVE-2026-94300 is a race condition in ISC BIND 9 (versions 9.11.0–9.18.50, 9.20.0–9.20.29, 9.21.0–9.21.26) that triggers a double-free (CWE-415) when named processes replayed GSS-TSIG signed UDP messages concurrently. An attacker who captures a legitimately signed GSS-TSIG UDP DNS message can replay it while the negotiated TSIG key remains valid. By simultaneously sending crafted queries to an attacker-controlled zone, the race condition corrupts heap memory via a double-free, potentially enabling remote code execution on the DNS server. The underlying flaw lives in the Kerberos-based GSS-TSIG authentication path — specifically the concurrent handling of TKEY negotiation messages. Dave Aitel of OpenAI independently discovered and responsibly disclosed this to ISC.

ISC rates this HIGH at CVSS 8.1, which is technically accurate for the narrow population running GSS-TSIG but misleading for the broader BIND installed base. The critical detail buried in the advisory: *in a configuration which uses BIND's default settings the vulnerable code path is not exposed.* You must explicitly set tkey-gssapi-keytab or tkey-gssapi-credential in named.conf to become vulnerable. GSS-TSIG is a niche feature used almost exclusively in BIND-with-Samba or BIND-with-FreeIPA integrations alongside Active Directory. The vast majority of BIND resolvers and authoritative servers — including the millions visible on Shodan port 53 — never touch this code path. The vendor severity of 8.1 is honest about the theoretical impact but silent about the configuration prerequisite that shields ~90% of real-world deployments.

"Non-default GSS-TSIG config + network capture + race = theoretical RCE most BIND shops can't reach"

02 · The Attack Path

4 steps from start to impact.

STEP 01

Identify BIND target with GSS-TSIG enabled

The attacker must locate a BIND 9 instance that has GSS-TSIG explicitly configured via tkey-gssapi-keytab or tkey-gssapi-credential. This is not reliably detectable remotely through standard DNS fingerprinting — the attacker needs prior knowledge of the environment's DNS architecture or must attempt TKEY negotiation probes and observe responses. In practice this means reconnaissance, insider knowledge, or post-compromise enumeration of named.conf.

Conditions required:

Target runs BIND 9.11.0–9.18.50, 9.20.0–9.20.29, or 9.21.0–9.21.26
Target has GSS-TSIG explicitly configured (non-default)

Where this breaks in practice:

GSS-TSIG is not enabled in default BIND configurations — estimated <10% of BIND deployments use it
Feature is almost exclusively found in AD-integrated environments (Samba/FreeIPA), dramatically narrowing the target set

Detection/coverage: Configuration audit via named-checkconf or grep for tkey-gssapi directives in named.conf; TKEY probe attempts visible in query logs

STEP 02

Capture a valid GSS-TSIG signed UDP message

The attacker must intercept a legitimately signed GSS-TSIG UDP DNS message on the wire. This requires a network position enabling packet capture — either adjacent on the same broadcast domain, via ARP spoofing, through a compromised network tap, or from a previously compromised host on the same subnet. DNS over UDP is unencrypted so the capture itself is trivial once positioned, but gaining position is the real obstacle. No known tooling automates this step specific to GSS-TSIG capture.

Conditions required:

Network position to capture DNS UDP traffic to/from the target
A valid GSS-TSIG TKEY negotiation must occur while the attacker is listening

Where this breaks in practice:

Requires adjacent network access or prior compromise — this is a post-initial-access prerequisite for any external attacker
Encrypted DNS transports (DoT/DoH) between endpoints would prevent capture, though internal BIND-to-BIND traffic typically uses plain UDP
Modern network segmentation and microsegmentation limits lateral sniffing

Detection/coverage: ARP spoofing detection via DAI; promiscuous-mode NIC alerts from EDR agents; unusual pcap/tcpdump process execution

STEP 03

Replay message and trigger the race condition

The captured GSS-TSIG signed message must be replayed to the BIND server while the negotiated TSIG key is still valid. Kerberos ticket lifetimes (typically 8–10 hours, configurable) define this window. The attacker replays the exact UDP packet while simultaneously sending additional TKEY or crafted queries to force concurrent processing in named, creating the race condition that leads to the double-free. The timing must be precise — the race window is narrow and non-deterministic.

Conditions required:

TSIG key still within Kerberos ticket lifetime
Attacker can send UDP packets to the BIND server on port 53
Timing precision to hit the narrow race window between concurrent message handlers

Where this breaks in practice:

Race conditions are inherently probabilistic — multiple attempts may be needed, each risking detection
BIND's internal locking and message ordering may close the window on many attempts
Each failed race attempt may crash named (DoS), generating alerts before RCE is achieved

Detection/coverage: Duplicate TKEY message detection in DNS query logs (same message-ID replayed); anomalous burst of TKEY negotiations from a single source; BIND crash/restart events in systemd journal

STEP 04

Exploit double-free for code execution

The race condition causes named to free the same heap region twice (CWE-415). By controlling the content of DNS queries sent to an attacker-controlled zone (forcing named to allocate attacker-influenced data into the freed region), the attacker attempts to hijack execution flow. On modern 64-bit Linux systems with ASLR and hardened allocators, this is non-deterministic and typically requires heap grooming. The ISC advisory describes this as *potential* remote code execution — many attempts will simply crash named rather than achieve clean shell.

Conditions required:

Attacker controls a DNS zone the target BIND server will query (requires recursion or forwarding enabled toward attacker infrastructure)
Heap layout must be favorable; ASLR and allocator hardening must be bypassed or tolerated

Where this breaks in practice:

ASLR on modern 64-bit Linux makes heap exploitation non-deterministic
BIND compiled with jemalloc or hardened glibc further degrades reliability
Failed exploitation crashes named, which systemd auto-restarts — but each crash produces core dumps and journal entries
ISC advisory explicitly says 'potential' RCE, not 'reliable' RCE; no known weaponized exploit exists

Detection/coverage: Core dumps with double-free signatures; ASAN/MSAN builds catch the corruption immediately; unexpected named restarts visible in systemctl status named and monitoring

03 · Compensating Control

MEDIUM 5.9→IGNORE 0.0

SEVERITY REDUCED

Disable GSS-TSIG if not actively required — Comment out or remove tkey-gssapi-keytab and tkey-gssapi-credential directives from named.conf, then run rndc reconfig or restart named. This completely eliminates the vulnerable code path without upgrading BIND. Verify removal with named-checkconf -p | grep tkey-gssapi. If your BIND instance serves only as a resolver or authoritative server without AD dynamic update integration, you almost certainly do not need GSS-TSIG. No mitigation SLA applies at MEDIUM severity — deploy as part of your next change window and proceed to the 365-day remediation window for the actual patch.

MEDIUM 5.9→IGNORE 0.0

SEVERITY REDUCED

Migrate dynamic updates from GSS-TSIG to TSIG shared secrets (RFC 2845) — If authenticated dynamic DNS updates are required but Kerberos-based GSS-TSIG can be replaced, configure TSIG with pre-shared HMAC-SHA256 keys instead. This uses a completely separate code path unaffected by CVE-2026-94300. Requires key generation (tsig-keygen), distribution to update clients, and named.conf reconfiguration. Schedule within the 365-day noisgate remediation SLA for MEDIUM severity.

MEDIUM 5.9→IGNORE 0.0

SEVERITY REDUCED

Upgrade to BIND 9.20.30 or 9.21.27 — Apply the vendor patch to fully remediate. For 9.18.x users: there is no 9.18.x fix — ISC requires migration to 9.20.30+. For distro packages (RHEL, Debian, Ubuntu, SUSE), monitor your vendor's security tracker; packages typically land 3–7 days after ISC release. At MEDIUM severity with no noisgate mitigation SLA, target the 365-day noisgate remediation SLA — but prioritize if you confirmed GSS-TSIG is enabled.

MEDIUM 5.9→LOW 3.2

SEVERITY REDUCED

Restrict network access to BIND on port 53/UDP via ACL and host firewall — Use iptables/nftables or network ACLs to limit which source IPs can reach the BIND server on port 53. In AD-integrated environments, restrict to known AD member hosts and Samba servers only. This degrades the attacker's ability to both sniff GSS-TSIG traffic and replay messages, but does not eliminate risk if the attacker has already compromised an allowed host. Deploy within the 365-day remediation window.

What doesn't work

WAF — This is a DNS/UDP vulnerability, not HTTP. Web application firewalls do not inspect DNS traffic and provide zero protection against CVE-2026-94300.
DNSSEC — DNSSEC validates zone data integrity (cryptographic signatures on RRsets), not the transport-layer GSS-TSIG authentication mechanism. It does not prevent message replay or the double-free race condition.
DNS Response Rate Limiting (RRL) — RRL throttles outbound DNS responses to prevent reflection/amplification attacks. It does not limit inbound GSS-TSIG TKEY message processing or prevent the race condition.
Standard volumetric rate limiting on port 53 — The attack requires only a small number of precisely timed packets, not high volume. Typical rate-limit thresholds will not intercept the exploitation traffic pattern.

04 · Intelligence Metadata

The supporting signals.

In-the-wild exploitation	None known. ISC states they are "not aware of any active exploits." No GreyNoise tags or Shadowserver scanning campaigns observed as of 2026-10-22. This CVE is <48 hours old.
Proof of concept	None public. No PoC on pocindex.io, no GitHub repositories named after this CVE, no Nuclei templates, no ExploitDB or Metasploit modules as of 2026-10-22. The race condition + double-free chain is non-trivial to weaponize — prior GSS-TSIG CVEs (CVE-2021-25216) never produced reliable public exploits either.
EPSS score	Not yet scored. FIRST EPSS API returns empty dataset — expected for a CVE disclosed <48 hours ago. Historical BIND GSS-TSIG CVEs (CVE-2021-25216) peaked around EPSS 0.05–0.08 (~85th percentile), suggesting moderate-low exploitation probability once scored.
CISA KEV status	Not listed in the Known Exploited Vulnerabilities catalog as of 2026-10-22.
CVSS vector interpretation	`CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H` — AC:H is the critical modifier, dropping the score from 9.8 to 8.1. Reflects the race condition timing requirement. Full CIA:H reflects the RCE potential. The vector does not capture the non-default `tkey-gssapi-keytab`/`tkey-gssapi-credential` configuration prerequisite, which is the single largest real-world friction factor.
Affected versions	BIND 9.11.0–9.18.50, 9.20.0–9.20.29, 9.21.0–9.21.26. SPE: 9.11.3-S1–9.18.50-S1, 9.20.9-S1–9.20.29-S1. Critical note: the 9.18.x branch has no fix — ISC recommends migration to 9.20.30+ for 9.18 users.
Fixed versions	BIND 9.20.30, 9.21.27, 9.20.30-S1 (SPE). Distro backports: monitor RHEL/CentOS, Debian, Ubuntu, SUSE security trackers — packages typically lag 3–7 days for ISC advisories. The 9.18.x branch is end-of-line for this fix.
Internet exposure	Shodan indexes ~1.15M hosts with port 53/TCP banners globally. BIND is the dominant authoritative server software. However, GSS-TSIG is an opt-in feature for AD-integrated environments — the overwhelming majority of internet-facing BIND instances are authoritative-only or public resolvers that do not enable GSS-TSIG. The actually-vulnerable internet surface is a small fraction.
Disclosure context	Disclosed 2026-10-21 as part of a coordinated quad-CVE BIND advisory (CVE-2026-94300 at 8.1, CVE-2026-19630/CVE-2026-97313/CVE-2026-96888 at 7.5 each). CVE-2026-94300 is the only one with RCE potential; the others are DoS.
Reporter	Dave Aitel (OpenAI) — independently discovered and responsibly disclosed to ISC. Aitel is a well-known vulnerability researcher (former NSA, founder of Immunity Inc., creator of CANVAS exploitation framework).

Sources.

05 · The Call

Final Verdict

↓ DOWNGRADED to MEDIUM (5.9/10)

Why this verdict

Non-default configuration eliminates ~90% of targets. GSS-TSIG requires explicitly setting tkey-gssapi-keytab or tkey-gssapi-credential in named.conf. BIND's default config does not expose the vulnerable code path. Only BIND deployments integrated with Active Directory via Samba or FreeIPA typically enable this feature. The ISC advisory itself states: 'In a configuration which uses BIND's default settings the vulnerable code path is not exposed.' The vendor CVSS base score has no mechanism to express 'only applies if you opted into a niche feature.' This is the primary downgrade driver: −1.2 from the base.
Network capture prerequisite implies post-initial-access. The attacker must intercept a valid GSS-TSIG signed UDP message on the wire. For any external attacker, this requires an existing foothold on the internal network — adjacent LAN segment, compromised host, or network TAP access. The DNS server is not the initial access vector here; the attacker is already inside. This compounds with the first friction point and represents an additional −0.5 adjustment.
Race condition + double-free = probabilistic, not deterministic. AC:H in the CVSS vector partially accounts for this, but real-world exploitation against modern 64-bit Linux with ASLR, stack canaries, and hardened allocators (jemalloc in many BIND builds) is even less reliable than AC:H implies. ISC describes RCE as 'potential,' not guaranteed. Many attempts produce a crash (DoS) rather than a shell. An additional −0.3 adjustment.
Zero weaponization evidence at day one. No PoC on pocindex.io, GitHub, ExploitDB, or Metasploit. No ITW exploitation. Not KEV-listed. EPSS not yet scored, but the prior GSS-TSIG CVE (CVE-2021-25216, same code area, 2021) never produced a reliable public exploit despite being known for 5+ years. The exploit development barrier is high. −0.2 adjustment.
Role multiplier: BIND with GSS-TSIG in AD-adjacent environments. The subset of BIND servers running GSS-TSIG (~5–10% of BIND installations) are by definition in AD-integrated environments (Samba, FreeIPA). Compromising such a DNS server yields host-level RCE and the ability to manipulate DNS resolution within the domain — meaningful for redirecting authentication traffic and enabling lateral movement. However, this falls short of direct domain takeover: the attacker gains a foothold on infrastructure *adjacent* to AD, not on a domain controller or identity provider. Blast radius is host → network-level DNS manipulation, requiring further lateral movement for domain compromise. BIND is not canonically a high-value-role component per the catalog (not a DC, IdP, hypervisor, PAM, CA, or edge appliance), and the chain does not directly produce fleet-scale or identity-scale impact. The floor does not override the friction-based downgrade to MEDIUM.

Why not higher?

The vendor's 8.1 HIGH reflects genuine impact *if successfully exploited against a GSS-TSIG-enabled target*. But the CVSS base score cannot express the non-default configuration gate that removes the vast majority of BIND installations from the vulnerable population. With no PoC, no ITW exploitation, a multi-step chain requiring internal network position, probabilistic exploitation via a race condition, and a feature that must be explicitly opted into — there is no justification for maintaining HIGH severity fleet-wide. Even for the AD-integrated subset, the chain ends at host-level RCE on the DNS server, not direct domain compromise.

Why not lower?

For the ~5–10% of BIND installations that DO run GSS-TSIG, this is a genuine pre-auth RCE vector from an internal network position. DNS infrastructure compromise in an AD environment is a meaningful security event — an attacker controlling DNS can redirect Kerberos, LDAP, and authentication traffic, poison zone data, and create conditions for credential theft. The double-free primitive, while unreliable, has been weaponized in similar contexts before. Dave Aitel's discovery further signals that competent exploitation analysis has occurred. Dropping below MEDIUM would undercount the risk for the affected subset and leave AD-integrated BIND-Samba shops without an appropriate signal.

06 · Verification

Crowdsourced verification payload.

Run on each BIND host as root (or a user with read access to named.conf). Invoke: sudo bash cve-2026-94300-check.sh. The script checks both the BIND version AND whether GSS-TSIG is configured — both conditions must be true for exploitability. Exit code 1 = VULNERABLE, 0 = PATCHED/not exploitable, 2 = UNKNOWN.

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/usr/bin/env bash
# CVE-2026-94300 Vulnerability Checker — noisgate
# Checks BIND version + GSS-TSIG configuration status
# Exit codes: 0=PATCHED/NOT_VULNERABLE  1=VULNERABLE  2=UNKNOWN
set -uo pipefail

NAMED=$(command -v named 2>/dev/null || true)
if [[ -z "$NAMED" ]]; then
  echo "UNKNOWN - named binary not found; BIND may not be installed"
  exit 2
fi

VERSION=$("$NAMED" -v 2>/dev/null | grep -oP 'BIND \K[0-9]+\.[0-9]+\.[0-9]+' || true)
if [[ -z "$VERSION" ]]; then
  echo "UNKNOWN - could not parse BIND version"
  exit 2
fi

IFS='.' read -r MAJ MIN PAT <<< "$VERSION"
echo "[*] BIND version: $VERSION"

# Check affected version ranges
AFFECTED=false
if [[ "$MAJ" -eq 9 ]]; then
  if [[ "$MIN" -ge 11 && "$MIN" -le 17 ]]; then AFFECTED=true; fi
  if [[ "$MIN" -eq 18 && "$PAT" -le 50 ]]; then AFFECTED=true; fi
  if [[ "$MIN" -eq 20 && "$PAT" -le 29 ]]; then AFFECTED=true; fi
  if [[ "$MIN" -eq 21 && "$PAT" -le 26 ]]; then AFFECTED=true; fi
fi

if [[ "$AFFECTED" == "false" ]]; then
  echo "PATCHED - BIND $VERSION is outside the affected range"
  exit 0
fi

echo "[!] Version $VERSION is in the affected range"

# Locate named.conf
CONF=""
for F in /etc/named.conf /etc/bind/named.conf /usr/local/etc/named.conf \
         /usr/local/etc/namedb/named.conf /etc/named/named.conf; do
  [[ -f "$F" ]] && CONF="$F" && break
done
if [[ -z "$CONF" ]]; then
  echo "UNKNOWN - cannot locate named.conf; version affected but GSS-TSIG status undetermined"
  exit 2
fi
if [[ ! -r "$CONF" ]]; then
  echo "UNKNOWN - found $CONF but cannot read (need root or named group)"
  exit 2
fi

echo "[*] Scanning $CONF for GSS-TSIG directives..."

GSS=false
check_file() {
  local f="$1"
  [[ -r "$f" ]] || return 0
  if grep -qE '^[^/]*[^#]*tkey-gssapi-(keytab|credential)' "$f" 2>/dev/null; then
    GSS=true
    echo "[!] GSS-TSIG directive found in: $f"
  fi
  while IFS= read -r inc; do
    [[ -r "$inc" ]] && check_file "$inc"
  done < <(grep -oP '^[^#]*include\s+"\K[^"]+' "$f" 2>/dev/null || true)
}
check_file "$CONF"

if [[ "$GSS" == "true" ]]; then
  echo "VULNERABLE - BIND $VERSION with GSS-TSIG enabled (CVE-2026-94300)"
  echo "  -> Upgrade to 9.20.30+/9.21.27+ or disable tkey-gssapi-keytab/credential"
  exit 1
else
  echo "PATCHED - BIND $VERSION affected but GSS-TSIG NOT configured (code path not exposed)"
  echo "  -> Version upgrade still recommended; CVE not currently exploitable"
  exit 0
fi