Every CVE Search/ Get API key

CVE-2026-35579

CoreDNS TSIG authentication bypass on gRPC, QUIC, DoH, and DoH3 transports

8.2 HighFix available

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.

Attack profile

How easy it is to exploit

Attack vector
Network
Complexity
Low
Privileges needed
None
User interaction
None

What an attacker can affect

Confidentiality
High
Integrity
None
Availability
None

Exploit likelihood

0.61%Up 0.6 points since May 6, 2026
90%50%10%1%

What each source reports

CVE List Score used 8.2

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.

Record
CVE-2026-35579
CVSS 4.0
8.2 HighCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
CVSS 3.1
7.5 HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Weakness
CWE-287, CWE-303
Updated
2026-11-02
EUVDEUVD-2026-27493 8.2

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.

Record
EUVD-2026-27493
CVSS 4.0
8.2 HighCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Updated
2026-11-02
GitHub AdvisoriesGHSA-vp29-5652-4fw9 8.2

CoreDNS has TSIG authentication bypass on gRPC and QUIC transports

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 did not add HMAC verification.

The DoH and DoH3 paths have an even weaker failure mode. In https.go, DoHWriter.TsigStatus() returned nil unconditionally:

func (d *DoHWriter) TsigStatus() error {
    return nil
}

In server_https.go, the incoming DNS message is unpacked from the HTTP request and passed directly into ServeDNS() without checking msg.IsTsig(), without looking up the TSIG key name, and without calling dns.TsigVerify().

The same pattern exists in the DoH3 path in server_https3.go.

The effective DoH/DoH3 flow before the fix was:

  1. HTTP or HTTP/3 request arrives.
  2. DNS message is unpacked from the request.
  3. A DoHWriter is created.
  4. The message is passed to ServeDNS().
  5. The tsig plugin checks w.TsigStatus().
  6. TsigStatus() returns nil.
  7. nil is interpreted as successful TSIG verification.

This means that for DoH and DoH3, CoreDNS did not even require a valid TSIG key name. Any TSIG record was enough to satisfy the tsig plugin, regardless of key name or MAC contents.

PoC

Setup: built CoreDNS from master at commit 12d9457 and also verified against the v1.14.2 release binary. Configured a single test zone with 9 records and tsig { require all }.

Listeners used the same TSIG configuration and key:

  • TCP on port 1053, using the normal dns.Server path where TSIG HMAC verification works correctly
  • gRPC on port 1443, using manual TSIG handling
  • DoH on port 8443
  • DoH3 with the same TSIG configuration

gRPC / QUIC behavior

A test client sent AXFR requests over gRPC with a valid TSIG key name but forged MAC values. The same requests were sent over TCP for comparison.

| MAC used | gRPC | TCP | |----------|------|-----| | 32 zero bytes | BYPASS, 9 records returned | BADSIG | | 32 random bytes | BYPASS, 9 records returned | BADSIG | | HMAC computed with wrong secret | BYPASS, 9 records returned | BADSIG | | truncated to 16 bytes | BYPASS, 9 records returned | BADSIG | | single byte 0x41 | BYPASS, 9 records returned | BADSIG | | empty MAC | BYPASS, 9 records returned | BADSIG | | wrong key name + zero MAC | REJECTED, NOTAUTH/BADKEY | REJECTED, NOTAUTH/BADKEY |

6 out of 7 forged TSIG requests bypassed authentication over gRPC and returned a full zone transfer. The only rejected case was the wrong key name, because the gRPC path checked whether the key name existed.

The same class applied to QUIC.

DoH / DoH3 behavior

For DoH, a test client sent DNS queries over HTTPS POST to…

Record
GHSA-vp29-5652-4fw9
CVSS 4.0
8.2 HighCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
CVSS 3.1
7.5 HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Weakness
CWE-287
Updated
2026-11-02
NVD 8.2

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.

Record
CVE-2026-35579
CVSS 4.0
8.2 HighCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
CVSS 3.1
9.8 CriticalCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS 3.1
7.5 HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Weakness
CWE-287, CWE-303
Updated
2026-11-02
OSV 8.2

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.

