Listen to this Post
How the CVE Works (Technical Details):
The vulnerability stems from incomplete TSIG verification in CoreDNS transports. For gRPC and QUIC, the server_grpc.go and server_quic.go code checks only the TSIG key name existence but never calls dns.TsigVerify() to validate the HMAC. If the key name matches a configured secret, tsigStatus remains nil, which the tsig plugin interprets as successful authentication. Thus, an attacker can send a request with a valid key name but any forged MAC (zero bytes, random, wrong secret, truncated, or single byte) and bypass authentication. For DoH and DoH3, the failure is even worse: DoHWriter.TsigStatus() is hardcoded to return nil unconditionally in https.go. The server_https.go and server_https3.go unpack the DNS message directly from HTTP requests without any TSIG check – no key name lookup, no dns.TsigVerify(). Any request containing a TSIG record, even with an invalid key name or garbage MAC, is passed to ServeDNS() as “verified”. The tsig plugin sees nil status and grants access. Attackers can exploit this to perform unauthorized AXFR/IXFR zone transfers, dynamic updates, or bypass TSIG-gated plugins. The PoC shows that over gRPC 6/7 forged MACs succeed, and over DoH 7/8 variants (including wrong key name) succeed, while TCP correctly rejects them. The root cause is that transport layers report successful verification when verification either did not happen or only checked the key name.
DailyCVE Form:
Platform: CoreDNS
Version: <=1.14.2
Vulnerability: TSIG bypass
Severity: Critical
Date: 2025-04-15
Prediction: Patch 2025-05-15
What Undercode Say:
Analytics: Attackers can trivially spoof TSIG. DoH/DoH3 require zero key knowledge. gRPC/QUIC need only a valid key name (leaked or guessed). Zone data exposure risk is high.
Bash commands & codes:
Example: Forged AXFR over gRPC using grpcurl with custom DNS message (simplified)
Generate a raw DNS AXFR query with TSIG record (zero MAC) using dnsgo or custom Python
python3 -c "
import dns.message, dns.tsig, dns.query
q = dns.message.make_query('example.com', 'AXFR')
q.use_tsig(keyname='fake_key', secret='', algorithm='hmac-sha256')
Force MAC to zeros (modify wire format)
wire = q.to_wire()
Replace MAC with 32 zero bytes
forge = wire[:len(wire)-32] + b'\x00'32
Send over gRPC proxy (example using grpcurl)
"
Over DoH with curl – any TSIG record bypasses
curl -k -X POST https://localhost:8443/dns-query \
-H "Content-Type: application/dns-message" \
--data-binary @forged_axfr.bin
Exploit:
- For gRPC/QUIC: Send AXFR request with known TSIG key name (e.g., from config leak) and arbitrary MAC (all zeros). CoreDNS accepts and returns full zone.
- For DoH/DoH3: Send any DNS query (AXFR, update) with a TSIG record of any key name and any MAC – even invalid. CoreDNS treats as authenticated and processes request.
- No need to know actual secret. DoH attackers need zero knowledge of key name.
Protection from this CVE:
- Upgrade CoreDNS to version with complete TSIG verification (≥1.14.3 or patched build from PR 7943/7947 plus HMAC verification).
- Disable gRPC, QUIC, DoH, and DoH3 listeners where TSIG authentication is required.
- Restrict network access to transport ports (e.g., 1443, 8443) to trusted IPs only.
- Avoid exposing TSIG-protected functionality (AXFR, dynamic updates) over affected transports.
- Monitor logs for TSIG requests with mismatched MAC or unknown key names accepted (indicates exploitation attempt).
Impact:
- Unauthenticated attacker can execute full zone transfers (AXFR/IXFR) over gRPC, QUIC, DoH, DoH3, leaking all DNS records.
- Perform unauthorized dynamic DNS updates, altering zone data.
- Bypass any plugin that relies on TSIG for access control (e.g., `tsig` plugin with
require all). - DoH/DoH3 attack has lowest bar: any TSIG record works, no key name needed.
- Leads to complete compromise of TSIG-protected zones, violating confidentiality and integrity.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
