How severe is CVE-2026-32934?

No CVSS score has been assigned to CVE-2026-32934 yet. Review the advisory details and affected package list to assess your exposure.

Which packages are affected by CVE-2026-32934?

CVE-2026-32934 affects the following packages: github.com/coredns/coredns (Go). Ecosystems affected: Go.

How do I fix CVE-2026-32934?

Update github.com/coredns/coredns to 1.14.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-32934 is resolved across your whole dependency graph.

How do I detect CVE-2026-32934 in my Go dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/coredns/coredns, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

How do I mitigate CVE-2026-32934 if there is no patch (or I can't update yet)?

Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.

Is CVE-2026-32934 actively exploited in the wild?

No public exploit code has been indexed for CVE-2026-32934 yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

What is the EPSS score for CVE-2026-32934?

CVE-2026-32934 has an EPSS (Exploit Prediction Scoring System) score of 0.6%, placing it in the 49th percentile of all CVEs. EPSS is maintained by FIRST.org and estimates the probability that a vulnerability will be exploited in the wild within the next 30 days. This score indicates relatively lower exploitation probability, though the CVSS severity should still guide your patching priority.

What type of vulnerability is CVE-2026-32934?

CVE-2026-32934 is classified as CWE-770 (CWE-770). This weakness type describe the underlying flaw category, which helps determine the potential impact and the right class of mitigation.

When was CVE-2026-32934 published, and has it been updated?

CVE-2026-32934 was published on May 5, 2026 and was last updated on August 12, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

🐹 Go

Not in CISA KEV

CVE-2026-32934 — coredns

CVE-2026-32934 is a CWE-770 vulnerability in github.com/coredns/coredns. A fix is available for github.com/coredns/coredns — see the affected versions and patch details below.

CoreDNS DNS-over-QUIC unbounded goroutine growth leads to denial of service

Also known asGHSA-2wpx-qpw2-g5h5GO-2026-4969

Published

May 5, 2026

Updated

Aug 12, 2026

Affected

1 pkg

Patched

1 / 1

Exploits

None indexed

Exploitation data as of Oct 6, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.

Exploitation and automatability from CISA’s SSVC triage for CVE-2026-32934.

EPSS Exploitation Probability

via FIRST.org ↗

0.6%probability of exploitation in next 30 days

Lower Risk0.00%

Lower risk than most CVEs49th percentile — riskier than 49% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

Real-World Exposure

1 pkg affected

🐹github.com/coredns/coredns

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

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. Even with a small configured quic { worker_pool_size ... }, CoreDNS still spawns a goroutine per accepted stream (workers + waiters) and active workers can block indefinitely in io.ReadFull() with no per-stream read deadline, enabling unauthenticated remote DoS via memory exhaustion/OOM-kill.

Details

CoreDNS' DoQ server uses a global worker pool (streamProcessPool) to limit concurrent stream processing, but when the pool is full it still spawns a goroutine per accepted stream that waits to acquire a worker token: select { case s.streamProcessPool <- ...: go ...; default: go ... wait for token ... } (core/dnsserver/server_quic.go)

Additionally, the DoQ message framing reads are blocking io.ReadFull() calls with no per-stream read deadline: readDOQMessage() reads the 2-byte length prefix and message body via io.ReadFull() (core/dnsserver/server_quic.go)

This allows an attacker to pin all workers by sending 1 byte (so io.ReadFull() blocks waiting for the second byte of the DoQ length prefix), while also creating an unbounded backlog of goroutines waiting for a worker token.

Note: this appears to be a result of an incomplete fix/regression for CVE-2025-47950 (GHSA-cvx7-x8pj-x2gw).

PoC

Adjust COREDNS_BIN in the PoC to point at right path (see the top-level const definitions for tunables as well)
Run python3 ./doq-dos-repro.py
Expected sample output: *** Start CoreDNS *** Corefile: /tmp/vh-f003-doq-mem-regression/Corefile Log: /tmp/vh-f003-doq-mem-regression/coredns.log

*** Baseline sample (idle) *** rss_kib=49380 go_goroutines=17

*** Build + run partial-stream flooder *** go: downloading golang.org/x/net v0.43.0 go: downloading golang.org/x/crypto v0.41.0 go: downloading go.uber.org/mock v0.5.2 go: downloading github.com/stretchr/testify v1.11.1 go: downloading golang.org/x/sys v0.35.0 go: downloading github.com/pmezard/go-difflib v1.0.0 go: downloading github.com/davecgh/go-spew v1.1.1 go: downloading gopkg.in/yaml.v3 v3.0.1

*** Candidate sample (during attack) *** rss_kib=137968 go_goroutines=15557

*** Flooder output *** opened conns=60 streams_per_conn=256 total_streams=15360

*** Wrote results *** /tmp/vh-f003-doq-mem-regression/results.json

*** OK *** DoQ flood caused goroutine/RSS growth despite worker_pool_size.

Impact

Unauthenticated remote DoS on an encrypted DNS transport via goroutine/RSS growth leading to OOM-kill/crash and service outage.

Affected Packages

1 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
🐹Go	`github.com/coredns/coredns`	all versions	1.14.3`go get github.com/coredns/coredns@v1.14.3`

Affected Products

1 product · 1 configurations

Application

corednscoredns.io

< 1.14.3

range

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/coredns/coredns, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/coredns/coredns to 1.14.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-32934 is resolved across your whole dependency graph.
Workarounds
Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.

Fixing This On Your OS

If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.

Red HatModerate

Workaround published by Red Hat

Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability.

Source: Red Hat security advisory for CVE-2026-32934 (CC BY 4.0)

Frequently Asked Questions

### 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. Even with a small configured quic { worker_pool_size ... }, CoreDNS still spawns a goroutine per accepted stream (workers + waiters) and active workers can block indefinitely in io.ReadFull() with no per-stream read deadline, enabling unauthenticated remote DoS via memory exhaustion/OOM-kill. ### Details CoreDNS' DoQ server uses a global worker pool (streamProcessPool) to limit concurrent stream processing, b

O3 Security · Impact-Aware SCA

Is CVE-2026-32934 in your dependencies?

Find it across Go, including transitive dependencies.

Scan my dependencies How O3 SCA works