Servers, proxies and network services

ISC BIND 9: CVE-2026-94300 GSS-TSIG memory corruption

BIND check

Replaying a GSS-TSIG signed UDP message can corrupt memory in named, the BIND 9 name server. ISC says that, combined with crafted queries to a zone the attacker controls, it can lead to remote code execution, and at the least it can crash named. The attack is complex: the attacker must capture a signed message and replay it while the key is still valid.

CVE CVE-2026-94300 (published 21 October 2026, early notification 14 October)
Severity High, CVSS 8.1
Affected BIND 9.11.0 through 9.18.50, 9.20.0 through 9.20.29, 9.21.0 through 9.21.26, and matching -S1 Supported Preview builds
Fixed 9.20.30 and 9.21.27 (9.20.30-S1 for the Preview Edition)
Move to 9.20. 9.18 and older are end of life. A distribution that still supports 9.18 may backport the fix, and the script looks for that
Workaround ISC lists none
Exploited ISC says it is not aware of any active exploitation
Same release The same BIND releases fix three other denial of service flaws that only the update fixes

What decides your exposure. The vulnerable code is in every build, but the path needs GSS-TSIG, which is used for secure dynamic updates against Kerberos or Active Directory. One analysis says builds with no GSS-TSIG configured do not reach it. ISC's advisory text does not spell out which configuration is required, so the script reports whether GSS-TSIG is configured as a hint, never as proof of safety, and says to update either way.

Quick start

  1. Download the script. The repository is mirrored on GitHub and Codeberg; pick a base URL.

    # BASE from GitHub:   https://raw.githubusercontent.com/PrivacySafe/security-patches/refs/heads/main
    # BASE from Codeberg: https://codeberg.org/PrivacySafe/security-patches/raw/branch/main
    # curl -fLO "$BASE/bind/bind-check.sh"
    curl -fLO https://raw.githubusercontent.com/PrivacySafe/security-patches/refs/heads/main/bind/bind-check.sh
    
  2. Read it before running it, then make it executable.

    less bind-check.sh
    chmod +x bind-check.sh
    
  3. Check this host. It finds named on PATH, in the usual locations and from running processes, and reads the configuration file the running process was started with.

    ./bind-check.sh check
    ./bind-check.sh check /opt/bind9/sbin/named
    

Commands

Command What it does
check [BINARY ...] (default) Reads the version from named -v, applies ISC's ranges, reads named.conf and every file it includes (following include statements, with a loop guard), and searches for GSS-TSIG settings: tkey-gssapi-keytab, tkey-gssapi-credential, tkey-domain, and the krb5-* and ms-* rules in update-policy. It also notes whether the build was compiled with GSSAPI (--with-gssapi)
version Prints the script version

Environment: NAMED_CONF (space separated files) replaces configuration discovery.

Exit codes: 0 nothing exposed, 1 an affected version is exposed or its configuration could not be read, 2 bad arguments.

How to read the result

  • Affected version and GSS-TSIG configured: exposed. Upgrade.
  • Affected version, no GSS-TSIG setting found: exit 0 with a warning that you should update anyway. A text search can miss a setting generated elsewhere.
  • End-of-life branch (9.18 and older, or the 9.19 development line): always reported as affected with no upstream fix. If your distribution supports it, watch its security tracker. The script reads the package changelog for a mention of the CVE and treats a mention as a likely backport. At the time of writing, Debian 13 had shipped the fix in bind9 1:9.20.30-1~deb13u1, while the 9.18 packages were still shown as vulnerable.
  • Config unreadable: the script cannot tell, so it treats the host as exposed.
  • Preview Edition (-S1) and distribution suffixes such as 9.20.30-1~deb13u1 or 9.18.39-0ubuntu0.24.04.8-Ubuntu are read correctly.

Fixing it

Upgrade to 9.20.30 or 9.21.27, or to a distribution build that carries the fix, then restart named. ISC lists no workaround. If you do not use GSS-TSIG, removing those settings is our suggestion rather than ISC's, and it does not replace the update.

