CoreDNS
cpe:2.3:a:coredns.io:coredns:*:*:*:*:*:*:*
- < 1.14.3
A vulnerability exists in CoreDNS versions prior to 1.14.3, where the gRPC, QUIC, DoH, and DoH3 transport implementations improperly manage TSIG authentication. In gRPC and QUIC, the server verifies the existence of the TSIG key name in the configuration but fails to validate the HMAC. If the key name is recognized, the tsigStatus field remains nil, allowing the tsig plugin to treat the request as authenticated, regardless of the MAC value. The situation is more critical for DoH and DoH3, where the DoHWriter.TsigStatus() method always returns nil, and the server does not examine the TSIG record at all. Consequently, any request with a TSIG record is considered authenticated over DoH and DoH3, even if the key name is invalid and the MAC is random. This flaw enables an unauthenticated network attacker to bypass TSIG authentication and exploit TSIG-protected functionalities, such as AXFR/IXFR zone transfers, dynamic DNS updates, or other TSIG-restricted plugin behaviors.
Exploitation allows an unauthenticated network attacker to bypass TSIG authentication on the affected CoreDNS transports, potentially leading to unauthorized access to TSIG-protected functionalities. This includes performing AXFR or IXFR zone transfers, dumping TSIG-protected zone data, submitting dynamic DNS updates (if enabled), bypassing other TSIG-gated plugin behaviors, and for DoH or DoH3, authenticating without a valid TSIG key name.
The vulnerability can be reproduced by sending DNS requests over the affected transports (gRPC, QUIC, DoH, or DoH3) with forged TSIG records. For gRPC and QUIC, requests can be made using a valid TSIG key name but with invalid MAC values, which will be accepted as authenticated. For DoH and DoH3, any TSIG record will be accepted, regardless of its validity, allowing for authentication bypass.
Users should upgrade to CoreDNS version 1.14.3 or later. If an immediate upgrade is not possible, gRPC, QUIC, DoH, and DoH3 listeners can be disabled where TSIG authentication is required, or network-level access to the affected transport ports can be restricted to trusted sources only.
Our algorithm analyzes dozens of metrics to generate these 8 key vulnerability categories, which are then combined to calculate the overall risk score.