Authentication Bypass in github.com/coredns/coredns (CVE-2026-35579, CVSS 9.8)

Summary

authentication bypass in github.com/coredns/coredns (CVE-2026-35579). Successful exploitation can lead to full system takeover. Exploitable via tsigStatus. Mitigation: upgrade to 1.14.3 or later.

Original description

The description as published by the source.

Summary

The gRPC, QUIC, DoH, and DoH3 transports in CoreDNS incorrectly handle TSIG authentication.

For gRPC and QUIC, CoreDNS checks whether the TSIG key name exists in the config, but does not actually verify the TSIG HMAC. If the key name matches, tsigStatus remains nil and the tsig plugin treats the request as "verified".

For DoH and DoH3, the issue is worse: TSIG is not verified at all. The DoH response writer has TsigStatus() hardcoded to return nil, so any request containing a TSIG record is treated as authenticated, even if the key name is invalid and the MAC is garbage.

As a result, attackers may bypass TSIG authentication on affected transports and access TSIG-protected functionality such as AXFR/IXFR zone transfers, dynamic updates, or other TSIG-gated plugin behavior.

Details

In server_grpc.go and server_quic.go, the TSIG handling checks whether the TSIG key name exists, but does not call dns.TsigVerify().

Relevant code before fix:

if tsig := msg.IsTsig(); tsig != nil {
    if s.tsigSecret == nil {
        w.tsigStatus = dns.ErrSecret
    } else if _, ok := s.tsigSecret[tsig.Hdr.Name]; !ok {
        w.tsigStatus = dns.ErrSecret
    }
    // key found -> nothing happens -> tsigStatus stays nil -> "verified"
}

This means that for gRPC and QUIC, a request with a known TSIG key name but an invalid MAC is accepted as authenticated.

PRs #7943 and #7947 partially addressed this area by adding key name checks for gRPC and QUIC, but di…

Source: NIST National Vulnerability Database NVD GitHub Advisory

AI summary

Written by an external AI model and may contain mistakes. Check the original description and references below before acting on it.

CoreDNS has a critical vulnerability allowing malicious attackers to bypass TSIG authentication. Exploitation could lead to unauthorized manipulation of domain information or unapproved data updates. This issue can be resolved by updating the system to version 1.14.3. In the past, similar authentication issues have led to significant data breaches. Prompt action is recommended.

Attackers can exploit CoreDNS's gRPC and QUIC transports by checking only for the presence of a TSIG key name without verifying the HMAC, thus bypassing authentication. Additionally, DoH and DoH3 transports do not perform any TSIG verification, accepting any TSIG record as authenticated. The affected versions are 1.14.2 and below, with the issue fixed in version 1.14.3. Detecting attacks involves monitoring for unusual request patterns in gRPC or QUIC and logging anomalous access activities.

❓ What is the problem

CoreDNS has a TSIG authentication bypass vulnerability in gRPC, QUIC, DoH, and DoH3 transports.

📍 Affected scope

gRPC and QUIC do not verify TSIG HMAC; DoH and DoH3 do not verify TSIG at all.

🔥 Severity

Critical severity (CVSS v3: 9.8), remote attack possible, no authentication required.

🔧 How to fix

Update to CoreDNS version 1.14.3 which introduces full TSIG verification.

🛡️ Workaround

No specific workaround identified; immediate update recommended.

🔍 Detection

Monitor for unusual request patterns and anomalous access on gRPC and QUIC services.

Related past incidents Similar incidents extracted from past CVEs

CVE-2020-1350

A Windows DNS Server Remote Code Execution Vulnerability related to improper handling of DNS responses.

CVE-2019-19781

Citrix ADC and Gateway TSIG authentication bypass, allowing for possible remote code execution.

CVE-2017-17485

A vulnerability in Infoblox NIOS that allowed TSIG Key Misvalidation.

If this happens at your company Expected impact per business scenario

📌 In an enterprise environment with large scale DNS management.

Attackers may exploit the vulnerability to perform unauthorized zone transfers, leading to potential exposure of proprietary information.

📌 In a cloud service provider offering DNS services.

Clients may lose trust in the service due to potential unauthorized DNS modifications affecting service reliability.

📌 For organizations hosting their own DNS infrastructure using CoreDNS.

Critical domain settings might be tampered with, resulting in service disruption or data leaks.

Recommended action

Immediately update CoreDNS to version 1.14.3 to mitigate the vulnerability.

Response actions

Concrete steps and command examples for SOC/SRE teams to execute in order

1
Identify exposure identify
```
grep -r 'github.com/coredns/coredns' . | grep -v node_modules
```
リポジトリと本番環境の依存ファイル (package-lock.json / requirements.txt / go.sum / Gemfile.lock 等) で github.com/coredns/coredns を grep し、稼働しているサービス・バージョンを把握する。
2
Match against affected range verify
```
Confirm if version satisfies `< 1.14.3`
```
Step 1 で見つかったバージョンが影響範囲 < 1.14.3 に該当するか照合。本番で稼働中ならインシデント扱い。
5
Apply temporary workaround mitigate
```
- Disable gRPC, QUIC, DoH, and DoH3 listeners where TSIG authentication is required.
```
パッチが適用されるまでの応急処置として、- Disable gRPC, QUIC, DoH, and DoH3 listeners where TSIG authentication is required. を実施。回避策の副作用 (機能低下) を確認した上で。
6
Apply patch patch
```
Upgrade github.com/coredns/coredns to 1.14.3
```
ステージング環境で 1.14.3 に上げて回帰テスト → 本番反映。回帰テストはアプリの主要ハッピーパスと、Step 3 で見つけた異常検知の続報チェックを含めること。
7
Post-deployment verification verify
```
Confirm patched version is live in production
```
パッチ適用後、ステージングで PoC または同等の悪用パターンを再現して脆弱性が閉じたことを確認。本番では Step 3 と同じログクエリでアラート再発が無いか継続監視。

Affected packages

go github.com/coredns/coredns

[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"1.14.3"}]}]

Authentication Bypass in github.com/coredns/coredns (CVE-2026-35579)

Summary

Original description

Summary

Details

AI summary

Related past incidents Similar incidents extracted from past CVEs

If this happens at your company Expected impact per business scenario

Response actions

Affected packages

References