GHSA-px8v-pp82-rcvr is a medium-severity (CVSS 6.5) CWE-345 vulnerability in github.com/quic-go/quic-go. A fix is available for github.com/quic-go/quic-go — see the affected versions and patch details below.
quic-go affected by an ICMP Packet Too Large Injection Attack on Linux
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-px8v-pp82-rcvr.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
GHSA-px8v-pp82-rcvr plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 377,238 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
github.com/quic-go/quic-goReal-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
Impact
An off-path attacker can inject an ICMP Packet Too Large packet. Since affected quic-go versions used IP_PMTUDISC_DO, the kernel would then return a "message too large" error on sendmsg, i.e. when quic-go attempts to send a packet that exceeds the MTU claimed in that ICMP packet.
By setting this value to smaller than 1200 bytes (the minimum MTU for QUIC), the attacker can disrupt a QUIC connection. Crucially, this can be done after completion of the handshake, thereby circumventing any TCP fallback that might be implemented on the application layer (for example, many browsers fall back to HTTP over TCP if they're unable to establish a QUIC connection).
As far as I understand, the kernel tracks the MTU per 4-tuple, so the attacker needs to at least know the client's IP and port tuple to mount an attack (assuming that it knows the server's IP and port).
Patches
The fix is easy: Use IP_PMTUDISC_PROBE instead of IP_PMTUDISC_DO. This socket option only sets the DF bit, but disables the kernel's MTU tracking.
Has the problem been patched? What versions should users upgrade to?
Fixed in https://github.com/quic-go/quic-go/pull/4729 Released in https://github.com/quic-go/quic-go/releases/tag/v0.48.2
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
Use iptables to drop ICMP Unreachable packets.
References
Are there any links users can visit to find out more?
This bug was discovered while doing research for my new IETF draft on IP fragmentation: https://datatracker.ietf.org/doc/draft-seemann-tsvwg-udp-fragmentation/
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/quic-go/quic-go | all versions | 0.48.2go get github.com/quic-go/quic-go@v0.48.2 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/quic-go/quic-go, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/quic-go/quic-go to 0.48.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-px8v-pp82-rcvr is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-px8v-pp82-rcvr can be triaged on real exposure rather than presence alone.
Tailored to GHSA-px8v-pp82-rcvr. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
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.
| Product | Fixed in | Advisory |
|---|---|---|
| Red Hat Advanced Cluster Management for Kubernetes 2.11 for RHEL 9 | rhacm2/volsync-operator-bundle:v0.10.2-3 | RHSA-2025:0386 |
| Red Hat Advanced Cluster Management for Kubernetes 2.11 for RHEL 9 | rhacm2/lighthouse-agent-rhel9:v0.18.5-3 | RHSA-2025:4810 |
| Red Hat Advanced Cluster Management for Kubernetes 2.12 for RHEL 9 | rhacm2/volsync-operator-bundle:v0.11.1-3 | RHSA-2025:0385 |
| Red Hat Advanced Cluster Management for Kubernetes 2.12 for RHEL 9 | rhacm2/lighthouse-agent-rhel9:v0.19.4-1 | RHSA-2025:4250 |
| Red Hat Ansible Automation Platform 2.5 for RHEL 8 | receptor-0:1.5.1-2.el8ap | RHSA-2024:10766 |
Frequently Asked Questions
Is GHSA-px8v-pp82-rcvr in your dependencies?
O3 Security finds GHSA-px8v-pp82-rcvr across Go dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.