REDHAT-BUG-2445127: SSRF

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.