CVE-2026-15709 Overview
CVE-2026-15709 is a denial-of-service vulnerability in the libsoup HTTP client/server library, specifically in its WebSocket implementation when the permessage-deflate extension is negotiated. The decompression loop calling inflate() processes data in chunks without enforcing an upper bound on the output buffer size. A remote, unauthenticated attacker can send a small, highly compressed WebSocket frame that expands to consume all available memory. The result is an Out-of-Memory (OOM) condition and process crash. The flaw is tracked under CWE-409: Improper Handling of Highly Compressed Data (Data Amplification).
Critical Impact
A single small WebSocket payload can exhaust server or client memory, crashing any application built on libsoup and terminating availability.
Affected Products
- libsoup — WebSocket implementation using the permessage-deflate extension
- Applications and services embedding libsoup for WebSocket client or server functionality
- Red Hat Enterprise Linux distributions shipping affected libsoup packages (see Red Hat CVE Report)
Discovery Timeline
- 2026-07-14 - CVE-2026-15709 published to the National Vulnerability Database
- 2026-07-15 - Last updated in NVD database
Technical Details for CVE-2026-15709
Vulnerability Analysis
The vulnerability resides in the WebSocket message reassembly path in libsoup when peers negotiate the permessage-deflate extension defined in RFC 7692. libsoup enforces max_incoming_payload_size on the compressed frame received on the wire. However, it does not track allocations performed during inflation. The inflate() loop grows the output buffer chunk-by-chunk to accommodate whatever the DEFLATE stream produces.
A secondary check exists on the decompressed total, max_total_message_size, but it runs only after decompression finishes. For client connections, this check is disabled by default. Because compression ratios for repetitive data can exceed 1000:1, a few kilobytes of compressed input can force the allocation of gigabytes of memory before any limit is consulted.
Root Cause
The root cause is missing enforcement of an output-size ceiling inside the decompression loop. libsoup validates input size but never compares cumulative inflated bytes against a maximum during each inflate() iteration. The disabled-by-default client-side total-size check compounds the problem for outbound WebSocket connections to attacker-controlled endpoints.
Attack Vector
Exploitation requires only network reachability to a libsoup-based WebSocket peer. An attacker crafts a WebSocket frame containing a DEFLATE-compressed payload of long runs of a single byte (a classic zip bomb pattern). Upon receipt, the target's inflate loop allocates memory indefinitely until the kernel OOM-killer terminates the process or the host swaps to unresponsiveness. No authentication or user interaction is required, and a client that merely connects to a malicious WebSocket server is equally vulnerable.
For technical details refer to the GNOME Issue Tracker Entry and the Red Hat Bugzilla Issue.
Detection Methods for CVE-2026-15709
Indicators of Compromise
- Sudden resident set size (RSS) growth in processes linked against libsoup-2.4 or libsoup-3.0 immediately after a WebSocket upgrade handshake.
- Kernel oom-kill log entries naming applications such as gnome-shell, evolution, epiphany, or custom services using libsoup WebSockets.
- WebSocket handshake responses containing Sec-WebSocket-Extensions: permessage-deflate followed by small compressed frames from untrusted peers.
Detection Strategies
- Inspect WebSocket traffic for permessage-deflate frames whose compressed payload is under 10 KB but whose stream advertises unbounded expansion; flag anomalous compression ratios at the proxy or WAF layer.
- Monitor libsoup-consuming processes for rapid virtual memory growth using cgroup memory accounting or eBPF probes on mmap/brk.
- Correlate application crashes with recent inbound or outbound WebSocket sessions in application logs.
Monitoring Recommendations
- Enable systemd MemoryMax= and MemoryHigh= limits on services using libsoup to convert OOM events into contained restarts and generate alertable signals.
- Ship kernel OOM-killer logs and process memory metrics to a centralized SIEM for correlation with network telemetry.
- Alert on repeated crash-and-restart loops of libsoup-based daemons, which indicate active exploitation attempts.
How to Mitigate CVE-2026-15709
Immediate Actions Required
- Apply the vendor-supplied libsoup update as soon as it is available through your distribution's package manager.
- Inventory all applications linked against libsoup-2.4 and libsoup-3.0 and prioritize patching of network-exposed services first.
- For client applications, avoid connecting to untrusted WebSocket endpoints until the update is deployed.
Patch Information
Refer to the Red Hat CVE Report for distribution package versions and errata. Upstream fixes and status are tracked in the GNOME Issue Tracker Entry. The remediation enforces an output-size limit inside the decompression loop and enables max_total_message_size checks for client connections by default.
Workarounds
- Disable the permessage-deflate extension in applications by not advertising it during the WebSocket handshake, eliminating the vulnerable code path.
- For server deployments, terminate WebSockets at a reverse proxy such as nginx or HAProxy that enforces its own decompression limits before traffic reaches libsoup.
- Constrain per-process memory using systemd unit directives or container memory limits to bound the blast radius of any successful DoS attempt.
# Example systemd hardening for a libsoup-based service
[Service]
MemoryMax=512M
MemoryHigh=384M
Restart=on-failure
RestartSec=5s
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
