Bug 2547716 (CVE-2026-107227)

Summary: CVE-2026-107227 org.asynchttpclient/async-http-client: AsyncHttpClient: Denial of Service via unbounded WebSocket decompression
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security DevOps Team <prodsec-dev>
Status: NEW --- QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: unspecifiedCC: gmalinko, janstey, pdelbell, rstepani
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in AsyncHttpClient's WebSocket `permessage-deflate` handling. When WebSocket compression is enabled (it is disabled by default), the client does not limit the size of a message after decompression; the configured frame and buffer limits apply to the compressed data. A malicious or compromised WebSocket server, or an attacker able to interfere with a cleartext `ws://` connection, can send a small compressed message that expands substantially and exhausts the client's JVM heap, causing denial of service. The issue is fixed in AsyncHttpClient 3.0.14. The 2.x line is end of life and has no fix.
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-10-07 21:02:48 UTC 
The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. From 2.2.0 until 3.0.14, WebSocket permessage-deflate decompression is unbounded when compression is enabled. The inbound pipeline aggregates compressed frames before WebSocketClientCompressionHandler inflates them, so webSocketMaxFrameSize and webSocketMaxBufferSize do not bound decompressed output. A malicious WebSocket peer can send a small compressed message that expands to a very large Netty buffer and exhausts JVM heap. This issue is fixed in version 3.0.14.