CVE-2026-3632

What it actually does

The flaw is an input-validation weakness in libsoup hostname handling. If an application using libsoup accepts or constructs a hostname from attacker-influenced input, special characters can be inserted so that the generated HTTP request contains attacker-controlled header content. This can create HTTP request smuggling behavior, where an intermediary or receiving server interprets the request differently than the libsoup-based client intended. In specific application designs, the same condition can become server-side request forgery (SSRF), allowing the vulnerable application to make unintended requests to internal or external resources. The assigned severity is low because exploitation requires several conditions, including attacker influence over hostname construction, user interaction, high privileges, and a deployment path where the affected SoupServer/client behavior is security-relevant.

Why it matters to the business

Successful exploitation could allow an attacker to make an affected application send unauthorized network requests or alter how downstream HTTP services interpret traffic. The practical impact is expected to be limited for most organizations because the attack complexity and prerequisites are high, EPSS is very low and stable, there is no known CISA KEV listing, no known ransomware use, and no public exploit maturity is reported. However, libsoup is a common library dependency in Linux and GNOME-related software, including some Red Hat Enterprise Linux packages, so exposure may exist indirectly through applications rather than through a clearly visible internet-facing service.

How an attack unfolds

An attacker first identifies an application or workflow that uses libsoup to make outbound HTTP requests and where a hostname, URL, redirect target, or similar network destination can be influenced. The attacker then supplies a specially crafted hostname containing characters that should have been rejected or normalized. When the application asks libsoup to create the HTTP request, the malformed hostname causes additional header content or request framing data to be embedded in the outbound request. If that request reaches a proxy, gateway, or HTTP server that parses the stream differently, a hidden or altered request can be processed alongside the legitimate one. In an SSRF scenario, the attacker uses this behavior to make the application initiate requests to otherwise inaccessible internal services, metadata endpoints, administrative interfaces, or trusted upstream systems. Exploitation is situational and depends heavily on the surrounding application logic and network topology.

How to fix it

Upgrade libsoup and downstream operating-system packages to vendor-fixed versions as soon as they are available from the relevant distribution or software vendor. Because no fixed versions were provided in the input, track advisories for GNOME libsoup and affected enterprise Linux distributions, then apply the vendor package update through the normal package-management channel. Where immediate patching is not possible, reduce exposure by preventing untrusted input from directly controlling hostnames or URLs, rejecting hostnames containing control characters or encoded newline sequences, disabling unsafe redirects, restricting outbound network access from affected applications, and blocking access to internal-only services from application egress paths. Treat URL parsing, hostname validation, and outbound allowlisting as defense-in-depth controls, not as replacements for updating the vulnerable library.

How to confirm the fix worked

Confirm that affected systems no longer ship or link against a vulnerable libsoup build by checking installed package versions through the operating system package manager and comparing them with the latest vendor advisory. For applications that bundle dependencies, inspect software bills of materials, container images, and build manifests for libsoup versions and rebuild images after updating the base layer. Functionally validate the fix by testing whether hostnames containing raw or encoded carriage-return/line-feed characters are rejected before an HTTP request is emitted. Review outbound proxy and application logs to confirm that requests with malformed Host headers or injected header-like content are not accepted or forwarded. Also verify that egress controls prevent application processes from reaching sensitive internal-only endpoints unless explicitly required.

Typical attack path

1. Find an application or feature that uses libsoup for HTTP requests.
2. Determine whether attacker-controlled input can influence the hostname, URL, redirect destination, or upstream request target.
3. Submit a hostname or URL containing encoded or raw special characters intended to inject HTTP header content.
4. Cause the vulnerable application to generate an outbound HTTP request using the crafted value.
5. Rely on a downstream proxy, gateway, or server to interpret the malformed request in a way that creates request smuggling or SSRF behavior.
6. Use the unintended request path to reach internal services, alter request routing, or access limited internal information.

How to detect it

To determine whether exploitation already occurred, review application logs, outbound proxy logs, web gateway logs, HTTP reverse-proxy logs, EDR network telemetry, and packet captures for evidence of malformed hostnames or injected HTTP headers in requests generated by applications using libsoup. Focus on requests where the Host value contains raw or encoded carriage-return/line-feed sequences, where a single outbound connection appears to contain multiple HTTP requests unexpectedly, or where an application made unusual requests to internal-only services. Investigate outbound requests to metadata services, loopback addresses, RFC1918 private address ranges, link-local addresses, administrative interfaces, and unusual ports that were triggered by user-supplied URL or hostname fields. Because there are no reported threat actors, KEV listing, ransomware use, or mature public exploit reports for this issue, detection should focus on behavioral anomalies rather than campaign-specific indicators. Correlate suspicious requests with application events involving URL submission, redirects, webhook configuration, feed import, image/document fetching, or other remote-resource retrieval features.

• %0d%0a
• %0D%0A
• %0a%0d
• %0A%0D
• \r\nHost:
• \r\nContent-Length:
• \r\nTransfer-Encoding:
• \r\nConnection:
• Host: .*%0d%0a
• Host: .*%0D%0A
• Transfer-Encoding: chunked
• 169.254.169.254
• 127.0.0.1
• localhost
• ::1
• metadata.google.internal
• metadata/iam/security-credentials

What your security team should do

• Inventory systems, containers, and applications that include GNOME libsoup or distribution packages derived from it.
• Prioritize patching internet-adjacent applications, applications that process untrusted URLs, and services that can reach sensitive internal networks.
• Apply vendor updates for libsoup through supported operating-system and application package channels once fixed builds are available.
• Add input validation or allowlisting for any application feature that accepts URLs, hostnames, webhooks, redirects, feed sources, or remote resource locations.
• Restrict outbound application egress to approved destinations and block access to internal metadata, administrative, and control-plane endpoints where not required.
• Review proxy, gateway, and application logs for evidence of CRLF-style hostname/header injection and unexpected internal HTTP requests.
• Monitor vendor advisories because this issue has low current exploitation likelihood but may become more relevant if downstream exploit paths are published.