CVE-2026-35579: CoreDNS TSIG authentication bypass on gRPC, QUIC, DoH, and DoH3 transports
CoreDNS is a DNS server written in Go. In versions prior to 1.14.3, the gRPC, QUIC, DoH, and DoH3 transport implementations incorrectly handle TSIG authentication. For gRPC and QUIC, the server checks whether the TSIG key name exists in the configuration but never calls dns.TsigVerify() to validate the HMAC. If the key name matches a configured key, the tsigStatus field remains nil and the tsig plugin treats the request as successfully authenticated regardless of the MAC value. For DoH and DoH3, the issue is more severe: the DoHWriter.TsigStatus() method unconditionally returns nil, and the server never inspects the TSIG record at all. Any request containing a TSIG record is treated as authenticated over DoH and DoH3, even if the key name is invalid and the MAC is arbitrary.
An unauthenticated network attacker can exploit this to bypass TSIG-protected functionality such as AXFR/IXFR zone transfers, dynamic DNS updates, or other TSIG-gated plugin behavior. The DoH and DoH3 variants have a lower exploitation bar because the attacker does not need to know a valid TSIG key name.
This issue has been fixed in version 1.14.3. As a workaround, disable gRPC, QUIC, DoH, and DoH3 listeners where TSIG authentication is required, or restrict network-level access to affected transport ports to trusted sources only.
Security readout for executives and security teams
Plain-English summary
CoreDNS before 1.14.3 can wrongly accept forged TSIG-authenticated DNS requests over gRPC, QUIC, DoH, and DoH3. If those transports protect zone transfers, dynamic updates, or plugin behavior, an outside attacker may bypass intended DNS access controls.
Executive priority
Treat as high priority for DNS services using modern CoreDNS transports with TSIG controls. The business risk is unauthorized access to DNS operations or zone data, not general remote code execution based on the provided sources.
Technical view
The affected transports mishandle TSIG validation. gRPC and QUIC check only that a configured key name exists, without verifying the HMAC. DoH and DoH3 report TSIG success without inspecting the TSIG record, making arbitrary TSIG-bearing requests appear authenticated.
Likely exposure
Exposure is likely limited to CoreDNS deployments before 1.14.3 that enable gRPC, QUIC, DoH, or DoH3 listeners and rely on TSIG for sensitive functions such as AXFR, IXFR, dynamic DNS updates, or TSIG-gated plugins.
Exploitation context
The source bundle describes unauthenticated network exploitation. DoH and DoH3 require less prior knowledge because a valid TSIG key name is not needed. KEV is false, and the provided sources do not state active exploitation.
Researcher notes
The strongest technical distinction is transport-specific: gRPC and QUIC validate key-name presence but not MAC integrity, while DoH and DoH3 accept TSIG status without record inspection. Analysis is limited to the provided bundle.
Mitigation direction
Upgrade CoreDNS to version 1.14.3 or later.
Disable gRPC, QUIC, DoH, and DoH3 where TSIG authentication is required.
Restrict affected transport ports to trusted sources only.
Review Red Hat guidance where CoreDNS is supplied through Red Hat products.
Validation and detection
Inventory CoreDNS versions and flag anything before 1.14.3.
Review CoreDNS configuration for gRPC, QUIC, DoH, or DoH3 listeners.
Identify TSIG-protected AXFR, IXFR, dynamic update, or plugin paths.
Confirm exposed transport ports are limited to trusted networks.
Check vendor advisories for product-specific package status.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · medium confidence lookup
CWE-287: Credential and account abuse lookup
Authentication and credential weaknesses can make valid-account abuse and credential telemetry useful review starting points. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
The CVE wording references authentication or credential exposure, so valid-account and credential-access review may help. This is a Glexia inferred lookup path, not an official MITRE, ATT&CK, or CVE Program mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-287 · source CWE mapping
Improper Authentication
Improper Authentication represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.
Incorrect Implementation of Authentication Algorithm
Incorrect Implementation of Authentication Algorithm represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.