Record
CVE-2026-35579
CVSS 4.0
8.2 HighCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Weakness
CWE-287
Updated
2026-11-02
OSVGHSA-vp29-5652-4fw9 8.2

CoreDNS has TSIG authentication bypass on gRPC and QUIC transports

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 did not add HMAC verification.

The DoH and DoH3 paths have an even weaker failure mode. In https.go, DoHWriter.TsigStatus() returned nil unconditionally:

func (d *DoHWriter) TsigStatus() error {
    return nil
}

In server_https.go, the incoming DNS message is unpacked from the HTTP request and passed directly into ServeDNS() without checking msg.IsTsig(), without looking up the TSIG key name, and without calling dns.TsigVerify().

The same pattern exists in the DoH3 path in server_https3.go.

The effective DoH/DoH3 flow before the fix was:

  1. HTTP or HTTP/3 request arrives.
  2. DNS message is unpacked from the request.
  3. A DoHWriter is created.
  4. The message is passed to ServeDNS().
  5. The tsig plugin checks w.TsigStatus().
  6. TsigStatus() returns nil.
  7. nil is interpreted as successful TSIG verification.

This means that for DoH and DoH3, CoreDNS did not even require a valid TSIG key name. Any TSIG record was enough to satisfy the tsig plugin, regardless of key name or MAC contents.

PoC

Setup: built CoreDNS from master at commit 12d9457 and also verified against the v1.14.2 release binary. Configured a single test zone with 9 records and tsig { require all }.

Listeners used the same TSIG configuration and key:

  • TCP on port 1053, using the normal dns.Server path where TSIG HMAC verification works correctly
  • gRPC on port 1443, using manual TSIG handling
  • DoH on port 8443
  • DoH3 with the same TSIG configuration

gRPC / QUIC behavior

A test client sent AXFR requests over gRPC with a valid TSIG key name but forged MAC values. The same requests were sent over TCP for comparison.

| MAC used | gRPC | TCP | |----------|------|-----| | 32 zero bytes | BYPASS, 9 records returned | BADSIG | | 32 random bytes | BYPASS, 9 records returned | BADSIG | | HMAC computed with wrong secret | BYPASS, 9 records returned | BADSIG | | truncated to 16 bytes | BYPASS, 9 records returned | BADSIG | | single byte 0x41 | BYPASS, 9 records returned | BADSIG | | empty MAC | BYPASS, 9 records returned | BADSIG | | wrong key name + zero MAC | REJECTED, NOTAUTH/BADKEY | REJECTED, NOTAUTH/BADKEY |

6 out of 7 forged TSIG requests bypassed authentication over gRPC and returned a full zone transfer. The only rejected case was the wrong key name, because the gRPC path checked whether the key name existed.

The same class applied to QUIC.

DoH / DoH3 behavior

For DoH, a test client sent DNS queries over HTTPS POST to…

Record
GHSA-vp29-5652-4fw9
CVSS 4.0
8.2 HighCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
CVSS 3.1
7.5 HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Weakness
CWE-287
Updated
2026-11-02
Show 9 moreShow less
OSVOESA-2026-3368 9.8

coredns security update

CoreDNS is a fast and flexible DNS server. The key word here is flexible: with CoreDNS you are able to do what you want with your DNS data by utilizing plugins.

Security Fix(es):

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.(CVE-2026-35579)

Record
OESA-2026-3368
CVSS 3.1
9.8 CriticalCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Updated
2026-11-02
OSVOESA-2026-3369 9.8

coredns security update

CoreDNS is a fast and flexible DNS server. The key word here is flexible: with CoreDNS you are able to do what you want with your DNS data by utilizing plugins.

Security Fix(es):

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.(CVE-2026-35579)

Record
OESA-2026-3369
CVSS 3.1
9.8 CriticalCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Updated
2026-11-02
OSVOESA-2026-3370 9.8

coredns security update

CoreDNS is a fast and flexible DNS server. The key word here is flexible: with CoreDNS you are able to do what you want with your DNS data by utilizing plugins.

Security Fix(es):

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.(CVE-2026-35579)

