{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/products/coredns/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cves":[{"cvss":7.5,"id":"CVE-2025-47950"}],"_cs_exploited":false,"_cs_products":["coredns"],"_cs_severities":["medium"],"_cs_tags":["coredns","dos","denial-of-service","vulnerability"],"_cs_type":"advisory","_cs_vendors":["coredns"],"content_html":"\u003cp\u003eA denial-of-service vulnerability exists in CoreDNS\u0026rsquo; DNS-over-QUIC (DoQ) server implementation. A remote, unauthenticated attacker can exploit this flaw by opening numerous QUIC streams and sending only a single byte, causing the server to exhaust memory resources. This occurs because CoreDNS spawns a goroutine per accepted stream, even when the worker pool is full, and workers can block indefinitely when reading incomplete DoQ messages. The vulnerability is present in CoreDNS versions prior to 1.14.3. The root cause is an incomplete fix/regression for CVE-2025-47950, highlighting the risk of regressions in security patches. This can lead to service outages and impacts DNS resolution availability for affected systems.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker establishes multiple QUIC connections to the CoreDNS server on the DoQ port (default 853).\u003c/li\u003e\n\u003cli\u003eFor each connection, the attacker opens a large number of QUIC streams.\u003c/li\u003e\n\u003cli\u003eOn each stream, the attacker sends only the first byte of the 2-byte length prefix expected for a DoQ message.\u003c/li\u003e\n\u003cli\u003eThe CoreDNS server accepts each stream and spawns a goroutine to handle it, regardless of worker pool capacity. These goroutines wait for a worker token.\u003c/li\u003e\n\u003cli\u003eThe worker goroutines attempt to read the full 2-byte length prefix using \u003ccode\u003eio.ReadFull()\u003c/code\u003e, blocking indefinitely because the second byte is never sent by the attacker.\u003c/li\u003e\n\u003cli\u003eAs the attacker opens more streams, the backlog of waiting goroutines grows without bound, consuming memory.\u003c/li\u003e\n\u003cli\u003eThe server\u0026rsquo;s memory usage increases rapidly, potentially leading to an OOM-kill.\u003c/li\u003e\n\u003cli\u003eThe CoreDNS service becomes unavailable, resulting in a denial-of-service condition.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this vulnerability leads to a denial-of-service condition on the CoreDNS server. The server experiences excessive memory consumption and goroutine growth, potentially leading to an OOM-kill and service outage. The number of victims depends on the deployment size and exposure of the CoreDNS server. All organizations using affected versions of CoreDNS are vulnerable. This impacts DNS resolution, potentially disrupting all network services that rely on the affected CoreDNS server.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade CoreDNS to version 1.14.3 or later to patch CVE-2026-32934 and mitigate the DoS vulnerability.\u003c/li\u003e\n\u003cli\u003eMonitor CoreDNS server resource usage (CPU, memory, goroutine count) for anomalous spikes that could indicate exploitation.\u003c/li\u003e\n\u003cli\u003eImplement rate limiting or connection limits on the DoQ port (853) to reduce the impact of a potential attack.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eDetect CoreDNS Excessive Goroutine Growth\u003c/code\u003e to identify potential exploitation attempts.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-28T22:41:50Z","date_published":"2026-04-28T22:41:50Z","id":"/briefs/2026-05-coredns-doq-dos/","summary":"CoreDNS' DNS-over-QUIC (DoQ) server can be driven into large goroutine and memory growth by a remote client that opens many QUIC streams and stalls after sending only 1 byte, leading to denial of service in versions before 1.14.3.","title":"CoreDNS DoQ Server Denial-of-Service Vulnerability","url":"https://feed.craftedsignal.io/briefs/2026-05-coredns-doq-dos/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["coredns"],"_cs_severities":["high"],"_cs_tags":["coredns","tsig","authentication-bypass"],"_cs_type":"advisory","_cs_vendors":["coredns"],"content_html":"\u003cp\u003eCoreDNS versions prior to 1.14.3 contain a flaw in the handling of TSIG authentication for gRPC, QUIC, DoH, and DoH3 transports. Specifically, gRPC and QUIC transports only check for the presence of a TSIG key name without verifying the HMAC, while DoH and DoH3 transports unconditionally return a successful TSIG status. This vulnerability allows unauthenticated attackers to bypass TSIG authentication, potentially enabling unauthorized zone transfers, dynamic updates, and access to other TSIG-protected resources. This issue was identified in version 1.14.2 and prior, and affects deployments where TSIG authentication is relied upon for secure DNS operations over these transports.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker identifies a CoreDNS server using gRPC, QUIC, DoH, or DoH3 with TSIG authentication enabled.\u003c/li\u003e\n\u003cli\u003eFor gRPC/QUIC, the attacker crafts a DNS request with a valid TSIG key name but a forged or invalid HMAC value. For DoH/DoH3, the attacker crafts a DNS request with any TSIG record.\u003c/li\u003e\n\u003cli\u003eThe attacker sends the crafted request to the CoreDNS server via the affected transport (gRPC, QUIC, DoH, or DoH3).\u003c/li\u003e\n\u003cli\u003eCoreDNS receives the request and processes the TSIG information. For gRPC/QUIC, CoreDNS checks if the TSIG key name exists in the configuration. For DoH/DoH3, the transport layer reports successful TSIG verification without performing actual verification.\u003c/li\u003e\n\u003cli\u003eThe TSIG check passes due to the vulnerability: either HMAC is not validated (gRPC/QUIC) or TSIG status is unconditionally reported as valid (DoH/DoH3).\u003c/li\u003e\n\u003cli\u003eThe request is passed to the appropriate plugin, bypassing TSIG authentication requirements.\u003c/li\u003e\n\u003cli\u003eThe attacker gains access to TSIG-protected functionality, such as AXFR/IXFR zone transfers or dynamic DNS updates.\u003c/li\u003e\n\u003cli\u003eThe attacker exfiltrates zone data or modifies DNS records, depending on the enabled functionality.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this vulnerability can allow unauthenticated attackers to perform unauthorized actions on the affected CoreDNS server. This can lead to the exposure of sensitive zone data via AXFR/IXFR, unauthorized modification of DNS records through dynamic updates, or other bypasses of TSIG-gated plugin behavior. The DoH and DoH3 variants pose a higher risk because they do not even require a valid TSIG key name to be known. The impact depends on the specific TSIG-protected functionality enabled on the CoreDNS server and the sensitivity of the data being protected.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade CoreDNS to version 1.14.3 or later to patch CVE-2026-35579.\u003c/li\u003e\n\u003cli\u003eIf upgrading is not immediately possible, disable gRPC, QUIC, DoH, and DoH3 listeners where TSIG authentication is required as suggested in the advisory.\u003c/li\u003e\n\u003cli\u003eImplement network-level access controls to restrict access to gRPC, QUIC, DoH, and DoH3 ports to trusted sources only, as recommended in the advisory.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Detect CoreDNS AXFR Request over DoH with Forged TSIG\u0026rdquo; to identify potential exploitation attempts.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-24T12:00:00Z","date_published":"2024-01-24T12:00:00Z","id":"/briefs/2024-01-coredns-tsig-bypass/","summary":"CoreDNS versions prior to 1.14.3 are vulnerable to TSIG authentication bypass on gRPC, QUIC, DoH, and DoH3 transports, allowing unauthenticated network attackers to bypass authentication and potentially access TSIG-protected zone data or submit dynamic DNS updates.","title":"CoreDNS TSIG Authentication Bypass Vulnerability","url":"https://feed.craftedsignal.io/briefs/2024-01-coredns-tsig-bypass/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["CoreDNS"],"_cs_severities":["medium"],"_cs_tags":["cve","dos","coredns"],"_cs_type":"advisory","_cs_vendors":["CoreDNS"],"content_html":"\u003cp\u003eCoreDNS is susceptible to a denial-of-service vulnerability affecting its DNS-over-HTTPS (DoH) GET request handling. The vulnerability, identified as CVE-2026-32936, stems from the server\u0026rsquo;s excessive processing of oversized \u003ccode\u003edns=\u003c/code\u003e query parameters in GET requests to the \u003ccode\u003e/dns-query\u003c/code\u003e endpoint. An unauthenticated attacker can exploit this by sending specially crafted, oversized requests, forcing the server to expend significant CPU resources, allocate large amounts of memory, and increase garbage collection overhead before ultimately rejecting the request with a \u003ccode\u003e400 Bad Request\u003c/code\u003e error. This pre-validation processing weakness can degrade the server\u0026rsquo;s performance, impacting its ability to respond to legitimate requests, and potentially leading to a complete denial of service, especially in memory-constrained environments. The vulnerability affects CoreDNS versions prior to 1.14.3.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker crafts an HTTP GET request to the \u003ccode\u003e/dns-query\u003c/code\u003e endpoint.\u003c/li\u003e\n\u003cli\u003eThe crafted request includes a \u003ccode\u003edns=\u003c/code\u003e query parameter with an extremely large, base64 encoded value.\u003c/li\u003e\n\u003cli\u003eCoreDNS receives the request and parses the HTTP request line using \u003ccode\u003enet/http.readRequest\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe server parses the URL and extracts the value of the \u003ccode\u003edns\u003c/code\u003e query parameter via \u003ccode\u003ereq.URL.Query()\u003c/code\u003e within the \u003ccode\u003erequestToMsgGet\u003c/code\u003e function.\u003c/li\u003e\n\u003cli\u003eThe extracted base64-encoded value is passed to the \u003ccode\u003ebase64ToMsg\u003c/code\u003e function for decoding.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003ebase64ToMsg\u003c/code\u003e function uses \u003ccode\u003eb64Enc.DecodeString()\u003c/code\u003e to decode the oversized base64 string, consuming significant CPU and memory.\u003c/li\u003e\n\u003cli\u003eThe decoded data is then passed to \u003ccode\u003em.Unpack()\u003c/code\u003e to unpack it into a DNS message, further increasing resource consumption.\u003c/li\u003e\n\u003cli\u003eOnly after these resource-intensive operations, CoreDNS determines that the request is invalid and returns a \u003ccode\u003e400 Bad Request\u003c/code\u003e error, having already expended significant server resources.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this vulnerability can lead to a denial-of-service condition. Attackers can repeatedly send oversized DoH GET requests, leading to:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eElevated CPU consumption, potentially causing performance degradation for other services.\u003c/li\u003e\n\u003cli\u003eLarge transient memory allocations, leading to increased garbage collection pressure and potential memory exhaustion.\u003c/li\u003e\n\u003cli\u003eHigher peak resident memory usage, impacting overall system stability.\u003c/li\u003e\n\u003cli\u003eDegraded throughput and responsiveness for legitimate DNS queries.\u003c/li\u003e\n\u003cli\u003eUltimately, a denial of service, especially in resource-constrained or heavily loaded deployments.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eDetect CoreDNS DoH GET Oversized DNS Query\u003c/code\u003e to detect exploitation attempts by monitoring HTTP requests with abnormally large DNS query parameters.\u003c/li\u003e\n\u003cli\u003eUpgrade CoreDNS to version 1.14.3 or later to patch CVE-2026-32936.\u003c/li\u003e\n\u003cli\u003eImplement rate limiting for the \u003ccode\u003e/dns-query\u003c/code\u003e endpoint to mitigate the impact of a large volume of malicious requests.\u003c/li\u003e\n\u003cli\u003eConsider disabling the DoH GET method and only allowing DoH POST, which has built-in size limitations, as a temporary workaround.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-08T14:30:00Z","date_published":"2024-01-08T14:30:00Z","id":"/briefs/2024-01-08-coredns-doh-dos/","summary":"CoreDNS is vulnerable to a denial-of-service attack where processing oversized DNS-over-HTTPS GET requests exhausts resources prior to returning an error.","title":"CoreDNS DoH GET Query Denial-of-Service","url":"https://feed.craftedsignal.io/briefs/2024-01-08-coredns-doh-dos/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["CoreDNS"],"_cs_severities":["high"],"_cs_tags":["cve-2026-33489","acl-bypass","dns","zone-transfer","coredns"],"_cs_type":"advisory","_cs_vendors":["CoreDNS"],"content_html":"\u003cp\u003eA vulnerability exists in the CoreDNS transfer plugin related to Access Control List (ACL) stanza selection. When both a parent zone and a more-specific subzone are configured with transfer rules, CoreDNS versions prior to 1.14.3 may incorrectly prioritize the parent zone\u0026rsquo;s rule over the subzone\u0026rsquo;s due to a lexicographic string comparison instead of a proper longest-match algorithm. This can lead to a permissive parent-zone transfer rule overriding a more restrictive subzone rule, allowing unauthorized clients to perform AXFR/IXFR requests and retrieve zone contents they should not have access to. This vulnerability matters because it can expose sensitive DNS information to unauthorized parties, potentially aiding reconnaissance or enabling further attacks.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker identifies a CoreDNS server running a version prior to 1.14.3.\u003c/li\u003e\n\u003cli\u003eThe attacker determines that the CoreDNS server is configured with both a parent zone (e.g., example.org.) and a subzone (e.g., a.example.org.) with different transfer ACLs. The parent zone\u0026rsquo;s ACL is more permissive than the subzone\u0026rsquo;s.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts an AXFR or IXFR request specifically targeting the subzone (a.example.org.).\u003c/li\u003e\n\u003cli\u003eThe CoreDNS server\u0026rsquo;s transfer plugin incorrectly selects the parent zone\u0026rsquo;s ACL due to the lexicographic comparison logic, which favors \u0026ldquo;example.org.\u0026rdquo; over \u0026ldquo;a.example.org.\u0026rdquo;.\u003c/li\u003e\n\u003cli\u003eThe server authorizes the transfer based on the permissive parent zone ACL.\u003c/li\u003e\n\u003cli\u003eThe CoreDNS server responds to the attacker\u0026rsquo;s request, providing the full zone contents of the subzone.\u003c/li\u003e\n\u003cli\u003eThe attacker receives the zone data, gaining access to information such as hostnames, IP addresses, and other DNS records that should have been protected by the subzone\u0026rsquo;s restrictive ACL.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this vulnerability allows unauthorized zone transfers, exposing sensitive DNS information. The impact is significant as it can lead to the disclosure of internal network structures, server names, and other critical data, potentially facilitating reconnaissance for further attacks. The severity is compounded by the non-intuitive nature of the vulnerability, making it difficult to detect and remediate without a clear understanding of the underlying issue.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade CoreDNS to version 1.14.3 or later to address the vulnerability (CVE-2026-33489).\u003c/li\u003e\n\u003cli\u003eReview CoreDNS transfer configurations to ensure subzone ACLs are not inadvertently bypassed by more permissive parent zone ACLs.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T10:00:00Z","date_published":"2024-01-03T10:00:00Z","id":"/briefs/2024-01-03-coredns-acl-bypass/","summary":"CoreDNS' transfer plugin prior to version 1.14.3 can select the wrong ACL stanza due to lexicographic comparison, leading to unauthorized zone transfers by clients intended to be denied by subzone-specific transfer policies.","title":"CoreDNS Transfer Plugin ACL Bypass Vulnerability","url":"https://feed.craftedsignal.io/briefs/2024-01-03-coredns-acl-bypass/"}],"language":"en","title":"CraftedSignal Threat Feed — CoreDNS","version":"https://jsonfeed.org/version/1.1"}