ghsa-cvx7-x8pj-x2gw
Vulnerability from github
Summary
A Denial of Service (DoS) vulnerability was discovered in the CoreDNS DNS-over-QUIC (DoQ) server implementation. The server previously created a new goroutine for every incoming QUIC stream without imposing any limits on the number of concurrent streams or goroutines. A remote, unauthenticated attacker could open a large number of streams, leading to uncontrolled memory consumption and eventually causing an Out Of Memory (OOM) crash — especially in containerized or memory-constrained environments.
Impact
- Component:
server_quic.go
- Attack Vector: Remote, network-based
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Impact: High availability loss (OOM kill or unresponsiveness)
This issue affects deployments with quic://
enabled in the Corefile. A single attacker can cause the CoreDNS instance to become unresponsive using minimal bandwidth and CPU.
Patches
The patch introduces two key mitigation mechanisms:
max_streams
: Caps the number of concurrent QUIC streams per connection. Default:256
.worker_pool_size
: Introduces a server-wide, bounded worker pool to process incoming streams. Default:1024
.
This eliminates the 1:1 stream-to-goroutine model and ensures that CoreDNS remains resilient under high concurrency. The new configuration options are exposed through the quic
Corefile block:
quic {
max_streams 256
worker_pool_size 1024
}
These defaults are generous and aligned with typical DNS-over-QUIC client behavior.
Workarounds
If you're unable to upgrade immediately, you can:
- Disable QUIC support by removing or commenting out the quic://
block in your Corefile
- Use container runtime resource limits to detect and isolate excessive memory usage
- Monitor QUIC connection patterns and alert on anomalies
References
- RFC 9250 - DNS over Dedicated QUIC Connections
- quic-go GitHub project
- QUIC stream exhaustion class of vulnerabilities (related)
Credit
Thanks to @thevilledev for disclovering this vulnerability and contributing a high-quality fix.
For more information
Please consult our security guide for more information regarding our security process.
{ "affected": [ { "package": { "ecosystem": "Go", "name": "github.com/coredns/coredns" }, "ranges": [ { "events": [ { "introduced": "0" }, { "fixed": "1.12.2" } ], "type": "ECOSYSTEM" } ] } ], "aliases": [ "CVE-2025-47950" ], "database_specific": { "cwe_ids": [ "CWE-770" ], "github_reviewed": true, "github_reviewed_at": "2025-06-06T21:27:27Z", "nvd_published_at": "2025-06-06T18:15:35Z", "severity": "HIGH" }, "details": "### Summary\n\nA **Denial of Service (DoS)** vulnerability was discovered in the CoreDNS DNS-over-QUIC (DoQ) server implementation. The server previously created a new goroutine for every incoming QUIC stream without imposing any limits on the number of concurrent streams or goroutines. A remote, unauthenticated attacker could open a large number of streams, leading to uncontrolled memory consumption and eventually causing an Out Of Memory (OOM) crash \u2014 especially in containerized or memory-constrained environments.\n\n### Impact\n\n- **Component**: `server_quic.go`\n- **Attack Vector**: Remote, network-based\n- **Attack Complexity**: Low\n- **Privileges Required**: None\n- **User Interaction**: None\n- **Impact**: High availability loss (OOM kill or unresponsiveness)\n\nThis issue affects deployments with `quic://` enabled in the Corefile. A single attacker can cause the CoreDNS instance to become unresponsive using minimal bandwidth and CPU.\n\n### Patches\n\nThe patch introduces two key mitigation mechanisms:\n\n- **`max_streams`**: Caps the number of concurrent QUIC streams per connection. Default: `256`.\n- **`worker_pool_size`**: Introduces a server-wide, bounded worker pool to process incoming streams. Default: `1024`.\n\nThis eliminates the 1:1 stream-to-goroutine model and ensures that CoreDNS remains resilient under high concurrency. The new configuration options are exposed through the `quic` Corefile block:\n\n```\nquic {\n max_streams 256\n worker_pool_size 1024\n}\n```\n\nThese defaults are generous and aligned with typical DNS-over-QUIC client behavior.\n\n### Workarounds\n\nIf you\u0027re unable to upgrade immediately, you can:\n- Disable QUIC support by removing or commenting out the `quic://` block in your Corefile\n- Use container runtime resource limits to detect and isolate excessive memory usage\n- Monitor QUIC connection patterns and alert on anomalies\n\n### References\n\n- [RFC 9250 - DNS over Dedicated QUIC Connections](https://datatracker.ietf.org/doc/html/rfc9250)\n- [quic-go GitHub project](https://github.com/quic-go/quic-go)\n- [QUIC stream exhaustion class of vulnerabilities (related)](https://www.usenix.org/conference/usenixsecurity23/presentation/botella)\n\n### Credit\n\nThanks to [@thevilledev](https://github.com/thevilledev) for disclovering this vulnerability and contributing a high-quality fix.\n\n### For more information\n\nPlease consult our [security guide](https://github.com/coredns/coredns/blob/master/.github/SECURITY.md) for more information regarding our security process.", "id": "GHSA-cvx7-x8pj-x2gw", "modified": "2025-06-09T21:39:31Z", "published": "2025-06-06T21:27:27Z", "references": [ { "type": "WEB", "url": "https://github.com/coredns/coredns/security/advisories/GHSA-cvx7-x8pj-x2gw" }, { "type": "ADVISORY", "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-47950" }, { "type": "WEB", "url": "https://github.com/coredns/coredns/commit/efaed02c6a480ec147b1f799aab7cf815b17dfe1" }, { "type": "WEB", "url": "https://datatracker.ietf.org/doc/html/rfc9250" }, { "type": "PACKAGE", "url": "https://github.com/coredns/coredns" }, { "type": "WEB", "url": "https://github.com/quic-go/quic-go" }, { "type": "WEB", "url": "https://www.usenix.org/conference/usenixsecurity23/presentation/botella" } ], "schema_version": "1.4.0", "severity": [ { "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H", "type": "CVSS_V3" } ], "summary": "CoreDNS Vulnerable to DoQ Memory Exhaustion via Stream Amplification" }
Sightings
Author | Source | Type | Date |
---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.