CVE-2026-33190

What it actually does

CoreDNS versions before 1.14.3 can incorrectly allow DNS queries that should be blocked by the tsig plugin when those queries arrive over encrypted or alternate transports: DNS-over-TLS, DNS-over-HTTPS, DNS-over-HTTP/3, DNS-over-QUIC, and gRPC. The vulnerable code relies on the transport writer's TSIG status instead of independently validating the TSIG signature. Several of those transport implementations return a successful or nil TSIG status even when no valid TSIG authentication occurred. As a result, a remote unauthenticated client can bypass a `tsig require all` policy and access DNS resources that operators intended to restrict. Plain DNS over UDP and TCP is not affected.

Why it matters to the business

Organizations using CoreDNS to protect sensitive zones, service-discovery records, internal hostnames, or other restricted DNS data with TSIG may unintentionally expose that information over DoT, DoH, DoH3, DoQ, or gRPC listeners. The most likely consequence is confidentiality loss: attackers can enumerate private DNS records, discover internal infrastructure, map services, and use that information to support later intrusion activity. The issue is not currently listed in CISA KEV, has no reported ransomware association, and has a low, stable EPSS score, but it is remotely exploitable without credentials and should be prioritized anywhere CoreDNS exposes non-plain-DNS transports with TSIG-based access control.

How an attack unfolds

An attacker first identifies a CoreDNS service that supports one of the affected non-plain-DNS transports, such as DoH on an HTTPS endpoint, DoT over TLS, DoQ, DoH3, or gRPC. The attacker then sends DNS queries for records or zones that are expected to be protected by a `tsig require all` policy, but omits TSIG authentication or supplies an invalid TSIG. On vulnerable versions, the relevant transport writer reports a nil or successful TSIG status, or the server is not configured in a way that allows TSIG verification to occur for that transport. The tsig plugin therefore treats the request as authenticated and allows processing to continue. If the queried data exists and the rest of the CoreDNS plugin chain permits the response, the attacker receives DNS answers that should have been refused. The attacker can repeat this process to enumerate restricted names, service records, infrastructure metadata, or other sensitive DNS content.

How to fix it

Upgrade CoreDNS to version 1.14.3 or later. This is the primary fix because the defect is in how TSIG status is handled for non-plain-DNS transports. If immediate upgrade is not possible, disable or restrict affected transports that rely on TSIG for authorization: DoT, DoH, DoH3, DoQ, and gRPC. Limit access to those listeners using network controls, reverse-proxy ACLs, firewall rules, mutual TLS, VPN-only exposure, or source allowlists. Do not rely on `tsig require all` as the sole access-control mechanism for affected transports until upgraded. Plain DNS over UDP and TCP are not affected by this specific issue, but deployments should still validate that TSIG policy behaves as expected after configuration changes.

How to confirm the fix worked

Confirm the deployed CoreDNS version is 1.14.3 or later, for example by checking the container image tag, package version, binary version output, or build metadata used to deploy CoreDNS. Review CoreDNS Corefile configuration for use of the `tsig` plugin, especially `tsig require all`, together with DoT, DoH, DoH3, DoQ, or gRPC listeners. To validate behavior, send an unauthenticated DNS query over each enabled affected transport to a zone or record that should require TSIG. A fixed or safely mitigated deployment should reject the request, commonly with REFUSED or an equivalent failure, and should not return protected DNS answers. Also test a valid TSIG-signed request where applicable to ensure legitimate clients continue to work after the upgrade or mitigation.

Typical attack path

1. Scan for CoreDNS or DNS services exposing DoH, DoT, DoH3, DoQ, or gRPC-based DNS access.
2. Identify DNS zones, record names, or service-discovery patterns likely to be protected by TSIG.
3. Send DNS queries over an affected transport without a TSIG record or with an invalid TSIG signature.
4. Observe that the server returns normal DNS responses instead of refusing the unauthenticated request.
5. Automate queries to enumerate restricted records and map infrastructure or services.
6. Use the discovered DNS information to support follow-on reconnaissance, targeting, phishing, lateral movement planning, or service abuse.

How to detect it

To determine whether this was already exploited, review CoreDNS query logs, reverse-proxy logs, load-balancer logs, TLS listener logs, DoH access logs, DoQ/DoH3 telemetry, and gRPC access logs for requests to TSIG-protected zones over affected transports before the upgrade to 1.14.3. Focus on queries from untrusted or unexpected source IPs that were made over DoH, DoT, DoH3, DoQ, or gRPC and returned successful DNS answers despite lacking valid TSIG authentication. If CoreDNS query logging was not enabled, use surrounding telemetry such as HTTPS access logs for `/dns-query`, TLS connection logs to DNS-over-TLS listeners, QUIC/HTTP3 listener logs, and firewall or flow logs showing repeated connections to DNS transport ports. Compare queried names against zones protected by `tsig require all`; successful NOERROR, NODATA, or NXDOMAIN responses to unauthenticated clients are more suspicious than REFUSED responses. Look for enumeration patterns such as high-volume queries, sequential hostname guessing, broad SRV/TXT lookups, repeated subdomain discovery attempts, and requests from internet scanners or infrastructure not associated with legitimate TSIG clients. Because encrypted transports may hide DNS payloads from network sensors, application-layer logs at CoreDNS, the TLS/HTTP proxy, or the DNS gateway are the most useful evidence sources.

• /dns-query
• GET /dns-query
• POST /dns-query
• application/dns-message
• Content-Type: application/dns-message
• h2 /dns-query
• h3 /dns-query
• DoH
• DoH3
• DoT
• DoQ
• grpc
• tsig require all
• NOERROR
• REFUSED

What your security team should do

• Inventory CoreDNS deployments and identify any instances running versions earlier than 1.14.3.
• Prioritize remediation for CoreDNS servers exposing DoH, DoT, DoH3, DoQ, or gRPC and using the tsig plugin to protect restricted resources.
• Upgrade CoreDNS to 1.14.3 or later across affected deployments.
• Until upgraded, restrict or disable affected non-plain-DNS transports where TSIG is used for authorization.
• Review CoreDNS Corefiles for `tsig require all` policies and confirm they are not the only control protecting sensitive DNS data over affected transports.
• Enable or increase DNS query logging temporarily for protected zones to identify unexpected access over affected transports.
• Search historical DoH, DoT, DoQ, DoH3, gRPC, proxy, and CoreDNS logs for unauthorized queries that received successful responses before remediation.
• After patching, run negative tests using unsigned or invalidly signed queries over every enabled affected transport to confirm access is denied.