Undertow Uncontrolled Resource Consumption VulnerabilityGHSA-w6qf-42m7-vh68
HIGHFix: undertow-io/undertow@7d388c5GHSA-w6qf-42m7-vh68 is a high-severity (CVSS 7.5) Uncontrolled Resource Consumption vulnerability in io.undertow:undertow-core. A fix is available for io.undertow:undertow-core — see the affected versions and patch details below.
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-w6qf-42m7-vh68.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
Where this sits among everything scored
Real-World Exposure
io.undertow:undertow-core☕io.undertow:undertow-coreReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.
Description
A vulnerability was found in Undertow. This vulnerability impacts a server that supports the wildfly-http-client protocol. Whenever a malicious user opens and closes a connection with the HTTP port of the server and then closes the connection immediately, the server will end with both memory and open file limits exhausted at some point, depending on the amount of memory available.
At HTTP upgrade to remoting, the WriteTimeoutStreamSinkConduit leaks connections if RemotingConnection is closed by Remoting ServerConnectionOpenListener. Because the remoting connection originates in Undertow as part of the HTTP upgrade, there is an external layer to the remoting connection. This connection is unaware of the outermost layer when closing the connection during the connection opening procedure. Hence, the Undertow WriteTimeoutStreamSinkConduit is not notified of the closed connection in this scenario. Because WriteTimeoutStreamSinkConduit creates a timeout task, the whole dependency tree leaks via that task, which is added to XNIO WorkerThread. So, the workerThread points to the Undertow conduit, which contains the connections and causes the leak.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | io.undertow:undertow-core | ≥ 2.3.0.Final&&< 2.3.12.Final | 2.3.12.Finalio.undertow:undertow-core:2.3.12.Final |
| ☕Maven | io.undertow:undertow-core | all versions | 2.2.31.Finalio.undertow:undertow-core:2.2.31.Final |
Affected Products
active iq unified managernetapponcommand workflow automationnetappfuseredhatintegration camel for spring bootredhatjboss enterprise application platformredhatopenshift container platformredhatDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for io.undertow:undertow-core, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update io.undertow:undertow-core to 2.3.12.Final or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-w6qf-42m7-vh68 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.
This is rated as Important due to the fact that this might be an unauthenticated remote issue exploited by a malicious user, causing a denial of service (DoS) to the affected server.
No mitigation is currently available for this vulnerability. However, there might be some protections, such as request limits by a load balancer in front of JBoss EAP/Wildfly or even Undertow, that could minimize the impact.Source: Red Hat security advisory for GHSA-w6qf-42m7-vh68 (CC BY 4.0)
| Product | Fixed in | Advisory |
|---|---|---|
| Red Hat build of Apache Camel 4.4.1 for Spring Boot 3.2 | see advisory | RHSA-2024:4884 |
| Red Hat Fuse 7.13.0 | see advisory | RHSA-2024:3354 |
| Red Hat JBoss Enterprise Application Platform 7.1 EUS for RHEL 7 | eap7-activemq-artemis-0:1.5.5.016-1.redhat_00001.1.ep7.el7 | RHSA-2025:4226 |
| Red Hat JBoss Enterprise Application Platform 7.3 EUS for RHEL 7 | eap7-jackson-annotations-0:2.10.4-3.redhat_00006.1.el7eap | RHSA-2025:9583 |
| Red Hat JBoss Enterprise Application Platform 7.4.16 | io.undertow/undertow-core:2.2.30.SP1-redhat-00001 | RHSA-2024:1677 |
| Red Hat JBoss Enterprise Application Platform 7.4 for RHEL 8 | eap7-undertow-0:2.2.30-1.SP1_redhat_00001.1.el8eap | RHSA-2024:1675 |
| Red Hat JBoss Enterprise Application Platform 7.4 for RHEL 9 | eap7-undertow-0:2.2.30-1.SP1_redhat_00001.1.el9eap | RHSA-2024:1676 |
| Red Hat JBoss Enterprise Application Platform 7.4 on RHEL 7 | eap7-undertow-0:2.2.30-1.SP1_redhat_00001.1.el7eap | RHSA-2024:1674 |
Frequently Asked Questions
Is GHSA-w6qf-42m7-vh68 in your dependencies?
Find it across Maven, including transitive dependencies.