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