A flaw was found 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.

A flaw was found 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.

A flaw was found 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. 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. The soupuridecodedatauri() function incorrectly treated base64 data-URI payloads as NUL-terminated strings when calling gbase64decodeinplace(). 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.

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.

A type-confusion heap overflow was found in libsoup's WebSocket Pong handling.

SoupWebsocketConnection::pong is declared to deliver a GBytes payload, but receivepong() emitted a GByteArray pointer via gsignalemit() and then unreffed the GByteArray. Handlers that treated the argument as GBytes (as documented) operated on the wrong object layout, resulting in heap memory corruption / overflow conditions under ASan.

Fixed upstream by converting the buffer with gbytearrayfreetobytes() before emission (commit d2cbaf25, libsoup 3.7.3).

References: https://gitlab.gnome.org/GNOME/libsoup/-/workitems/554 (Bug 2) https://gitlab.gnome.org/GNOME/libsoup/-/commit/d2cbaf25

A heap buffer overflow was found in libsoup's client-side WebSocket frame construction / masking path.

Outgoing frames are built in a GByteArray. For a send payload larger than the array can represent (at/above ~2^31), gbytearraysizednew() / append truncated the length while xorwithmask() still iterated the full attacker-/caller-controlled length, writing past the small allocation during masking.

Fixed by rejecting outgoing payloads above MAXOUTGOINGPAYLOADSIZE both before and after extensions process the payload (commit d7f074f8, libsoup 3.7.3).

References: https://gitlab.gnome.org/GNOME/libsoup/-/workitems/554 (Bug 7) https://gitlab.gnome.org/GNOME/libsoup/-/commit/d7f074f8

A heap buffer overflow was found in libsoup's WebSocket permessage-deflate outgoing path.

soupwebsocketextensiondeflateprocessoutgoingmessage() stored deflateBound()'s uLong result in a guint and grew a GByteArray by that amount. For payloads approaching 4 GiB, the bound exceeds GMAXUINT; truncation allowed buffer->len + maxlength to wrap on later growth, and zlib wrote through nextout past the allocation.

Fixed by refusing payloads whose compressed bound cannot fit in a GByteArray and by checking each incremental growth (commit dbd0417e, libsoup 3.7.3).

References: https://gitlab.gnome.org/GNOME/libsoup/-/workitems/554 (Bug 8) https://gitlab.gnome.org/GNOME/libsoup/-/commit/dbd0417e

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

A heap buffer overflow condition was found in libsoup's soupuridecodedatauri().

After percent-decoding a data URI payload marked ;base64, the code called gbase64decodeinplace(), which measures input with strlen(). Percent-decoded content can contain embedded NUL bytes (for example data:;base64,A%00B), so the measured length was too short. gbase64decodeinplace() returned without writing a valid output length; the uninitialized length was then stored as the size of the returned GBytes, allowing callers to read past the allocation.

Fixed upstream by decoding with gbase64decodestep() using the real buffer length (commit e4f03226, libsoup 3.7.3).

References: https://gitlab.gnome.org/GNOME/libsoup/-/workitems/554 (Bug 1) https://gitlab.gnome.org/GNOME/libsoup/-/commit/e4f03226

A heap buffer overflow was found in libsoup WebSocket fragmented-message reassembly.

Reassembled messages are stored in a GByteArray (length typed as guint). A sequence of fragments (or extension expansion) that grew the message past GMAXINT caused gbytearraysetsize() / related growth APIs to truncate the size while surrounding code continued to use the full length, corrupting the heap. Upstream notes interaction with older GLib (e.g. 2.70) growth behavior.

Fixed by rejecting reassembly that would exceed what a GByteArray can safely hold, independently of max-total-message-size (commit d7f074f8, libsoup 3.7.3).

References: https://gitlab.gnome.org/GNOME/libsoup/-/workitems/554 (Bug 5) https://gitlab.gnome.org/GNOME/libsoup/-/commit/d7f074f8

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. A remote, unauthenticated attacker can place a complete HTTP request in the body and cause SoupServer to process that smuggled request, leading to unintended request handling.

A flaw was found in libsoup, a library for handling HTTP requests. This vulnerability, known as a Use-After-Free, occurs in the HTTP/2 server implementation. A remote attacker can exploit this by sending specially crafted HTTP/2 requests that cause authentication failures. This can lead to the application attempting to access memory that has already been freed, potentially causing application instability or crashes, resulting in a Denial of Service (DoS).

A flaw was found in libsoup. When establishing HTTPS tunnels through a configured HTTP proxy, sensitive session cookies are transmitted in cleartext within the initial HTTP CONNECT request. A network-positioned attacker or a malicious HTTP proxy can intercept these cookies, leading to potential session hijacking or user impersonation.

Cleartext Transmission of Sensitive Information has been reported in libsoup’s HTTP CONNECT handling. When establishing HTTPS tunnels via soupsession.c::tunnelconnect(), cookies (including potentially sensitive session cookies) are sent in cleartext within the initial HTTP CONNECT request to the configured proxy. A network-positioned attacker or malicious HTTP proxy can intercept or observe these cookies and leverage them for session hijacking or user impersonation.

HTTP/1 request-smuggling desync in SoupServer: when a client sends Expect: 100-continue with a Content-Length body and SoupServer emits an early final (non-1xx) response before reading the body (e.g. 401 from SoupAuthDomain, or any handler that sets a final status at the headers stage), libsoup marks the read side DONE without draining the declared body bytes and without sending Connection: close. On a keep-alive connection those leftover body bytes are then parsed as the next HTTP request, so a complete second request placed in the body is smuggled and executed (CWE-444 / RFC 9112 framing violation).

