CVE-2026-94300: BIND GSS-TSIG Race, Exposure and Fixes

CVE-2026-94300 is a BIND 9 memory-corruption vulnerability involving concurrent use of a GSS-TSIG session. It can terminate the DNS server and may permit remote code execution under specific conditions. The important qualification is the signed traffic: this is not evidence that an ordinary unsigned DNS query can compromise every BIND installation. Operators need to establish the deployed build, the relevant authentication path and whether the running service has received the fix.

ISC’s October 21 advisory, reviewed October 23, rates the issue High, CVSS 3.1 8.1. The described attack requires a previously captured GSS-TSIG-signed UDP message, replayed while its negotiated key remains valid. ISC describes potential RCE with additional crafted queries involving an attacker-controlled zone. It reports no known active exploits and no known workaround. These are the vendor’s published findings, not an independently reproduced exploit.

The bug is shared session state, not simply an invalid signature

Les BIND 9.20.30 release notes explain the implementation boundary: a GSS-TSIG session negotiated through TKEY is shared by messages signed or verified with that key. Earlier code did not serialize access to that session. Concurrent messages could corrupt Kerberos-owned state; the fix serializes access.

This explains why “the message is authenticated” is an incomplete security argument. Authentication decides whether a message carries acceptable credentials. It does not, by itself, make concurrent access to the credential context safe. In this case, the lifecycle of the shared session matters alongside the validity of an individual message.

Consider the distinction conceptually. Two operations can both refer to a legitimate session while still accessing its mutable state at overlapping times. Rejecting unrelated unauthenticated requests would not necessarily prevent that overlap. This is an explanation of the concurrency boundary, not a reconstruction of the exact interleaving or a claim about an undisclosed allocator technique.

The release notes establish the synchronization change, while the advisory describes a broader potential impact. Neither source reviewed here provides enough evidence to publish a reliable code-execution payload, claim a particular instruction-pointer primitive or identify an exploit signature. A precise analysis should stop at that boundary rather than filling it with a plausible-looking attack chain.

Which upstream versions are affected?

The following ranges and fixed releases come from the ISC advisory. They describe upstream BIND releases; package maintainers may identify their own remediation builds separately. The absence of a fixed 9.18 release in this table should prompt a supported upgrade-path review, not invention of a patch version.

Do not treat all five rows as interchangeable deployment choices. Preserve the existing branch, packaging source and support relationship in the decision record. For a distribution package, obtain the vendor’s advisory or changelog that explicitly maps its package build to this CVE. A short upstream version string alone may not express a distributor’s patch state.

Conversely, a package-manager result showing that “no updates are available” is not enough to close exposure. It may reflect the configured repositories, a held package or a release branch that no longer receives the desired update. Establish what remediation the responsible supplier actually provides for that installation.

Separate vulnerable code from the described attack prerequisites

A useful exposure assessment answers two questions independently: does this build contain the vulnerable implementation, and can the deployment encounter the GSS-TSIG conditions described by ISC? The first determines remediation status. The second informs urgency and the plausibility of a particular attack route. A missing answer to the second must not be turned into a claim that the first is false.

Inspect the effective deployment rather than a convenient copy of a configuration file. Includes, generated configuration, service arguments, chroot paths and container mounts can change which settings the daemon actually reads. The evidence record should identify the configuration source and runtime context so another administrator can repeat the assessment.

Where GSS-TSIG does not appear to be used, record how that conclusion was reached and which instance it covers. That can narrow the described exposure path. It does not justify a universal “unaffected” label for an unpatched fleet, especially when configuration ownership is fragmented or the service may be repurposed later.

Two administrative checks, and what they actually prove

Les BIND manual documents named -V as reporting version and build information and rndc status as requesting server status. These commands support inventory; they are not vulnerability probes. The example below has not been independently executed against a BIND deployment for this article.

# Run only in the environment of the BIND service you administer.
# Reports the named executable resolved by this shell:
named -V

