CVE-2026-15709
Summary
by MITRE • 07/14/2026
A flaw was found in libsoup's WebSocket implementation when using the permessage-deflate extension. The extension's decompression loop (inflate()) processes data in chunks without enforcing an upper boundary limit on the output buffer size. While libsoup limits the incoming compressed frame size via max_incoming_payload_size, it fails to track or limit memory allocation during decompression. A separate check for decompressed size (max_total_message_size) exists but executes only after inflation is complete, and it is entirely disabled by default for client connections. A remote, unauthenticated attacker can exploit this by sending a small, highly compressed payload (a decompression bomb), causing unbounded memory allocation that triggers an Out-of-Memory (OOM) crash and a Denial of Service (DoS).
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 07/14/2026
This vulnerability resides in the libsoup library's WebSocket implementation where the permessage-deflate compression extension fails to properly constrain memory usage during decompression operations. The flaw represents a classic buffer overflow scenario that occurs when the inflate() function processes compressed data chunks without enforcing output buffer size limitations, creating an exploitable condition where maliciously crafted payloads can trigger excessive memory consumption. The vulnerability stems from inadequate input validation and memory management practices within the decompression pipeline, allowing attackers to manipulate the compression algorithm's behavior through carefully constructed payloads.
The technical implementation flaw specifically manifests when libsoup applies permessage-deflate extension processing to incoming WebSocket frames. While the library correctly implements limits on incoming compressed frame sizes through max_incoming_payload_size parameter, it neglects to enforce corresponding constraints during the decompression phase. This creates a scenario where the initial size limitation protects against overly large compressed inputs but fails to prevent the exponential memory growth that occurs when decompressing highly compressed data. The system's design allows for unlimited output buffer expansion during inflate() operations, leading to unbounded memory consumption patterns that can overwhelm system resources.
The operational impact of this vulnerability extends beyond simple resource exhaustion to encompass complete service disruption through denial of service conditions. Attackers can exploit this weakness by transmitting small compressed payloads that decompress into massive amounts of data, effectively creating decompression bombs that consume available memory rapidly. The default configuration disables the max_total_message_size check for client connections, removing any protective mechanism that might otherwise limit total message size after decompression is complete. This default behavior creates a dangerous attack surface where even authenticated users could trigger system instability through carefully crafted WebSocket frames.
Security implications align with CWE-129 and CWE-770 vulnerability classifications, representing both improper input validation and insufficient resource management issues. The flaw also maps to ATT&CK technique T1499.004 for network denial of service attacks and T1566.002 for phishing with malicious attachments, as it enables attackers to exploit WebSocket connections through compressed data manipulation. The vulnerability's remote and unauthenticated nature makes it particularly dangerous as it requires no prior access credentials or privileged information to execute successful attacks against vulnerable systems.
Mitigation strategies should focus on implementing strict decompression limits within the permessage-deflate extension, enforcing maximum output buffer size constraints during inflate() operations, and enabling the max_total_message_size check by default for all connection types. System administrators should also consider implementing rate limiting mechanisms for WebSocket connections and monitoring network traffic patterns for unusual compression ratios that might indicate exploitation attempts. Additionally, upgrading to patched versions of libsoup that address this specific memory management issue represents the most effective long-term solution, while temporary workarounds could involve disabling permessage-deflate extension support entirely where feasible.