Verified upstream on libsoup 3.7.1 / current HEAD: one crafted connection to an auth-protected path yields 401 then 200, and the smuggled handler runs. Defect location: libsoup/server/http1/soup-server-message-io-http1.c iowrite() STATEHEADERS Expect: 100-continue path (readstate -> DONE without drain/close).

Distinct from CVE-2026-1760 (chunked + keep-alive close) and CVE-2026-1801 (malformed chunk headers). Upstream: https://gitlab.gnome.org/GNOME/libsoup/-/workitems/539. Reporter: Jianqiang (Stark) Li. Embargo: No. Patch discussed upstream; fixed release not yet shipped.

A flaw was found in libsoup. When handling cookies, libsoup clients mistakenly allow cookies to be set for public suffix domains if the domain contains at least two components and includes an uppercase character. This bypasses public suffix protections and could allow a malicious website to set cookies for domains it does not own, potentially leading to integrity issues such as session fixation.

A flaw was found in Libsoup. The server-side digest authentication implementation in the SoupAuthDomainDigest class does not properly track issued nonces or enforce the required incrementing nonce-count (nc) attribute. This vulnerability allows a remote attacker to capture a single valid authentication header and replay it repeatedly. Consequently, the attacker can bypass authentication and gain unauthorized access to protected resources, impersonating the legitimate user.

A flaw was found in libsoup. A remote attacker, by controlling the method parameter of the soupmessagenew() function, could inject arbitrary headers and additional request data. This vulnerability, known as CRLF (Carriage Return Line Feed) injection, occurs because the method value is not properly escaped during request line construction, potentially leading to HTTP request injection.

A flaw was found in libsoup, a library used by applications to send network requests. This vulnerability occurs because libsoup does not properly validate hostnames, allowing special characters to be injected into HTTP headers. A remote attacker could exploit this to perform HTTP smuggling, where they can send hidden, malicious requests alongside legitimate ones. In certain situations, this could lead to Server-Side Request Forgery (SSRF), enabling an attacker to force the server to make unauthorized requests to other internal or external systems. The impact is low, as SoupServer is not actually used in internet infrastructure.

A flaw was found in libsoup. An attacker controlling the value used to set the Content-Type header can inject a Carriage Return Line Feed (CRLF) sequence due to improper input sanitization in the soupmessageheaderssetcontenttype() function. This vulnerability allows for the injection of arbitrary header-value pairs, potentially leading to HTTP header injection and response splitting attacks.

Vulnerability Reference:

A flaw in libsoup's WebSocket implementation allows a remote attacker to trigger a denial of service (DoS) by exploiting a protocol validation failure.

Component / Vulnerable Part:

libsoup -> libsoup/websocket/soup-websocket-connection.c (Control frame parser)

Technical Analysis & Root Cause:

Per RFC 6455 §5.5, WebSocket control frames (PING, PONG, CLOSE) must not exceed a payload length of 125 bytes and cannot be fragmented. libsoup's frame parsing logic fails to immediately reject non-compliant control frames exceeding this limit. When an oversized control frame is received, the unexpected state disrupts the state machine or triggers an unhandled execution error, forcing the library to abruptly crash.

Impact:

A remote, unauthenticated attacker (client or server) can send a single malformed, oversized control frame to instantly terminate the connection wrapper, resulting in a remote denial of service for any application using libsoup WebSockets.

A flaw was found in libsoup. After a CONNECT tunnel is established through an HTTP proxy, libsoup incorrectly attaches the Proxy-Authorization header to subsequent HTTPS requests sent through that tunnel to the destination server. This allows the destination server to capture proxy credentials, leading to information disclosure.

A flaw was found in libsoup’s caching mechanism, SoupCache, where the HTTP Vary header is ignored when evaluating cached responses. This header ensures that responses vary appropriately based on request headers such as language or authentication. Without this check, cached content can be incorrectly reused across different requests, potentially exposing sensitive user information. While the issue is unlikely to affect everyday desktop use, it could result in confidentiality breaches in proxy or multi-user environments.

A flaw was found in libsoup. The HTTP/2 client request-body path for non-pollable GInputStream sources buffers an asynchronous read sized to the current flow-control window, then later copies that entire buffer into nghttp2's DATA callback buffer without clamping to the callback length. A malicious HTTP/2 server can send a SETTINGS frame that reduces SETTINGSINITIALWINDOWSIZE while that read is in flight, making the next DATA callback length smaller than the already-buffered byte count. The only check is a gassert(), which aborts the client in typical builds. If assertions are compiled out, nghttp2 rejects a return value larger than the allowed length and fails the session.

An out-of-bounds read vulnerability was found in libsoup's multipart processing subsystem. The flaw exists in the soupmultipartinputstreamreadheaders() function inside soup-multipart-input-stream.c, which does not adequately restrict or validate the size of incoming multipart boundary strings. When processing a crafted HTTP response containing a malformed or oversized boundary parameter, the internal stream reader reads past the allocated buffer bounds. A remote, unauthenticated attacker can exploit this behavior to cause a service denial (DoS) through application failure or potentially read fragments of unauthorized memory metadata.

https://gitlab.gnome.org/GNOME/libsoup/-/workitems/476#note2695744

A flaw was found in libsoup, where soupauthdigestauthenticate() is vulnerable to a NULL pointer dereference. This issue may cause the libsoup client to crash.

A flaw was found in libsoup. SoupContentSniffer may be vulnerable to a NULL pointer dereference in the sniffmp4 function. The HTTP server may cause the libsoup client to crash.