CVE-2026-35579: CoreDNS TSIG Authentication Bypass Flaw

CVE-2026-35579 Overview

CVE-2026-35579 is an authentication bypass vulnerability [CWE-287] in CoreDNS, a DNS server written in Go. Versions prior to 1.14.3 incorrectly handle Transaction Signature (TSIG) authentication across the gRPC, QUIC, DNS-over-HTTPS (DoH), and DNS-over-HTTP/3 (DoH3) transport implementations. The gRPC and QUIC code paths verify that a TSIG key name exists but never call dns.TsigVerify() to validate the HMAC. The DoH and DoH3 paths are worse: DoHWriter.TsigStatus() unconditionally returns nil, so any request containing a TSIG record is accepted as authenticated.

Critical Impact
Unauthenticated network attackers can bypass TSIG-protected operations such as AXFR/IXFR zone transfers and dynamic DNS updates. Over DoH and DoH3, attackers do not need to know a valid TSIG key name.

Affected Products

CoreDNS versions prior to 1.14.3
Deployments exposing gRPC or QUIC DNS transports with TSIG authentication
Deployments exposing DoH or DoH3 DNS transports with TSIG authentication

Discovery Timeline

2026-05-05 - CVE CVE-2026-35579 published to NVD
2026-05-07 - Last updated in NVD database

Technical Details for CVE-2026-35579

Vulnerability Analysis

The vulnerability stems from incomplete TSIG validation in non-traditional DNS transports. TSIG (RFC 8945) is a shared-secret HMAC mechanism that authenticates DNS messages and gates sensitive operations like zone transfers and dynamic updates. CoreDNS relies on the tsig plugin to validate inbound requests, which inspects the TsigStatus() value returned by each transport's response writer.

For gRPC and QUIC transports, the server checks whether the supplied TSIG key name appears in its configuration but never invokes dns.TsigVerify() to validate the HMAC. When the key name matches, the tsigStatus field remains nil, which the plugin interprets as a successful authentication regardless of the MAC contents. An attacker who knows or guesses a configured key name can issue forged signed requests.

For DoH and DoH3, validation is absent entirely. DoHWriter.TsigStatus() always returns nil, and the server never inspects the TSIG record in the request. Any request carrying a TSIG record, with arbitrary key name and arbitrary MAC, is treated as authenticated. This eliminates the need to enumerate valid key names.

Root Cause

The transport implementations decouple TSIG verification from the request lifecycle. The gRPC and QUIC handlers only confirm key-name membership without computing or comparing the HMAC. The DoH and DoH3 writer implementations stub out TSIG status reporting, returning nil unconditionally and leaving the TSIG record uninspected. The tsig plugin then trusts the writer's status as a verification result.

Attack Vector

An unauthenticated network attacker sends a DNS request containing a TSIG record over an exposed gRPC, QUIC, DoH, or DoH3 listener. The request can invoke any TSIG-gated functionality, including AXFR/IXFR zone transfers exposing full zone contents, dynamic DNS updates that modify records, and other plugin behavior protected by TSIG. Over DoH and DoH3, the attacker does not need any prior knowledge of configured TSIG keys.

No verified exploit code is publicly indexed at this time. Refer to the CoreDNS GitHub Security Advisory for technical details.

Detection Methods for CVE-2026-35579

Indicators of Compromise

Unexpected AXFR or IXFR responses originating from CoreDNS instances exposing gRPC, QUIC, DoH, or DoH3 listeners.
Dynamic DNS update transactions arriving over DoH or DoH3 endpoints from untrusted source addresses.
TSIG-signed requests over DoH/DoH3 referencing key names that are not provisioned in the CoreDNS configuration.

Detection Strategies

Inspect CoreDNS query logs for zone transfer requests over non-traditional transports such as gRPC port 443, QUIC, or HTTPS endpoints terminating DoH/DoH3.
Compare TSIG key names observed in inbound requests against the keys defined under the tsig plugin in your Corefile.
Alert on dynamic update operations (DNS opcode UPDATE) processed by CoreDNS where the source is outside management networks.

Monitoring Recommendations

Capture and review network telemetry for the configured gRPC, QUIC, DoH, and DoH3 listener ports.
Forward CoreDNS logs to a centralized analytics platform and build content for DNS opcode anomalies and zone-transfer volume spikes.
Track CoreDNS version inventory across the environment and flag instances running versions earlier than 1.14.3.

How to Mitigate CVE-2026-35579

Immediate Actions Required

Upgrade CoreDNS to version 1.14.3 or later on all instances that expose gRPC, QUIC, DoH, or DoH3 listeners.
Audit Corefile configurations to identify which transports and TSIG-protected plugins are in use.
Rotate TSIG keys after upgrading if there is any indication that requests were processed by vulnerable instances.

Patch Information

The CoreDNS maintainers fixed this issue in version 1.14.3. The patch ensures that gRPC and QUIC transports invoke dns.TsigVerify() to validate the HMAC and that DoH and DoH3 writers report accurate TSIG verification status. Details are available in the CoreDNS GitHub Security Advisory GHSA-vp29-5652-4fw9.

Workarounds

Disable the gRPC, QUIC, DoH, and DoH3 listeners in environments where TSIG authentication is required and upgrading is not yet possible.
Restrict network-level access to gRPC, QUIC, DoH, and DoH3 transport ports to trusted source addresses using firewall rules or service mesh policies.
Place CoreDNS behind an authenticating reverse proxy that enforces mutual TLS for DoH and DoH3 endpoints until patches are deployed.

bash

# Example: restrict CoreDNS DoH listener to trusted management subnet
iptables -A INPUT -p tcp --dport 443 -s 10.0.10.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j DROP

# Example: disable DoH/DoH3 in Corefile while patching is scheduled
# Remove or comment the following blocks:
# tls://.:853 { ... }
# https://.:443 { ... }
# quic://.:853 { ... }
# grpc://.:443 { ... }