REDHAT-BUG-2455350: High severity Undertow io.undertow:undertow-core vulnerability
Summary: Undertow’s PerMessageDeflateFunction.largerBuffer() uses exponential doubling
Requirements To Exploit: Any application using Undertow’s WebSocket with permessage-deflate is
affected. This includes:
WildFly application server (uses Undertow as its web layer)
Red Hat JBoss Enterprise Application Platform (JBoss EAP)
Any standalone Undertow WebSocket application using
PerMessageDeflateHandshake
The vulnerability requires only a standard WebSocket connection with
permessage-deflate negotiated, no authentication, no special configuration.
Component Affected: io.undertow:undertow-core
Version Affected: Undertow 2.3.18.Final
Patch Available: no
Version Fixed: N/A
Cvss: Score: 7.5 HIGH Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Impact: IMPORTANT
Steps To Reproduce: I have attached a self-contained Maven project (undertow-websocket-poc.tar.gz)
containing 6 tests:
Baselines:
Baseline 1a: Valid Origin -> upgrade accepted, message delivered
Baseline 1b: Invalid Origin -> HTTP 403 rejected
Mitigation: Add a maxDecompressedBufferSize parameter to PerMessageDeflateHandshake
(e.g. default 10 MB) that limits the largerBuffer() growth
Add a maximum doubling count or absolute buffer cap in largerBuffer()
Add a maxDecompressionRatio check (reject if wire:decompressed > 100x)
Add a maxFragmentsPerMessage limit in WebSocketChannel
Add Ping rate limiting in WebSocketChannel before generating Pong
Expose these limits in the PerMessageDeflateHandshake constructor
Affected Software
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Any application using Undertow WebSockets with permessage-deflate is affected. This includes WildFly, Red Hat JBoss Enterprise Application Platform, and standalone Undertow WebSocket applications that use PerMessageDeflateHandshake.
What does an attacker need to exploit it?
An attacker needs only to establish a standard WebSocket connection and negotiate permessage-deflate. No authentication or special configuration is required.
Is a vendor patch available?
No patch is available, and no fixed version is listed.
What mitigation is identified if patching is not possible?
Limit decompressed buffer growth by adding a maxDecompressedBufferSize parameter to PerMessageDeflateHandshake, with 10 MB given as an example default. A maximum buffer-doubling count or absolute buffer limit is also identified as a mitigation.