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 the cookie parsing logic of the libsoup HTTP library, used in GNOME applications and other software. The vulnerability arises when processing the expiration date of cookies, where a specially crafted value can trigger an integer overflow. This may result in undefined behavior, allowing an attacker to bypass cookie expiration logic, causing persistent or unintended cookie behavior. The issue stems from improper validation of large integer inputs during date arithmetic operations within the cookie parsing routines.

A flaw in libsoup’s HTTP header handling allows multiple Host: headers in a request and returns the last occurrence for server-side processing. Common front proxies often honor the first Host: header, so this mismatch can cause vhost confusion where a proxy routes a request to one backend but the backend interprets it as destined for another host. This discrepancy enables request-smuggling style attacks, cache poisoning, or bypassing host-based access controls when an attacker supplies duplicate Host headers.

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

Use-After-Free vulnerability in the HTTP/2 server implementation of the libsoup HTTP library. The issue occurs in the onframerecvcallback() function when processing HTTP/2 frames. During header handling, the function increments an internal callback counter and emits signals such as soupservermessagegotheaders(). If a user-defined signal handler disconnects the client connection during this callback (for example due to authentication failure), the associated SoupServerMessageIOHTTP2 object may be destroyed and freed while still referenced by the callback. When execution returns to the callback, it continues to access the freed io object and attempts to update internal state, resulting in a heap use-after-free condition. An attacker can trigger this issue by sending HTTP/2 requests that cause authentication validation failures, potentially leading to application instability or crashes.

DESCRIPTION

Here, I had found another flaw in Libsoup's server-side digest authentication implementation. The SoupAuthDomainDigest class fails to track issued nonces or enforce the incrementing nonce-count (nc) attribute required by the Digest Auth standard. The validation logic in checkhexurp performs a purely mathematical verification. It recomputes the expected hash without verifying if the nonce was actually generated by the server or if the nc value is being reused. This allows an attacker who captures a single valid Authorization header to replay it indefinitely, bypassing authentication and accessing protected resources as the victim.

VULNERABILITY DETAILS

The vulnerability exists in libsoup/server/soup-auth-domain-digest.c due to a "stateless" design choice that violates security standard. -Stateless Validation: The function checkhexurp validates the response hash but fails to check against a store of active, issued nonces. -Missing Nonce-Count Check (The Main Flaw): RFC 7616 explicitly states that the server MUST verify that the nc (nonce-count) value increases for each request using the same nonce. In soup-auth-domain-digest.c (around lines 265-), the code parses the nonce count:

noncecount = strtoul (nc, NULL, 16); if (noncecount <= 0) return FALSE;

Here, it do checks that noncecount is positive, but it never compares it to a previously seen value for that nonce. It simply accepts any positive integer, allowing attackers to reuse nc=00000001 infinitely. -Insecure Nonce Generation: Nonces are generated using time(0) and the message pointer address. They are not cryptographically signed (HMAC) and are never expired by the server, creating an infinite window for replay attacks.

A flaw was found in libsoup’s WebSocket frame processing when handling incoming messages. If a non-default configuration is used where the maximum incoming payload size is unset, the library may read memory outside the intended bounds. This can cause unintended memory exposure or a crash. Applications using libsoup’s WebSocket support with this configuration may be impacted.

A flaw was found in libsoup, an HTTP client library. This vulnerability, known as CRLF (Carriage Return Line Feed) Injection, occurs when an HTTP proxy is configured and the library improperly handles URL-decoded input used to create the Host header. A remote attacker can exploit this by providing a specially crafted URL containing CRLF sequences, allowing them to inject additional HTTP headers or complete HTTP request bodies. This can lead to unintended or unauthorized HTTP requests being forwarded by the proxy, potentially impacting downstream services.

A flaw was found in the libsoup HTTP library that can cause proxy authentication credentials to be sent to unintended destinations. When handling HTTP redirects, libsoup removes the Authorization header but does not remove the Proxy-Authorization header if the request is redirected to a different host. As a result, sensitive proxy credentials may be leaked to third-party servers. Applications using libsoup for HTTP communication may unintentionally expose proxy authentication data.

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.

When libsoup is used as a client to send a request (a message), soupmessagesetrequesthostfromuri() is eventually invoked by soupsessionsendqueueitem(). This function takes the host component from a GUri using gurigethost(), and inserts this literally as a Host header value. Because of Teams/Releng/security#193, this string may contain any character, even ones that are normally not part of a hostname, including \r and \n. Because of this, it is possible to insert CRLF tokens into the Host header value, effectively allowing the insertion of arbitrary headers, and even full requests. For example, take the following gio cat operation:

gio cat "http://a%0d%0a%0d%0aPOST%20%2ffoo%20HTTP%2f1.1%0d%0aHost%3a%20localhost%0d%0aA%3a%20.localhost:8080/a"

This results in the following data being sent to the HTTP server:

GET /a HTTP/1.1 Accept-Encoding: gzip, deflate User-Agent: gvfs/1.54.4 Accept-Language: en-us, en;q=0.9, en;q=0.8 Connection: Keep-Alive Host: [a

POST /foo HTTP/1.1 Host: localhost A: .localhost]:8080

Many HTTP servers will interpret this as two HTTP requests and process both, enabling an HTTP smuggling attack. We tested this to work with nginx for example:

172.17.0.1 - - [02/Dec/2025:14:55:38 +0000] "GET /a HTTP/1.1" 200 12128 "-" "gvfs/1.54.4" "-" 172.17.0.1 - - [02/Dec/2025:14:55:38 +0000] "POST /foo HTTP/1.1" 405 168 "-" "-" "-"

Such an attack only appears works on hosts which do not require DNS to be used to resolve the subdomain. Even a wildcard subdomain will not allow an attacker to perform this attack on arbitrary hosts, as the DNS resolving process will fail due to the invalid characters.

Impact This vulnerability causes a write-like operation (an HTTP POST request) to be performed in a context where this is not expected (a file read operation via GVfs). Hence, this can cause behavior which was not accounted for, with a security impact when the URL is attacker controlled. An example scenario is LibreOffice, which uses GIO and GVFs to read remote image paths which may be present in a document. So, opening LibreOffice on a malicious file could trigger this POST request. In situations where LibreOffice is executed on a headless server (e.g., via libreoffice-convert or similar software) to convert documents to PDF, the result is a Server-Side Request Forgery (SSRF) vulnerability with a fully controllable POST request. This can have a relatively high impact in certain web-applications.

Recommended solution Ensure that hostname components cannot contain invalid characters in the first place. Additionally, it may be beneficial to perform extra validation in libsoup on header values, whenever they are set.

An out-of-bounds read vulnerability exists in the processframe() function of libsoup’s SoupWebSocketConnection. When maxincomingpayloadsize is explicitly set to 0, improper bounds handling allows the function to read beyond the allocated buffer while processing WebSocket frames. This condition can lead to memory disclosure or application instability. Exploitation requires a non-default configuration and a remote attacker capable of sending crafted WebSocket frames.