CVE-2026-35579: Critical TSIG Bypass in CoreDNS

CVE-2026-35579 is a critical authentication bypass in CoreDNS, scored 9.8 in the CVE record. The gRPC, QUIC, DoH and DoH3 transports do not properly verify TSIG signatures. Versions before 1.14.3 are affected, and 1.14.3 is the fixed release, so upgrade to it or a vendor build that carries the fix.

What's affected

• Product: CoreDNS (Go module github.com/coredns/coredns)
• Affected versions: before 1.14.3
• Fixed version: 1.14.3
• Affected transports: gRPC, QUIC, DoH and DoH3. Plain DNS over TCP and UDP verify TSIG correctly, according to the advisory

The advisory says that for gRPC and QUIC the server checks whether the TSIG key name exists in the configuration but never verifies the signature. For DoH and DoH3 the check is weaker still, and a request carrying any TSIG record is treated as authenticated. The record does not say this is exploited in the wild, and the CVE is not in the CISA Known Exploited Vulnerabilities catalog.

Red Hat lists the CVE and an erratum, RHSA-2026:25127, which suggests some distributions ship backported fixes. If your CoreDNS comes from a vendor build, read the vendor advisory for the fixed package version.

How to check if you're exposed

Start with the version.

coredns -version

In Kubernetes, CoreDNS usually runs as a deployment in the kube-system namespace. Read the image tag:

kubectl -n kube-system get deployment coredns \
  -o jsonpath='{.spec.template.spec.containers[0].image}'

Then check whether you are using the transports and the plugin involved. Look in your Corefile for server blocks that start with grpc://, quic://, https:// or h3:// and for the tsig plugin.

kubectl -n kube-system get configmap coredns -o yaml | grep -E "grpc://|quic://|https://|h3://|tsig"

If there is no tsig plugin in use, the flaw has nothing to bypass. A stock Kubernetes cluster DNS setup commonly has neither, so the exposure is mostly for people who run CoreDNS as an authoritative or secured DNS server.

What to do now

1. Upgrade CoreDNS to 1.14.3 or later, or to the fixed package from your vendor.
2. If you cannot upgrade yet, disable the gRPC, QUIC, DoH and DoH3 listeners where TSIG authentication is required. That is an advisory workaround.
3. Restrict network access to those transport ports to trusted sources.
4. Do not expose TSIG protected functions such as zone transfers or dynamic updates over the affected transports until you are patched.
5. Review logs for zone transfer and update requests from addresses you do not recognise.
6. Consider rotating TSIG secrets if you have reason to believe someone reached these listeners.

Why it matters

TSIG signs DNS messages with a shared secret so a server can tell who is asking. The point is to protect actions such as zone transfers and dynamic updates. The record files this under CWE-287, improper authentication, and CWE-303, incorrect implementation of an authentication algorithm.

The advisory explains the code path. When a request with a TSIG record arrived over these transports, the code either checked only the key name or did not check at all, and the plugin treated the empty status as a successful check. An empty error was read as success. That is a classic pattern, and it is the reason secure code returns an explicit result for verified, not a missing error.

The advisory also notes that two earlier changes had partly addressed this area but never added verification of the signature itself. Fixes that touch only the visible symptom can leave the cause in place.

Try it yourself

Click through it at your own pace, or open it full screen.

Quick check

Sources

• CVE record for CVE-2026-35579 on Gold
• GitHub advisory GHSA-vp29-5652-4fw9
• Red Hat page for CVE-2026-35579 (listed in the record)

Last reviewed: 19 October 2026.