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