Advisory · CVE-2026-102559
libsoup masked WebSocket frame construction can overflow on large payloads
When building a masked WebSocket client frame for a very large outgoing payload, libsoup passes truncated size values to allocation APIs while the masking routine uses the full length, causing a heap buffer overflow.
- Vendor
- Red Hat
- Product
- libsoup
- Identifier / CWE
- CVE-2026-102559
CWE-125 - Action timing
- Immediate
Explain it like I’m five
When libsoup packs a large outgoing message, it asks for a box that is too small because the size number got cut off, but then it packs the full-size message anyway. The leftover spills over the edges of the box and corrupts nearby memory.
- 01Large outgoing payload
The application constructs a WebSocket client frame for a very large payload.
- 02Truncated allocation
Size values passed to allocation APIs are truncated, producing an undersized buffer.
- 03Full-length masking
The masking routine still operates on the full, untruncated length.
- 04Heap overflow
Data is written past the allocation boundary, causing a heap buffer overflow.
What happened
Red Hat disclosed CVE-2026-102559 in libsoup. When constructing a masked WebSocket client frame for a very large outgoing payload, size values passed to byte-array allocation APIs can be truncated while the masking routine still uses the full length, causing a heap buffer overflow. It affects RHEL 6 through 10 libsoup/libsoup3 packages and carries a CVSS 3.1 score of 8.6 (high).
What to do
- Apply updated libsoup packages from your vendor as they are released.
- Prioritize clients that build WebSocket frames from large or attacker-influenced payloads.
- Review crash telemetry on hosts running services that recently transferred very large WebSocket messages.
- Note that this flaw sits beside CVE-2026-102558, a related libsoup WebSocket overflow: patch once, covering both.
Management note
This is the outgoing counterpart to CVE-2026-102558’s incoming overflow, in the same library. Applications that both send and receive WebSocket traffic on libsoup are exposed on both directions, so a single library update should be treated as the fix for the pair.