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.

CVE-2025-32907 addressed memory amplification when a client repeated the same range many times in a single Range header. Commit 9bb92f7a corrected merge correctness in soupmessageheadersgetrangesinternal() in libsoup/soup-message-headers.c, but the coalescing loop still removes merged ranges using garrayremoveindex() for each coalesced element. Because GArray is contiguous, each mid-array removal performs an O(N) memmove. When many identical satisfiable ranges are supplied (for example bytes=0-0 repeated thousands of times), the loop performs O(N²) work coalescing them into a single range.

The vulnerable path is reachable server-side from handlepartialget() in libsoup/server/http1/soup-server-message-io-http1.c when a SoupServer handler returns HTTP 200 with a non-empty body. No authentication is required. The number of ranges is bounded only by the maximum request header size (~100 KiB), allowing roughly 25,000 ranges per request. Reporter measurements on libsoup HEAD containing the CVE-2025-32907 fix show ~90 ms single-core CPU per such request at the wire maximum, blocking the server's event loop for that duration.

This is a CPU exhaustion / availability issue only. No memory corruption or information disclosure occurs.

Affected: libsoup versions containing the CVE-2025-32907 fix but not merge request !550. Fixed upstream: MR !550 merged 2026-08-20, replacing per-element removal with O(N) in-place compaction and rejecting Range headers requesting more than 200 ranges. Upstream report: https://gitlab.gnome.org/GNOME/libsoup/-/issues/538 Related: CVE-2025-32907

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 https://redhat.atlassian.net/browse/PSIRTSUPT-8846

A flaw was found in libsoup. A remote attacker could exploit an unsigned to signed conversion error in the soupbodyinputstreamreadchunked() function by sending a malicious HTTP request. This vulnerability occurs when libsoup operates behind a non-libsoup proxy server or as a proxy in front of a non-libsoup backend server. Successful exploitation can allow an attacker to bypass security controls, poison web caches, or gain unauthorized access.

HTTP Request Smuggling on libsoup through libsoup/http1/soup-body-input-stream.c:soupbodyinputstreamreadchunked() via Unsigned to Signed Conversion Error in chunk size

Requirements to exploit: spend malicious HTTP request to libsoup backend server operating behind non-libsoup proxy server, or to libsoup proxy server operating in front of non-libsoup backend server

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.

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

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's SoupServer. A remote attacker could exploit a use-after-free vulnerability where the soupserverdisconnect() function frees connection objects prematurely, even if a TLS handshake is still pending. If the handshake completes after the connection object has been freed, a dangling pointer is accessed, leading to a server crash and a Denial of Service.

SoupServer is vulnerable to use after free vulnerability because soupserverdisconnect() frees all SoupServerConnection objects, even if there is a pending GNUTLS handshake to be finished.

A TLS handshake is initiated asynchronously. After creating the SoupServerConnection, libsoup calls gtlsconnectionhandshakeasync(), which registers tlsconnectionhandshakereadycb as a callback. The handshake runs in the background andthe callback fires later when it completes. When the TLS handshake completes successfully, GNUTLS invokes tlsconnectionhandshakereadycb() asynchronously

soupserverdisconnect() is called ( due to some scenario, like a server restart, or other cases). This iterates through all active connections and disconnects them. When the last reference to a SoupServerConnection is dropped, soupserverconnectionfinalize() is called, freeing the object. If the TLS handshake completes after soupserverdisconnect() has freed the connection object, tlsconnectionhandshakereadycb() still fires with a dangling pointer. The callback then calls soupserverconnectionconnected(conn), which attempts to access the freed SoupServerConnection via soupserverconnectiongetiostream(), causing a crash

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 request smuggling vulnerability exists in libsoup's HTTP/1 header parsing logic. The soupmessageheadersappendcommon() function in libsoup/soup-message-headers.c unconditionally appends each header value without validating for duplicate or conflicting Content-Length fields. This allows an attacker to send HTTP requests containing multiple Content-Length headers with differing values.

A flaw was identified in libsoup, a widely used HTTP library in GNOME-based systems. When processing specially crafted HTTP Range headers, the library may improperly validate requested byte ranges. In certain build configurations, this could allow a remote attacker to access portions of server memory beyond the intended response. Exploitation requires a vulnerable configuration and access to a server using the embedded SoupServer component.

A flaw was found in libsoup. An integer underflow vulnerability occurs when processing content with a zero-length resource, leading to a buffer overread. This can allow an attacker to potentially access sensitive information or cause an application level denial of service.