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.
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 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 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 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 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 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 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 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 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 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 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 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 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 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 algorithmic complexity flaw exists in libsoup's HTTP Range header processing that persists after the CVE-2025-32907 fix.
A flaw was found in libsoup's SoupServer HTTP Range header processing. The sortranges() comparator function in soup-message-headers.c returns the difference of two goffset (64-bit) values as an int (32-bit). When two range start positions in a multi-range request differ by more than INTMAX (~2.1 billion), the truncation flips the comparison result sign, violating qsort's ordering contract. The mis-sorted ranges are then incorrectly merged, causing the server to silently omit requested byte ranges from the HTTP 206 Partial Content response. A remote unauthenticated attacker can trigger this by sending a multi-range Range request for a resource larger than approximately 2 GB, with range start offsets more than INTMAX apart. The client receives fewer ranges than requested with no error indication, compromising data integrity for resumable downloads, delta updates, mirror synchronization, and chunked verification of large objects.
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. An unsigned integer underflow in the soupfilterinputstreamreaduntil() function causes a heap buffer over-read when parsing multipart HTTP responses. A malicious HTTP server can exploit this by sending a crafted multipart response, potentially causing the client application to crash or disclose sensitive heap memory.
A flaw was found in libsoup. The chunked transfer encoding parser uses a permissive parsing function for chunk sizes that silently accepts inputs violating RFC 9112, including leading whitespace, plus sign prefixes, and trailing invalid characters. When libsoup operates behind a strict frontend proxy, this parsing differential can be exploited to smuggle HTTP requests.
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 means the destination server receives proxy credentials in cleartext (within the TLS session). Per HTTP standards, Proxy-Authorization should only appear on the CONNECT request itself, never on requests forwarded through the established tunnel. The proxy authentication logic in authmsgstarting() in libsoup/auth/soup-auth-manager.c runs unconditionally for all messages without checking whether the current request is being sent through an already-established CONNECT tunnel. This is distinct from CVE-2026-12547 which covers credential leak on proxy switch.
Upstream report: https://gitlab.gnome.org/GNOME/libsoup/-/workitems/534 PSIRTSUPT: https://redhat.atlassian.net/browse/PSIRTSUPT-17666
An unsigned integer underflow in soupfilterinputstreamreaduntil() in libsoup/soup-filter-input-stream.c causes a heap buffer over-read when parsing multipart HTTP responses. When includeboundary is FALSE and the internal buffer contains fewer bytes than the boundary string length, the subtraction of two unsigned values wraps to a very large number, causing the boundary scan loop to read beyond the heap allocation. A malicious HTTP server can trigger this against any libsoup client using SoupMultipartInputStream. This is related to but distinct from CVE-2026-1761 — Red Hat's downstream fix for that CVE does not resolve this issue.
Upstream report: https://gitlab.gnome.org/GNOME/libsoup/-/workitems/532 PSIRTSUPT: https://redhat.atlassian.net/browse/PSIRTSUPT-17666
The chunked transfer encoding parser in libsoup uses strtoul(metabuf, NULL, 16) to parse chunk sizes without strict validation. This function silently accepts inputs that violate RFC 9112 §7.1, including leading whitespace, + prefixes, and trailing invalid characters (e.g., 0z parses as 0). When libsoup operates behind a strict frontend proxy, this parsing differential enables an attacker to smuggle HTTP requests through the backend connection. Both server-side (SoupServer) and client-side chunked response parsing are affected. This is distinct from CVE-2026-1801 which covers bare LF tolerance.
Upstream report: https://gitlab.gnome.org/GNOME/libsoup/-/workitems/533 PSIRTSUPT: https://redhat.atlassian.net/browse/PSIRTSUPT-17666
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.
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.
https://gitlab.gnome.org/GNOME/libsoup/-/workitems/516 https://redhat.atlassian.net/browse/PSIRTSUPT-8846
https://gitlab.gnome.org/GNOME/libsoup/-/workitems/516 https://redhat.atlassian.net/browse/PSIRTSUPT-8846
A heap out-of-bounds read flaw was found in libsoup. When parsing multipart HTTP messages, an integer type mismatch between the caller and soupheadersparse() can cause the length parameter to be incorrectly truncated, leading to a heap buffer over-read. A remote attacker could use this flaw to crash an application using libsoup or potentially disclose heap memory contents.
https://gitlab.gnome.org/GNOME/libsoup/-/workitems/506 https://redhat.atlassian.net/browse/PSIRTSUPT-8846
https://gitlab.gnome.org/GNOME/libsoup/-/workitems/476#note2695744