Sources

Before you run it

  • The fix. Update to 9.20.30 or 9.21.27 (9.20.30-S1 for the Preview Edition). ISC lists no workaround. The 9.18 branch and older are end of life and get no upstream fix. A distribution that still supports 9.18 may backport it, which the script looks for.
  • GSS-TSIG is a hint, not a verdict. The vulnerable path needs GSS-TSIG (used for secure dynamic updates against Kerberos or Active Directory), but ISC does not spell out which configuration is required. The script reports whether GSS-TSIG is configured and tells you to update either way.
  • It never reloads named. It finds named in PATH, the usual locations and running processes, reads the version from named -v and reads named.conf and its include files.
  • Other flaws ride along. The same releases fix three denial of service flaws that only the update fixes.
  • It also checks running docker and podman containers, unless you name a directory or set SCAN_CONTAINERS=0. A read-only probe inside each running docker and podman container captures the output of named -v and named -V and the configuration files (with every secret "..." value redacted inside the container before it is copied) into a private temporary directory. The script then runs once per container, in isolation, against that copy, so one container's configuration never changes another's result. include paths are resolved inside the container's copy, not on the host. The copies are removed on exit. A path shown as .../docker_NAME/... is inside the container NAME. It is skipped when you name a binary or directory yourself.

Red Hat advisories

Red Hat's advisory list (security advisories released 2026-04-01 to 2026-11-03) names the CVEs below. A Red Hat build is judged by its RPM release, not by the upstream version number, because Red Hat backports fixes: the advisory names the release that fixes it. A CVE with no advisory in the list has none for that period, which is not the same as not affected. The current state is on Red Hat's CVE database.

Advisory Released Severity Package and stream CVEs on this page
RHSA-2026:87309 2026-10-21 Important bind-9.20.30-0.1.hum1 (Hummingbird) CVE-2026-94300
RHSA-2026:92419 2026-10-29 Important bind-9.18.33-15.el10_2.14 (RHEL 10.2) CVE-2026-94300
RHSA-2026:93072 2026-10-30 Important bind9.18-9.18.29-14.el9_8.12 (RHEL 9.8) CVE-2026-94300
RHSA-2026:93610 2026-11-02 Important bind-9.16.23-40.el9_8.13 (RHEL 9.8) CVE-2026-94300
RHSA-2026:93925 2026-11-02 Important bind-9.11.36-18.el8_10 (RHEL 8.10) CVE-2026-94300
RHSA-2026:94011 2026-11-02 Important bind9.16-9.16.23-0.22.el8_10.21 (RHEL 8.10) CVE-2026-94300
RHSA-2026:94115 2026-11-03 Important bind-9.18.33-4.el10_0.6 (RHEL 10.0) CVE-2026-94300
RHSA-2026:94277 2026-11-03 Important bind9.16-9.16.23-0.7.el8_6.12 (RHEL 8.6) CVE-2026-94300
RHSA-2026:94278 2026-11-03 Important bind9.18-9.18.29-4.el9_6.5 (RHEL 9.6) CVE-2026-94300

The Security Patches software and this documentation are dedicated to the public domain under CC0 1.0 Universal. Other pages on privacysafe.app/docs are CC BY-SA 4.0 unless the page says otherwise.

Edit this page on Codeberg

The PrivacySafe Ecosystem

Shop at Ivy Cyber

Ivy Cyber offers PrivacySafe products and services in the USA and has partnerships with 3NSoft in Canada and Kuip Limited in the European Union. Enterprise services and consulting are available at ivycyber.com

PrivacySafe Foundation is a 501(c)(3) nonprofit public charity that supports the development of the PrivacySafe applications, along with the components they rely upon: 3NWeb protocols, filesystem, documentation, and reference implementations.

PrivacySafe Foundation

Donations to PrivacySafe Foundation support education, research, documentation, and public code. Purchases from Ivy Cyber support PrivacySafe products, services, hosting, and technical support. Together, we're building a better web.