CVE-2025-46421

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 the permessage-deflate WebSocket extension compresses a very large outgoing message, truncated size calculations used for GByteArray growth could wrap, causing zlib to write past the allocated buffer and resulting in a heap buffer overflow.

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.

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 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.