CVE-2026-102560

In libsoup, when handling an incoming WebSocket Pong frame, SoupWebsocketConnection emitted the ::pong signal with a GByteArray pointer even though the signal is declared to pass a GBytes. Applications connecting a handler that follows the documented GBytes API can trigger heap corruption or a crash upon receiving a crafted Pong.

A use-after-free vulnerability was found in the libsoup library, in the soup_message_headers_get_content_disposition() function. This flaw allows a malicious HTTP client to cause memory corruption in the libsoup server.

A flaw was found in SoupServer (libsoup). When an HTTP/1.x client sends a request with Expect: 100-continue and a request body, and SoupServer returns an early final (non-1xx) response before the body is read, the server neither drains the declared body bytes nor closes the connection. On a keep-alive connection, those leftover bytes are interpreted as a subsequent HTTP request.

In libsoup, when constructing a masked WebSocket client frame for a very large outgoing payload, size values passed to GByteArray allocation APIs could be truncated while the masking routine still used the full length, causing a heap buffer overflow.

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.

In libsoup, the soup_uri_decode_data_uri() function incorrectly treated base64 data-URI payloads as NUL-terminated strings when calling g_base64_decode_inplace(). If the percent-decoded payload contained embedded NUL bytes, the decoded length could remain uninitialized and be used as the size of the returned GBytes. This can lead to an out-of-bounds read or application crash when processing a crafted data URI.

In libsoup, when reassembling fragmented WebSocket messages into a GByteArray, libsoup did not adequately cap total message size against the limits of the underlying buffer type. A remote peer could send fragments that caused size truncation while the implementation still used the full length, leading to heap corruption or a crash.

A flaw was found in libsoup where sending an HTTP/2 request body from a non-pollable input stream can lead to buffering more data than the flow-control window allows. A malicious server can shrink SETTINGS_INITIAL_WINDOW_SIZE while the buffered read is in progress, causing the client to copy the full buffer into a smaller DATA callback without bounds check, potentially aborting the process or failing the HTTP/2 session.

A use-after-free vulnerability was found in libsoup's HTTP/2 client implementation. A malicious HTTP/2 server or MITM attacker can exploit it when a GNOME application uploads a file over HTTP/2 and the server sends a GOAWAY frame while the file body is being read asynchronously. This can lead to memory corruption, information disclosure, or arbitrary code execution.

An algorithmic complexity flaw exists in libsoup's HTTP Range header processing that persists after the CVE-2025-32907 fix. The coalescing loop uses O(N²) operations when many identical ranges are supplied, allowing CPU exhaustion. The issue is reachable server-side without authentication and can block the event loop for ~90 ms per request at the wire maximum.