# Uses the configured RNDC endpoint and credentials:
rndc status

The first command describes an executable on disk. If the shell resolves a different installation from the one used by the service manager, its output may be irrelevant to the running server. Run the inventory check in the correct host, container or chroot context and compare the resolved executable with the service definition.

The second command depends on an already configured and authorized RNDC connection. Its result applies to the endpoint selected by that configuration, which may differ from the intended instance. If it fails, investigate the administrative connection; do not label the failure “not vulnerable,” and do not expose the control channel or weaken authentication simply to make the command work.

Retain the collection time, instance identifier, executable or image identity, package build and selected control endpoint. Redact sensitive deployment details before sharing the record. This gives the output evidentiary context without pretending that either command reproduces the race.

Patch the running service, then validate the DNS work it must perform

Choose the supported remediation for the actual packaging source. Before maintenance, identify redundant service instances and the DNS workflows that depend on them. An update that fixes the software but interrupts an essential authenticated update path is not a complete operational outcome.

In staging, use a disposable zone and a designated authorized client to exercise the normal GSS-TSIG workflow your organization relies on. Verify that the intended update succeeds and that unauthorized access remains denied under the existing policy. These are suggested functional acceptance checks, not an exploit test. Do not replay captured production messages or create attack traffic to make the evidence look more convincing.

After deployment, verify the effective running state for every serving instance. Package replacement may leave an older process running until the appropriate restart procedure is completed. A configuration reload should not be assumed to replace the executing program. Follow the supplier’s deployment procedure, then collect fresh runtime evidence.

Test ordinary DNS resolution from the clients and network locations that matter to the service. Include the authenticated workflow separately: a successful ordinary lookup says little about whether GSS-TSIG negotiation and updates still operate. Keep availability checks and security-remediation checks as distinct results in the change record.

If a distribution build retains an older upstream version string, keep the distributor’s fixed-package mapping beside the runtime record. If the upstream release has been installed directly, keep the release identity and deployment evidence. Both paths require a defensible connection between the patched artifact and the process that is actually serving requests.

Investigate crashes without inventing an intrusion signature

Unexpected daemon termination during relevant authenticated traffic deserves investigation, but the reviewed sources do not supply a unique log string that proves CVE-2026-94300 exploitation. A crash can have other causes. Its absence is also weak evidence where monitoring, retention or crash collection is incomplete.

Preserve the affected instance’s version, start and termination times, service logs and any existing crash artifacts under the organization’s incident-handling policy. Correlate them with configuration changes, maintenance and the relevant client workflow. Crash dumps can contain sensitive process memory, so restrict access and do not upload them to a public analysis service by default.

An observed crash does not demonstrate successful RCE. Establishing code execution or compromise requires additional evidence about unauthorized behavior. Keep that investigation separate from the patch decision: remediation can proceed while responders assess impact, and a patched build cannot retrospectively prove that no compromise occurred.

Questions that change the deployment decision

Does DNSSEC signing establish exposure? No. The disclosed mechanism concerns GSS-TSIG session handling. DNSSEC terminology alone is not evidence that the relevant workflow is present.

Can an IP allowlist be called a workaround? Network restrictions may reduce reachable paths in a particular architecture, but ISC lists no known workaround. Do not relabel a compensating control as a vendor-confirmed fix.

Is a negative remote scan enough? No. Without a validated test and documented coverage, a negative result cannot establish whether the shared session code has been corrected. Prefer package provenance and running-service verification.

The useful completion criterion is specific: every relevant instance runs a build whose remediation is documented, the required DNS workflows still function, and any suspicious historical activity has its own investigation outcome. That is stronger evidence than either an alarmist RCE headline or an unsupported declaration that unused-looking functionality makes the issue irrelevant.

Watch the Penligent product walkthrough

This product walkthrough introduces Penligent. It is separate from the BIND vulnerability analysis above and does not demonstrate exploitation or detection of CVE-2026-94300.