Withdrawn by the publisher.

Affected: CleanStart: kubernetes-dns-node-cache

Package kubernetes-dns-node-cache version 1.25.0-r8 fixes 17 vulnerabilities: CVE-2026-41178, CVE-2026-35579, CVE-2026-46600, CVE-2025-64702, CVE-2025-68151...

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.

Affected: Go: github.com/coredns/coredns

### 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:

```go 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 d…

Affected: openEuler:22.03-LTS-SP4: coredns

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 sourc…

Security update for coredns

github.com/containerd/containerd: containerd local privilege escalation golang: net/url: Memory exhaustion in query parameter parsing in net/url golang: archive/zip: Excessive CPU consumption when building archive index in archive/zip crypto/x509: golang: Denial of Service due to excessive resource consumption via crafted certificate crypto/tls: crypto/tls: Incorrect certificate validation during TLS session resumption github.com/coredns/coredns/core/dnsserver: CoreDNS DoS via unbounded connections and oversized messages urllib3: urllib3 vulnerable to decompression-bomb safeguard bypass when following HTTP redirects (streaming API) net/url: Incorrect parsing of IPv6 host literals in net/url github.com/coredns/coredns: CoreDNS: DNS access control bypass due to plugin execution order flaw github.com/coredns/coredns: CoreDNS: Denial of Service vulnerability due to predictable pseudo-random number generation crypto/x509: crypto/tls: golang: Go: Denial of Service vulnerability in certificate chain building github.com/coredns/coredns: CoreDNS: Denial of Service via oversized DNS-over-HTTPS GET requests google.golang.org/grpc/grpc-go: google.golang.org/grpc/authz: gRPC-Go: Authorization bypass due to improper HTTP/2 path validation github.com/go-jose/go-jose/v3: github.com/go-jose/go-jose/v4: Go JOSE: Denial of Service via crafted JSON Web Encryption (JWE) object github.com/coredns/coredns: CoreDNS: Authentication bypass allows unauthorized access to TSIG-protected functionalities

Ein entfernter, anonymer Angreifer kann mehrere Schwachstellen in CoreDNS ausnutzen, um Sicherheitsmaßnahmen zu umgehen und so vertrauliche Informationen offenzulegen oder einen Denial-of-Service-Zustand zu verursachen.