CVE-2026-3633

What it actually does

The flaw is an improper input validation issue in libsoup request construction. If an application allows an attacker to influence the method argument passed to soup_message_new(), the attacker may include carriage-return/line-feed sequences in that value. Because the method is not properly escaped before the HTTP request line is built, those characters can terminate the request line early and inject attacker-controlled HTTP headers or additional request data. The practical impact depends heavily on how the consuming application uses libsoup and whether untrusted input can reach the method parameter; the published CVSS vector reflects high attack complexity, high privileges, and required user interaction.

Why it matters to the business

Organizations using affected libsoup-based software could be exposed to HTTP request injection in applications that pass attacker-controlled method values into libsoup. Successful exploitation may allow manipulation of outbound HTTP traffic, header spoofing, request smuggling-style behavior against upstream services, bypass of expected request handling, or limited exposure or modification of data. The current public risk appears low because this is not in CISA KEV, is not known to be used in ransomware campaigns, has no reported exploit maturity, and has a low EPSS score, but it still matters for products and services that rely on libsoup for security-sensitive HTTP communication.

How an attack unfolds

An attacker first identifies an application or workflow that uses libsoup and lets them influence the HTTP method value used when constructing a request. The attacker then supplies a crafted method containing CRLF characters, such as encoded or raw carriage-return and line-feed sequences, followed by attacker-chosen header lines or additional request content. When the application calls soup_message_new() with this value, libsoup constructs the outbound request line without sufficiently escaping the method. The injected line breaks cause downstream HTTP parsers to interpret part of the method as separate headers or request data. Depending on the receiving service and surrounding application logic, this can result in spoofed headers, altered authentication or routing metadata, cache or proxy confusion, request smuggling-like effects, or unintended backend actions.

How to fix it

Upgrade libsoup through the vendor or operating-system package manager as soon as fixed packages are available for the affected distribution or product. No exact fixed versions were provided in the supplied data, so follow the relevant gnome libsoup and Red Hat Enterprise Linux security advisories for the authoritative patched package versions. Where immediate patching is not possible, reduce exposure by ensuring applications never pass user-controlled values to soup_message_new() as the method parameter, enforce an allowlist of valid HTTP methods such as GET, POST, PUT, PATCH, DELETE, HEAD, and OPTIONS, and reject or sanitize any method value containing control characters, whitespace, percent-encoded CRLF sequences, or non-token characters. Review custom code and downstream applications that dynamically construct HTTP methods rather than using constants or vetted library APIs.

How to confirm the fix worked

Confirm remediation by verifying the installed libsoup package version against the vendor advisory for the affected operating system or application bundle. Use package inventory tooling such as rpm, dpkg, distribution vulnerability scanners, or software composition analysis to identify affected libsoup packages. For source or application validation, review call sites of soup_message_new() and confirm the method parameter is constant or strictly allowlisted. Negative testing should verify that values containing raw or encoded CRLF sequences are rejected before reaching libsoup and cannot produce additional outbound headers or request body content. Network validation can be performed in a controlled test environment by capturing outbound HTTP requests and confirming a crafted method cannot create extra request headers or request lines.

Typical attack path

1. Identify software or an application component using affected versions of gnome libsoup, including deployments shipped through Linux distributions such as Red Hat Enterprise Linux.
2. Find an input path where an attacker can influence the HTTP method passed to soup_message_new().
3. Craft a method value containing CRLF sequences followed by injected HTTP headers or request payload fragments.
4. Trigger the application or user workflow that causes the crafted value to be used in an outbound libsoup request.
5. Rely on the downstream HTTP server, proxy, or intermediary to parse the injected bytes as valid headers or additional request data.
6. Use the altered request semantics to spoof metadata, bypass controls, influence backend behavior, or cause limited confidentiality, integrity, or availability impact.

How to detect it

To determine whether exploitation already occurred, focus on applications that use libsoup and allow dynamic HTTP method selection. Review application logs, outbound proxy logs, HTTP server logs, API gateway logs, and packet captures for malformed or unusual HTTP methods, request lines containing embedded line breaks, unexpected headers appearing only after a user-controlled method field is processed, and discrepancies between application intent and observed outbound requests. Look for encoded CRLF sequences in parameters that map to method names, such as %0d%0a, %0D%0A, \r\n, or double-encoded variants. On receiving services, search for abnormal header injection patterns, duplicated Host or Authorization headers, unexpected X-Forwarded-* headers, and invalid method names immediately before suspicious requests. Because no public exploit kit, threat actor, or stable exploit signature is known from the supplied data, detection should be behavior-based and correlated with affected application call paths rather than relying on a single definitive IOC.

• %0d%0a
• %0D%0A
• %250d%250a
• %250D%250A
• \r\n
• GET%0d%0a
• POST%0d%0a
• HTTP method contains CRLF
• invalid HTTP method
• malformed HTTP request line
• bad request syntax
• unexpected header after request method
• duplicate Host header
• duplicate Authorization header
• X-Forwarded-For:
• X-Original-URL:
• X-Rewrite-URL:

What your security team should do

• Inventory systems and applications that include gnome libsoup, especially Linux desktop, server, and embedded software distributed through Red Hat Enterprise Linux or related downstream packages.
• Track vendor advisories and deploy fixed libsoup packages when available; prioritize internet-facing or security-sensitive applications that make outbound HTTP requests based on user-controlled input.
• Ask application teams to review use of soup_message_new() and remove any path where untrusted input controls the HTTP method.
• Add application-level validation that only permits known-safe HTTP method names and blocks carriage-return, line-feed, whitespace, and encoded control characters.
• Monitor HTTP client, proxy, WAF, and server logs for malformed methods, unexpected headers, duplicated headers, and request parsing anomalies associated with affected applications.
• Treat exploitation likelihood as currently low because EPSS is 0.00223, the 30-day EPSS trend is flat, there is no known exploit maturity, and the issue is not in KEV; nevertheless, remediate through normal vulnerability management because the flaw can cross trust boundaries in specific application designs.