Record
OESA-2026-3370
CVSS 3.1
9.8 CriticalCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Updated
2026-11-02
OSVOESA-2026-3371 9.8

coredns security update

CoreDNS is a fast and flexible DNS server. The key word here is flexible: with CoreDNS you are able to do what you want with your DNS data by utilizing plugins.

Security Fix(es):

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.(CVE-2026-35579)

Record
OESA-2026-3371
CVSS 3.1
9.8 CriticalCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Updated
2026-11-02
OSVOESA-2026-3442 9.8

coredns security update

CoreDNS is a fast and flexible DNS server. The key word here is flexible: with CoreDNS you are able to do what you want with your DNS data by utilizing plugins.

Security Fix(es):

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.(CVE-2026-35579)

Record
OESA-2026-3442
CVSS 3.1
9.8 CriticalCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Updated
2026-11-02
OSVAZL-85730 No score

CVE-2026-35579 affecting package coredns for versions less than 1.11.4-16

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.

Record
AZL-85730
Updated
2026-11-05
OSVGO-2026-5667 No score

CoreDNS has TSIG authentication bypass on gRPC and QUIC transports in github.com/coredns/coredns

CoreDNS has TSIG authentication bypass on gRPC and QUIC transports in github.com/coredns/coredns

Record
GO-2026-5667
Updated
2026-11-02
OSVopenSUSE-SU-2026:20703-1 No score

Security update for coredns

This update for coredns fixes the following issues:

Changes in coredns:

  • Update to version 1.14.3:
    • This release introduces Windows service support, along with full TSIG verification across DoH, DoH3, QUIC, and gRPC transports, and improved TSIG propagation and DoH request validation.
    • It also adds optional TLS for the metrics endpoint.
    • Performance and stability are improved through cache prefetching, QUIC optimizations, and a new max_age option in the forward plugin.
    • Additional updates include enhanced SVCB/HTTPS support, improved zone transfer behavior, and various DNSSEC, PROXY protocol, and concurrency fixes.
    • The release is built with Go 1.26.2, which includes security fixes addressing CVE-2026-32282, CVE-2026-32289, CVE-2026-33810, CVE-2026-27144, CVE-2026-27143, CVE-2026-32288, CVE-2026-32283, and CVE-2026-27140, and also includes fixes for CVE-2026-32936, CVE-2026-33190, CVE-2026-33489, CVE-2026-32934, and CVE-2026-35579.
Record
openSUSE-SU-2026:20703-1
Updated
2026-11-02
OSVopenSUSE-SU-2026:21483-1 No score

Security update for govulncheck-vulndb

