CVE-2026-35579

What it actually does

CoreDNS versions before 1.14.3 incorrectly treat TSIG-authenticated DNS messages as trusted when they arrive over gRPC, QUIC, DNS-over-HTTPS, or DNS-over-HTTP/3 transports. For gRPC and QUIC, CoreDNS checks only whether the supplied TSIG key name exists but does not validate the TSIG HMAC, allowing an attacker who knows or guesses a configured key name to bypass authentication. For DoH and DoH3, CoreDNS does not properly inspect or verify the TSIG record at all, so any request containing a TSIG record can be treated as authenticated even with an invalid key name and arbitrary MAC. This can expose TSIG-protected operations such as AXFR/IXFR zone transfers, dynamic DNS updates, and other plugin behavior that relies on TSIG status.

Why it matters to the business

Successful exploitation can let an unauthenticated remote attacker access or manipulate DNS functions that are intended to be restricted. The most serious outcomes include disclosure of full DNS zones, unauthorized DNS record changes, service redirection, disruption of name resolution, and exposure of internal hostnames or service topology. Because CoreDNS is widely used in cloud-native, Kubernetes, service discovery, and infrastructure environments, compromise of trusted DNS behavior can have broad operational impact even though this issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has a low EPSS score with no 30-day increase.

How an attack unfolds

An attacker identifies a CoreDNS deployment exposing gRPC, QUIC, DoH, or DoH3 DNS transports where sensitive actions are protected with TSIG. For DoH or DoH3, the attacker sends a DNS request containing any TSIG record, even one with an invalid key name and bogus MAC, because the affected code path treats the request as authenticated without verification. For gRPC or QUIC, the attacker sends a request using a TSIG key name that matches a configured key, but the MAC does not need to be valid because HMAC verification is not performed. Once the request is accepted as authenticated, the attacker can attempt TSIG-gated actions such as AXFR or IXFR zone transfers to obtain zone contents, or dynamic DNS UPDATE operations to add, modify, or delete records if those functions are enabled. The attacker may then use disclosed DNS data for reconnaissance or unauthorized DNS changes for traffic interception, service disruption, or persistence through malicious records.

How to fix it

Upgrade CoreDNS to version 1.14.3 or later, which fixes TSIG validation for the affected transports. If immediate upgrade is not possible, disable gRPC, QUIC, DoH, and DoH3 listeners wherever TSIG authentication is required. Restrict access to affected transport ports and DoH paths to trusted administrative networks or authenticated upstream gateways only. Review CoreDNS configuration for TSIG-protected AXFR, IXFR, dynamic DNS UPDATE, transfer, and plugin behavior, and avoid exposing those functions over affected transports until patched. Rotate TSIG keys if there is evidence or suspicion that zone transfers or updates were abused, especially where key names or DNS configuration details may have been disclosed.

How to confirm the fix worked

Confirm the running CoreDNS binary reports version 1.14.3 or later. Review deployment manifests, container images, package inventories, and service definitions to ensure no older CoreDNS instance remains active. Verify whether gRPC, QUIC, DoH, or DoH3 listeners are enabled and whether they are reachable from untrusted networks. Perform controlled negative testing by submitting a TSIG-signed AXFR, IXFR, or UPDATE request with an invalid MAC over each enabled affected transport; patched systems should reject the request rather than treating it as authenticated. For DoH and DoH3, test with an arbitrary or invalid TSIG key name and confirm it is rejected. Validate network controls by confirming only trusted sources can reach affected listener ports or DoH endpoints.

Typical attack path

1. Discover a CoreDNS service exposing gRPC, QUIC, DoH, or DoH3 DNS transport endpoints.
2. Determine whether TSIG-protected operations such as AXFR, IXFR, dynamic DNS UPDATE, or TSIG-gated plugins are reachable over those transports.
3. For DoH or DoH3, craft a DNS message containing a TSIG record with arbitrary key data and MAC value.
4. For gRPC or QUIC, craft a DNS message containing a TSIG key name that matches a configured key, without needing a valid HMAC.
5. Submit AXFR, IXFR, UPDATE, or other privileged DNS requests over the affected transport.
6. Use accepted responses to exfiltrate zone data, alter DNS records, or trigger other TSIG-protected behavior.
7. Leverage stolen DNS information or unauthorized record changes for follow-on reconnaissance, redirection, disruption, or impersonation.

How to detect it

Investigate CoreDNS query logs, plugin logs, HTTP access logs for DoH, reverse proxy logs, load balancer logs, QUIC/HTTP3 telemetry, gRPC access logs, firewall flow logs, and DNS audit records. Focus on TSIG-bearing requests over gRPC, QUIC, DoH, and DoH3 transports, especially requests for AXFR, IXFR, or DNS UPDATE from unexpected sources. For DoH and DoH3, look for POST requests to DNS query endpoints with DNS message payloads that include TSIG records, followed by successful responses to zone transfer or update operations. For gRPC and QUIC, look for TSIG key names used from unusual IP addresses, unusual geographies, or sources that normally do not administer DNS. Review zone serial changes, dynamic update journals, zone files, and DNS repository history for unauthorized modifications. Also look for reconnaissance patterns such as repeated AXFR/IXFR attempts across many zones, failed and successful transfer attempts close together, and traffic to DoH/DoH3 endpoints that is not consistent with normal resolver use. If suspicious activity is found, preserve CoreDNS logs, configuration files, zone files, update journals, container images, and network captures where available.

• AXFR
• IXFR
• UPDATE
• TSIG
• /dns-query
• application/dns-message
• application/dns-json
• h3
• HTTP/3
• DoH
• DoH3
• grpc
• quic
• zone transfer
• dynamic update
• transfer plugin
• tsig plugin

What your security team should do

• Prioritize upgrading all CoreDNS deployments using gRPC, QUIC, DoH, or DoH3 transports to version 1.14.3 or later.
• Immediately restrict external or untrusted access to CoreDNS gRPC, QUIC, DoH, and DoH3 listeners until patching is complete.
• Disable affected transports where TSIG is used to authorize zone transfers, dynamic DNS updates, or other privileged DNS behavior and those transports are not strictly required.
• Audit CoreDNS configurations for AXFR, IXFR, dynamic DNS UPDATE, transfer, tsig, grpc, quic, DoH, and DoH3 usage.
• Search historical DNS, HTTP, QUIC, proxy, and CoreDNS logs for unusual AXFR, IXFR, UPDATE, or TSIG-bearing requests over DoH, DoH3, gRPC, or QUIC paths.
• Review DNS zones for unauthorized additions, deletions, or changes, especially records that redirect traffic, create new delegation paths, or introduce unexpected external targets.
• Rotate TSIG keys if logs show suspicious TSIG-authenticated operations, unexplained zone transfers, or unauthorized DNS updates.
• Add monitoring for TSIG-authenticated privileged DNS operations over non-traditional DNS transports and alert on requests from unexpected source networks.