A BIND server that accepts Kerberos-signed dynamic updates is the one CVE-2026-94300 goes after. ISC published the flaw on 21 October 2026 with a CVSS score of 8.1. An attacker who captures one GSS-TSIG signed UDP message can replay it while the negotiated key is still valid and corrupt memory in named, and ISC warns that crafted queries alongside the replay may reach remote code execution. Red Hat places the risk on servers with GSS-TSIG configured, so your first check is a grep for two directives, not a version string.
Below are the fixed BIND 9 packages for Debian, RHEL, Rocky Linux, AlmaLinux and Amazon Linux 2023, the upgrade on each, and two interim controls for Debian 12, Ubuntu and the EL8 and EL9 base packages, which have no fix yet. Every command shown ran in November 2026 on Debian 13 and AlmaLinux 10 lab VMs, with SELinux enforcing on the Alma box and the other distros checked in containers, so no step turns a security control off.
Fixed BIND packages for CVE-2026-94300
Compare the package release, not the upstream number named -v prints. RHEL 10 and Amazon Linux 2023 stay on BIND 9.18, a branch for which ISC’s CVE-2026-94300 advisory lists no fixed release, so their fix is a backport inside an old-looking version. Rows marked “Lab” were installed or queried on our test machines on 1 November 2026.
| Distro | Release | Package | Fixed build | Advisory | Checked |
|---|---|---|---|---|---|
| Debian | 13 trixie | bind9 | 1:9.20.30-1~deb13u1 | DSA-6576-1 | Lab |
| Debian | 14 forky / sid | bind9 | 1:9.20.30-1 | Tracker | Tracker |
| Debian | 12 bookworm | bind9 | No fix (1:9.18.49-1~deb12u3 is vulnerable) | None yet | Lab |
| Ubuntu | 26.04 LTS, 24.04 LTS | bind9 | No fix (1:9.20.24-1ubuntu0.4 and 1:9.18.39-0ubuntu0.24.04.8 in the archive) | None yet | Lab |
| RHEL | 10 | bind | 32:9.18.33-15.el10_2.14 | RHSA-2026:92419 | Advisory |
| Rocky Linux | 10 | bind | 32:9.18.33-15.el10_2.14 | RLSA-2026:92419 | Lab |
| AlmaLinux | 10 | bind | 32:9.18.33-15.el10_2.14 | ALSA-2026:92419 | Lab |
| RHEL | 9 | bind9.18 | 32:9.18.29-14.el9_8.12 | RHSA-2026:93072 | Advisory |
| AlmaLinux | 9 | bind9.18 | 32:9.18.29-14.el9_8.12 | ALSA-2026:93072 | Lab |
| Rocky Linux | 9 | bind9.18 | No fix yet (.el9_8.11 in the repos) | None yet | Lab |
| RHEL, Rocky, Alma | 9 | bind (9.16 base) | No fix, listed as affected | None yet | Advisory |
| RHEL, Rocky, Alma | 8 | bind, bind9.16 | No fix, listed as affected | None yet | Advisory |
| Amazon Linux | 2023 | bind | 32:9.18.50-1.amzn2023.0.5 | ALAS2023-2026-3312 | Lab |
| Amazon Linux | 2 | bind | 9.11.4-26.P2.amzn2.13.20 | ALAS2-2026-4038 | Advisory |
| ISC upstream | 9.20, 9.21, Supported Preview | BIND 9 | 9.20.30, 9.21.27, 9.20.30-S1 | ISC KB | Advisory |
Three groups have nothing to install yet. They are Debian 12, every Ubuntu release (the Ubuntu CVE page lists 20.04 through 26.10 as vulnerable), and the 9.16-based bind package on RHEL 8 and 9 and their rebuilds, while Rocky Linux 9 also lags AlmaLinux 9 on bind9.18. If your server is in one of those groups and has GSS-TSIG configured, go straight to the interim controls near the end. Keep this table bookmarked, because the Debian security tracker and the Red Hat pages are where the late packages will show up.
The conditions behind the replay
GSS-TSIG is how BIND authenticates DNS updates with Kerberos. Windows domain members use it to register their own A and PTR records, and so do FreeIPA clients and Samba AD domain controllers that run BIND as their DNS backend. The vulnerable path sits in how named handles those signed messages over UDP, and the attack needs every one of these to hold:
- The loaded
namedconfig carriestkey-gssapi-keytabortkey-gssapi-credential. - The attacker has captured a GSS-TSIG signed UDP message sent to that server.
- The attacker can send that message back to port 53 before the negotiated TSIG key expires.
That chain is why the vector reads AV:N/AC:H with no privileges and no user interaction. High complexity is not the same as low risk, though: the worst case ISC names is code execution on the box that holds your zones, and the realistic case is a crash that takes internal name resolution down. Red Hat rates it Important and says plainly that standard RHEL deployments do not enable GSS-TSIG, which concentrates the exposure on servers joined to FreeIPA or Active Directory.
On urgency, the public signals are quiet. ISC says it is not aware of any active exploits, the CVE is not in CISA’s Known Exploited Vulnerabilities catalog, and FIRST scored its EPSS at 0.00953 on 31 October 2026. ISC found the bug in internal testing, and it was reported independently by Dave Aitel of OpenAI. None of that buys you time on a domain DNS server, where one successful replay hits every machine that resolves through it. Patch those this week. A recursive resolver with no GSS-TSIG directive can wait for its normal update window.
Windows Server DNS is a different product and is not covered by this CVE. If your AD zones live on domain controllers set up the way our Windows Server DNS server guide or the secondary DNS setup on Windows Server describes, only the Linux BIND servers in your estate are in scope. The same goes for PowerDNS, which our PowerDNS Admin install on Ubuntu uses as its backend.
GSS-TSIG directives in the running config
The fastest exposure check asks named-checkconf to print the config it would load, with every include expanded, and filters it for the two directives. That catches a directive buried in an include file such as one FreeIPA or a Samba provisioning script wrote, which a plain grep of named.conf would miss. On Debian the tool reads /etc/bind/named.conf, and on the RHEL family /etc/named.conf.
sudo named-checkconf -p | grep -E 'tkey-gssapi-(keytab|credential)'Pair it with the installed package version. On Debian 13 the lab box was still on the trixie point-release build and returned one keytab line, which makes it both vulnerable and exposed:
An empty result means the GSS-TSIG code path is not configured, and you can patch on your normal schedule. If you run the chrooted service (named-chroot) on the RHEL family, point the tool at the chroot with -t /var/named/chroot, because the copy outside the chroot may not be the one in use. The same check on an AlmaLinux 10 server, with a recursive grep to find which file holds the line and the pending advisory for the CVE:
rpm -q bind bind-libs
sudo grep -rnE 'tkey-gssapi-(keytab|credential)' /etc/named.conf /etc/named/
sudo dnf updateinfo list --cve CVE-2026-94300The box was on the .13 build, the directive sat on line 14 of /etc/named.conf, and dnf already knew which advisory fixes it.
Last, see who can reach port 53. The replayed message travels over UDP, so check UDP listeners as well as TCP. A server that answers on a LAN address is reachable from that whole segment, and the replay needs nothing more than that:
sudo ss -tulnp 'sport = :53'Next to loopback and the systemd-resolved stub, the Debian lab server bound UDP and TCP on its LAN address, so any host on that subnet could talk to it. We cut four IPv6 link-local lines because they embed the NIC’s MAC address.
Netid State Recv-Q Send-Q Local Address:Port Peer Address:PortProcess
udp UNCONN 0 0 192.168.1.50:53 0.0.0.0:* users:(("named",pid=2397,fd=25))
udp UNCONN 0 0 192.168.1.50:53 0.0.0.0:* users:(("named",pid=2397,fd=24))
udp UNCONN 0 0 127.0.0.1:53 0.0.0.0:* users:(("named",pid=2397,fd=19))
udp UNCONN 0 0 127.0.0.1:53 0.0.0.0:* users:(("named",pid=2397,fd=18))
udp UNCONN 0 0 127.0.0.54:53 0.0.0.0:* users:(("systemd-resolve",pid=334,fd=20))
udp UNCONN 0 0 127.0.0.53%lo:53 0.0.0.0:* users:(("systemd-resolve",pid=334,fd=18))
udp UNCONN 0 0 [::1]:53 [::]:* users:(("named",pid=2397,fd=28))
udp UNCONN 0 0 [::1]:53 [::]:* users:(("named",pid=2397,fd=29))
tcp LISTEN 0 4096 127.0.0.54:53 0.0.0.0:* users:(("systemd-resolve",pid=334,fd=21))
tcp LISTEN 0 10 127.0.0.1:53 0.0.0.0:* users:(("named",pid=2397,fd=22))
tcp LISTEN 0 10 127.0.0.1:53 0.0.0.0:* users:(("named",pid=2397,fd=20))
tcp LISTEN 0 10 192.168.1.50:53 0.0.0.0:* users:(("named",pid=2397,fd=27))
tcp LISTEN 0 10 192.168.1.50:53 0.0.0.0:* users:(("named",pid=2397,fd=26))
tcp LISTEN 0 4096 127.0.0.53%lo:53 0.0.0.0:* users:(("systemd-resolve",pid=334,fd=19))
tcp LISTEN 0 10 [::1]:53 [::]:* users:(("named",pid=2397,fd=30))
tcp LISTEN 0 10 [::1]:53 [::]:* users:(("named",pid=2397,fd=31))When the version is in the affected range, a GSS-TSIG directive is loaded and named listens beyond loopback, that server goes to the top of your patch list.
The bind9 upgrade on Debian 13
DSA-6576-1 ships the fix through trixie-security, so a host without that suite in its sources will never see it. Refresh the package lists and confirm the security build is offered before you touch anything:
sudo apt update
apt list --upgradable 2>/dev/null | grep bind9
apt-get changelog bind9 | head -12All five bind9 packages came from stable-security, and the changelog lists CVE-2026-94300 next to three other BIND CVEs that this release also closes. Debian’s wording, “Prevent concurrent GSS-TSIG traffic from terminating named”, matches the title of ISC’s advisory rather than its replay description:
Upgrade the BIND packages together. Leaving bind9-libs behind is the usual way to end up with a new daemon linked against old code, and --only-upgrade stops apt from installing any of the named packages that are not on the box already:
sudo apt-get install -y --only-upgrade bind9 bind9-libs bind9-utils bind9-dnsutils bind9-hostThen confirm what is running, not only what is installed.
/usr/sbin/named -v
systemctl status named --no-pager -l | head -6The Debian package restarted named on its own during the upgrade, which is why the status line reads “4s ago” and the version string shows the deb13u1 security build. The keytab directive was still loaded, so GSS-TSIG stayed configured on the patched daemon:
If the start time in that status output is older than the upgrade, the old binary is still in memory and the server is still vulnerable. Restart it with sudo systemctl restart named and check again.
The bind update on RHEL, Rocky Linux and AlmaLinux 10
All three EL10 distros carry the same fixed build, 32:9.18.33-15.el10_2.14, under advisories that share a number: RHSA-2026:92419 on RHEL, RLSA-2026:92419 on Rocky Linux and ALSA-2026:92419 on AlmaLinux. Upgrading by advisory pulls exactly the packages that advisory covers and nothing else, which suits a change window on a DNS server. On AlmaLinux:
sudo dnf -y upgrade --advisory ALSA-2026:92419Use your own distro’s ID in the same command on RHEL or Rocky Linux. The RPM restarts named on upgrade as well, but an explicit restart costs a second and removes any doubt about which binary is in memory. Then confirm the changelog carries the fix:
sudo systemctl restart named
rpm -q bind bind-libs
rpm -q --changelog bind | grep -m1 -B1 CVE-2026-94300The transaction moved five packages to .el10_2.14, and Red Hat’s changelog entry describes the fix as preventing “arbitrary code execution via GSS-TSIG UDP message replay”. That is stronger language than Debian’s, and it lines up with the RCE warning in ISC’s description.
The capture also shows the lab host’s named.conf being restored from the backup taken during the mitigation step later in this guide, which put the keytab line back. Run systemctl restart named-chroot instead if the chrooted unit is the one you enable.
The EL9 split between bind and bind9.18
EL9 ships two BIND packages, and only one of them is fixed. The default bind is the 9.16 branch, which Red Hat lists as affected with no fix. The optional bind9.18 package got RHSA-2026:93072, and AlmaLinux rebuilt it as ALSA-2026:93072 on 30 October. Rocky Linux 9 had not shipped it when we checked on 1 November: its repos still held the .11 build, and that build’s changelog has no entry for the CVE. Find out which package your server runs before you plan anything:
rpm -q bind bind9.18Containers on the lab host give the repo state for each distro in one view. Amazon Linux 2023 and Rocky Linux 10 offer their fixed builds, AlmaLinux 9’s bind9.18 changelog names the CVE once, and Rocky Linux 9’s names it zero times:
On RHEL 9 or AlmaLinux 9 with bind9.18, upgrade it with dnf by advisory as on EL10, using RHSA-2026:93072 or ALSA-2026:93072, then restart. On the base bind package, or on Rocky Linux 9 today, switching packages is not a patch. Moving from 9.16 to 9.18 is a branch migration with its own config changes, and doing it during an incident is how DNS outages start. Apply the interim controls instead, and plan the move separately if you want off 9.16. Red Hat also lists EL9’s dhcp package as affected because it links BIND’s libraries; it doesn’t run a GSS-TSIG listener, but it will show up in scanner reports for this CVE.
The Amazon Linux 2023 backport
Amazon Linux 2023 is the case that confuses scanners. Its fixed package is 9.18.50, a number inside ISC’s affected range, because Amazon backported the fix rather than moving to 9.20. ALAS2023-2026-3312 also bundles CVE-2026-19630, CVE-2026-19668, CVE-2026-77119, CVE-2026-96888 and CVE-2026-97313. AL2023 versions its repositories, so a host locked to an older release will not see the update until you ask for the latest one.
sudo dnf --releasever=latest updateinfo list --cve CVE-2026-94300
sudo dnf -y upgrade --releasever=latest bind
rpm -q --changelog bind | grep -m1 CVE-2026-94300The container started on the .0.4 build, the advisory listed five packages, and after the upgrade the changelog line named CVE-2026-94300 among the BIND fixes in .0.5:
ALAS2023-2026-3312 Important/Sec. bind-32:9.18.50-1.amzn2023.0.5.x86_64
ALAS2023-2026-3312 Important/Sec. bind-dnssec-utils-32:9.18.50-1.amzn2023.0.5.x86_64
ALAS2023-2026-3312 Important/Sec. bind-libs-32:9.18.50-1.amzn2023.0.5.x86_64
ALAS2023-2026-3312 Important/Sec. bind-license-32:9.18.50-1.amzn2023.0.5.noarch
ALAS2023-2026-3312 Important/Sec. bind-utils-32:9.18.50-1.amzn2023.0.5.x86_64
bind-9.18.50-1.amzn2023.0.5.x86_64
- Fix CVE-2026-94300, CVE-2026-97313, CVE-2026-96888, CVE-2026-19630For a fleet pinned to a release version, the advisory itself gives the pinned form, dnf update --advisory ALAS2023-2026-3312 --releasever 2023.12.20261026, which moves only to the release that carries the fix. Restart named afterwards as on the other RPM distros. If your scanner still flags the host on version number alone, the changelog line is the evidence to attach to the exception.
Interim controls for hosts without a fix
ISC lists no workaround. Red Hat’s CVE page gives two mitigations, which are to remove the GSS-TSIG directives and restart, or to restrict DNS to trusted networks with a firewall. Which one fits depends on what the server does, and the choice should leave each host in one of these states:
- A server that takes no Kerberos updates has its GSS-TSIG directives commented out.
- A DNS server for AD, FreeIPA or Samba keeps GSS-TSIG and answers port 53 only from an allow-list.
- Each control has a ticket to undo it once the fixed package is installed.
Running both controls on a server that needs neither Kerberos updates nor wide access is fine, and it is the tightest position until the package lands.
Read this before disabling GSS-TSIG on a domain DNS server. Removing the directives stops every Kerberos-authenticated dynamic update. Windows machines stop registering their records, FreeIPA client enrollment that adds DNS entries fails, and a Samba AD domain controller on the BIND backend loses secure updates. Red Hat warns that this may disrupt automated Active Directory or IdM enrollment. If that server is the DNS for your Active Directory domain or a FreeIPA realm like the one in our Keycloak and FreeIPA integration, use the firewall control and keep GSS-TSIG on.
For servers that do not need Kerberos updates, back up the config, comment the directives out rather than deleting them, and confirm none are left. Commenting keeps the exact original lines on disk for the day you patch. This is the RHEL-family path, which we ran on the AlmaLinux 10 box while it was still on the vulnerable build. Red Hat’s instructions cover include files too, so if the recursive grep from the check section listed a file under /etc/named/, back it up and run the same sed against it as well.
sudo cp -a /etc/named.conf /etc/named.conf.pre-cve-2026-94300
sudo sed -i -E 's|^(\s*)(tkey-gssapi-(keytab\|credential)\s)|\1// \2|' /etc/named.conf
sudo named-checkconf && sudo systemctl restart named && systemctl is-active named
sudo named-checkconf -p | grep -cE 'tkey-gssapi-(keytab|credential)'The count dropped to 0 and named came back active, with the original line kept as a comment:
On Debian 12 and Ubuntu the directive normally sits in /etc/bind/named.conf.options. Find the file first, then run the same edit against it. This ran on the Debian 13 lab box, where it also brought the count to 0:
sudo grep -rlE 'tkey-gssapi-(keytab|credential)' /etc/bind/
sudo cp -a /etc/bind/named.conf.options /etc/bind/named.conf.options.pre-cve-2026-94300
sudo sed -i -E 's|^(\s*)(tkey-gssapi-(keytab\|credential)\s)|\1// \2|' /etc/bind/named.conf.options
sudo named-checkconf && sudo systemctl restart named && systemctl is-active namedThe firewall control limits port 53 to the networks that should talk to the server, which shrinks who can deliver a replayed message. With firewalld, replace the open dns service with a rich rule for your trusted subnet. Add a rule for every client and domain controller range before the reload, because any range you miss loses DNS the moment the rules apply. Check which zone holds the DNS interface first, since the commands below change the default zone:
sudo firewall-cmd --get-active-zonesOn the lab box eth0 sat in public, the default zone. If yours is in another zone, add --zone=<name> to each command that follows:
public (default)
interfaces: eth0Swap 10.0.1.0/24 for your own ranges, one rule per range. The rule is IPv4 only, so a server that also serves clients over IPv6 needs a matching family="ipv6" rule, or those clients lose DNS when the open service is removed:
sudo firewall-cmd --permanent --remove-service=dns
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="10.0.1.0/24" service name="dns" accept'
sudo firewall-cmd --reload
sudo firewall-cmd --list-all | grep -E 'services|rich|rule'dns is gone from the open services and the only DNS path left is the rich rule:
Prove the rule from a host outside the trusted range, because a firewall you have not tested is a guess. The Debian box sat on 192.168.1.0/24 and could no longer reach the AlmaLinux server’s resolver:
dig +time=2 +tries=1 @192.168.1.51 localhost Afirewalld rejected the query, so dig reported the host as unreachable instead of waiting for a timeout:
Debian and Ubuntu do not ship firewalld by default, so write the equivalent allow-list in whatever manages your nftables or ufw rules, then repeat the dig test from outside. Neither control replaces the package. A replay from inside the trusted subnet still works against a server with GSS-TSIG on, which is exactly the segment where domain members live.
If this CVE has you reconsidering BIND for authoritative zones that never needed Kerberos updates, PowerDNS with a database backend is the common alternative; our PowerDNS and PowerDNS Admin guide for Debian covers that setup end to end. For another backport-versus-version case worked through the same way, see the nginx CVE-2026-15176 check and patch.
Proof the DNS server is closed
A patch ticket closes when the server proves it, not when dnf or apt exits 0. Walk each BIND host through these checks, in order, and record the output with the change:
- The installed package matches the fixed build in the table above (
dpkg-query -W bind9orrpm -q bind bind9.18). - The package changelog names CVE-2026-94300, which settles any scanner dispute on 9.18 backports.
- The
namedstart time insystemctl statusis later than the package upgrade. named-checkconf -pshows GSS-TSIG directives only on servers that take Kerberos updates.- Port 53 answers only from the networks that should query the server, tested from a host outside them.
- Every host on a release with no fix carries at least one interim control, plus a ticket to undo it when the package lands.
- On a domain DNS server, one client re-registers its record after the change, which proves Kerberos updates still work.
Items 4 and 7 pull in different directions on a domain DNS server, and item 7 is the one people skip. On the AlmaLinux box, putting the backed-up named.conf back after the upgrade restored the keytab line, and named-checkconf accepted it on the patched build. Restoring was the right move there because the server needs secure updates. On a box that never needed them, leave the directive commented out for good: an unused GSS-TSIG listener is attack surface with no benefit.