This update for govulncheck-vulndb fixes the following issues:

  • Update to version 0.0.20260723T184607 2026-07-23T18:46:07Z (jsc#PED-11136).

Go CVE Numbering Authority IDs added or updated with aliases:

  • GO-2026-4730 CVE-2026-33022 GHSA-cv4x-93xx-wgfj
  • GO-2026-4761 CVE-2026-33211 GHSA-j5q5-j9gm-2w5c
  • GO-2026-5102 CVE-2026-45021 GHSA-3vcp-chfh-f6r2
  • GO-2026-5272 CVE-2026-40938 GHSA-94jr-7pqp-xhcq
  • GO-2026-5486 CVE-2026-40924 GHSA-m2cx-gpqf-qf74
  • GO-2026-5542 CVE-2026-40090 GHSA-pj97-4p9w-gx3q
  • GO-2026-5630 CVE-2026-25542 GHSA-rmx9-2pp3-xhcr
  • GO-2026-5643 CVE-2026-40923 GHSA-rx35-6rhx-7858
  • GO-2026-5675 CVE-2026-41492 GHSA-vvf7-6rmr-m29q
  • GO-2026-5711 CVE-2026-40161 GHSA-wjxp-xrpv-xpff
  • GO-2026-5746 CVE-2026-41567 GHSA-x86f-5xw2-fm2r
  • GO-2026-5749 CVE-2026-41328 GHSA-x92x-px7w-4gx4
  • GO-2026-5837 CVE-2026-44840 GHSA-q2m9-6jp9-c6mc
  • GO-2026-5929 CVE-2026-44342 GHSA-26v7-h57m-gh9m
  • GO-2026-5930 CVE-2026-33655 GHSA-6qcr-qxgr-m7fv
  • GO-2026-5933 GHSA-3g4q-2f67-2gvh
  • GO-2026-5934 GHSA-59qp-cfj3-rp64
  • GO-2026-5935 GHSA-7856-g3gv-9wq8
  • GO-2026-5936 CVE-2026-53552 GHSA-26rh-24rg-j3vv
  • GO-2026-5937 CVE-2026-53508 GHSA-2jcc-mxv7-p3f9
  • GO-2026-5938 CVE-2026-53553 GHSA-4g5x-hcwm-82jw
  • GO-2026-5939 CVE-2026-10517 GHSA-698x-9w2p-7vvp
  • GO-2026-5940 CVE-2026-53572 GHSA-6w3m-4hhp-775q
  • GO-2026-5941 CVE-2026-53487 GHSA-gvhc-wv3v-7pf8
  • GO-2026-5942 CVE-2026-46600
  • GO-2026-5944 CVE-2026-50197 GHSA-659f-rgp5-w4wf
  • GO-2026-5945 CVE-2026-6815 GHSA-rmxx-v9rj-vpvg
  • GO-2026-5946 CVE-2026-52831 GHSA-v5px-423j-pf7p
  • GO-2026-5947 CVE-2026-53649 GHSA-xqhv-chqm-fhcc
  • GO-2026-5948 CVE-2026-50554 GHSA-588f-fvcv-xhvf
  • GO-2026-5949 CVE-2026-50553 GHSA-rqrh-8wpv-x7hh
  • GO-2026-5950 CVE-2026-53602 GHSA-339v-266x-79xr
  • GO-2026-5951 CVE-2026-10219 GHSA-6jm8-4fhr-5w64
  • GO-2026-5952 CVE-2026-49834 GHSA-9vcr-p3rj-q5q6
  • GO-2026-5953 CVE-2026-9094 GHSA-c9w5-qp6m-m395
  • GO-2026-5956 CVE-2026-55252 GHSA-h5g6-xmh4-hc37
  • GO-2026-5957 CVE-2026-54158 GHSA-5xfx-xj4h-5p7r
  • GO-2026-5958 CVE-2026-54068 GHSA-gcm7-57gf-953c
  • GO-2026-5959 CVE-2026-54072 GHSA-h29v-hj44-q8cv
  • GO-2026-5961 CVE-2026-54069 GHSA-hvr9-72v2-fff3
  • GO-2026-5962 CVE-2026-54088 GHSA-m93h-4hw7-5qcm
  • GO-2026-5963 CVE-2026-54067 GHSA-mvjr-vv3c-w4qv
  • GO-2026-5964 CVE-2026-54066 GHSA-p4m3-mgmm-c664
  • GO-2026-5965 CVE-2026-54070 GHSA-w7cg-whh7-xp28
  • GO-2026-5966 CVE-2026-54089 GHSA-xqp3-jq6g-x3qm
  • GO-2026-5967 CVE-2026-50551 GHSA-56mp-4f3v-fgj2
  • GO-2026-5968 CVE-2026-54174 GHSA-fpg8-7664-jc5q
  • GO-2026-5969 GHSA-g936-7jqj-mwv8
  • GO-2026-5970 CVE-2026-56852
  • GO-2026-5973 CVE-2026-54250 GHSA-jxr7-mqhw-9p98
  • GO-2026-5974 CVE-2026-44300 GHSA-wmj8-9953-vff5
  • GO-2026-5975 CVE-2026-50018 GHSA-42j2-w334-qxw7
  • GO-2026-5976 CVE-2026-50141 GHSA-g7mm-9vx7-jm7h
  • GO-2026-5977 CVE-2026-50013 GHSA-qrh4-p6v4-mrfg
  • GO-2026-5978 CVE-2026-50125 GHSA-qw5r-ppcg-f8rj
  • GO-2026-5979 CVE-2026-50006 GHSA-xrcf-6jh3-ggvx
  • GO-2026-5980 CVE-2026-50158 GHSA-2c7f-fxww-6w6c
  • GO-2026-5981 GHSA-mqxv-9rm6-w8qc
  • GO-2026-5982 GHSA-pqg7-v6wh-3pfp
  • GO-2026-5984 CVE-2026-53604 GHSA-2p2f-px33-4vv5
  • GO-2026-5985 GHSA-7rx3-5wx3-5v76
  • GO-2026-5986 CVE-2026-61699 GHSA-cm26-5974-52h8
  • GO-2026-5987 CVE-2026-55513 GHSA-g4x6-jcvr-9m3g
  • GO-2026-5988 CVE-2026-54628 GHSA-hwrq-8wxh-q4xv
  • GO-2026-5989 CVE-2026-55512 GHSA-m3cx-mwpg-32jg
  • GO-2026-5990 CVE-2026-54629 GHSA-mf78-3rpf-r784
  • GO-2026-5991 CVE-2026-53603 GHSA-q4vm-pq3q-8wgq
  • GO-2026-5992 CVE-2026-61549 GHSA-qf34-295c-26v8
  • GO-2026-5996 CVE-2026-54450 GHSA-pph6-vfjv-vpjw
  • GO-2026-5997 CVE-2026-54452 GHSA-xgch-x3mx-cm3c
  • GO-2026-5998 CVE-2026-54495 GHSA-398h-7f66-3h4p
  • GO-2026-5999 CVE-2026-10814 GHSA-jh6h-v6mp-h22v
  • GO-2026-6002 CVE-2026-58196 GHSA-pr64-jmmf-jp54
  • GO-2026-6003 CVE-2026-53714 GHSA-22xc-xg2r-9j7v
  • GO-2026-6004 CVE-2026-52833 GHSA-3v79-m2cg-89ww
  • GO-2026-6005 CVE-2026-53715 GHSA-8fv2-88gg-hm7q
  • GO-2026-6006 CVE-2026-53716 GHSA-cxpq-8v7q-cg56 *…
Record
openSUSE-SU-2026:21483-1
Updated
2026-11-02

Affected products

Affected packages

Affected packages
PackageAffectedFixed
github.com/coredns/coredns
Go
 before 1.14.3
1.14.3
coredns
Azure Linux:3
 before 1.11.4-16
1.11.4-16
coredns
openEuler:22.03-LTS-SP4
 before 1.7.0-1.8.oe2203sp4
1.7.0-1.8.oe2203sp4
coredns
openEuler:24.03-LTS-SP1
 before 1.7.0-1.8.oe2403sp1
1.7.0-1.8.oe2403sp1
coredns
openEuler:24.03-LTS-SP3
 before 1.7.0-1.8.oe2403sp3
1.7.0-1.8.oe2403sp3
coredns
openEuler:20.03-LTS-SP4
 before 1.7.0-1.6.oe2003sp4
1.7.0-1.6.oe2003sp4
coredns
openEuler:24.03-LTS-SP4
 before 1.7.0-1.8.oe2403sp4
1.7.0-1.8.oe2403sp4
govulncheck-vulndb
openSUSE:Leap 16.0
From an advisory covering 1734 CVEs
 before 0.0.20260723T184607-160000.1.1
0.0.20260723T184607-160000.1.1

History

History
RecordedChangedSources
affected
factsOSV
first indexedCVE List, EUVD, GitHub Advisories, NVD, OSV

Dates are when Every CVE recorded each change. Upstream dates may differ.

In short

CVE-2026-35579 is a high vulnerability (CVSS 8.2) in Coredns, published April 28, 2026. No source lists public exploit code. EPSS puts the chance of exploitation in the next 30 days at 0.61%, the 49th percentile. Fixed in github.com/coredns/coredns 1.14.3.

References

Show 194 moreShow less
This page doesn't list everything

Left out here: 1,549 references and the rest of 3 source descriptions. The JSON record has them.

Pages All vulnerabilities Browse Docs Sources Guide Get API key
MoveEnter Open