CVE-2026-102558: Libsoup: libsoup: heap buffer overflow during websocket receive-buffer growth
A flaw was found in libsoup. When max-incoming-payload-size is unlimited (0), SoupWebsocketConnection could grow its incoming GByteArray based on an attacker-controlled frame length until the length wrapped, causing a heap buffer overflow while reading frame data.
Other sources
A heap buffer overflow was found in libsoup's WebSocket incoming receive buffer handling.
Incoming frames are accumulated in a GByteArray. With max-incoming-payload-size set to 0 (unlimited), a peer could declare a multi-GiB payload and stream it until the buffer length wrapped in gbytearraysetsize() while the read still targeted the original offset, writing past the allocation.
Fixed by rejecting payload lengths above what the receive buffer can represent as soon as the frame header is parsed, before buffering the payload (commit 381a474f, libsoup 3.7.3). Such frames are closed as SOUPWEBSOCKETCLOSETOOBIG.
References: https://gitlab.gnome.org/GNOME/libsoup/-/workitems/554 (Bug 6) https://gitlab.gnome.org/GNOME/libsoup/-/commit/381a474f
— Red Hat
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
libsoupto a version that resolves this vulnerability.Fixed in 3.7.3Patch 381a474f
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Applications using SoupWebsocketConnection are exposed when max-incoming-payload-size is configured as 0, meaning unlimited. The vulnerable path is WebSocket incoming-frame buffering.
What does an attacker need to do to trigger the overflow?
An unauthenticated network peer needs to send a WebSocket frame declaring a multi-GiB payload, then stream data until the receive buffer length wraps. No user interaction is required.
What version contains the fix, and what changes after updating?
The issue is fixed in libsoup 3.7.3 by commit 381a474f. The fix rejects payload lengths that exceed what the receive buffer can represent when the frame header is parsed, and closes those frames with SOUP_WEBSOCKET_CLOSE_TOO_BIG.
What configuration can reduce exposure if updating is not immediately possible?
Avoid configuring max-incoming-payload-size as 0. Setting a finite incoming payload limit prevents the unlimited-buffer condition described for this flaw.