CVE-2026-3634

What it actually does

The flaw is an improper input validation issue in GNOME libsoup's `soup_message_headers_set_content_type()` function. If an application passes attacker-controlled data into the Content-Type value, CRLF characters can be injected and interpreted as header delimiters. This can allow an attacker to add arbitrary HTTP headers, manipulate downstream HTTP parsing, and in some cases perform HTTP response splitting. Practical impact depends heavily on how the affected application uses libsoup, whether untrusted input reaches the Content-Type setter, and whether intermediaries, browsers, or clients act on the injected headers.

Why it matters to the business

The most likely business risk is application-level trust abuse: maliciously injected headers could alter caching behavior, set or overwrite cookies, redirect users, weaken security controls, or confuse proxies and clients. The CVSS score is low and exploitation requires a specific application data flow, high attacker privileges, and user interaction, so this is generally not an emergency patch for most organizations. However, because libsoup is a common Linux and GNOME HTTP library and is distributed through platforms such as Red Hat Enterprise Linux, the issue may appear indirectly in many applications and appliances, making inventory and routine patch management important.

How an attack unfolds

An attacker first needs access to a feature, integration point, or workflow where they can influence the value an application uses as an HTTP Content-Type. They then supply a crafted value containing a carriage return and line feed sequence followed by attacker-chosen header text. When the vulnerable application calls `soup_message_headers_set_content_type()` with that unsanitized value, libsoup may place the injected CRLF sequence into the generated HTTP message rather than rejecting or neutralizing it. The receiving HTTP client, proxy, cache, or browser may then interpret the injected text as additional headers. Depending on context, the attacker may be able to insert headers such as `Set-Cookie`, `Location`, `Cache-Control`, or security-policy headers, causing session manipulation, cache poisoning, redirect behavior, or response parsing confusion. There is no public exploit maturity indicated and the issue is not listed in CISA KEV, so exploitation is expected to be opportunistic and application-specific rather than broadly automated.

How to fix it

Upgrade libsoup packages to vendor-fixed versions as they become available for the affected operating system or distribution. Because no fixed versions were provided in the input, use the security advisories and package channels for GNOME libsoup and Red Hat Enterprise Linux to identify the exact patched package versions. Where immediate patching is not possible, ensure applications never pass untrusted or partially trusted data directly to `soup_message_headers_set_content_type()`. Validate Content-Type values against a strict allowlist of expected media types such as `application/json`, `text/plain`, or `text/html`; reject or strip carriage return, line feed, percent-encoded CRLF, and other control characters; and avoid reflecting user-supplied Content-Type values into HTTP messages. As a defense-in-depth measure, configure reverse proxies, WAFs, and API gateways to reject requests containing CRLF sequences in header-related parameters or metadata fields.

How to confirm the fix worked

Confirm exposure by identifying installed libsoup packages and applications linked against libsoup on Linux systems, especially GNOME-based workloads and Red Hat Enterprise Linux hosts. Check package manager metadata, vendor advisories, and changelogs for a fix referencing CVE-2026-3634, CRLF sanitization, header injection, or `soup_message_headers_set_content_type()`. For internally developed applications, review code paths where Content-Type is built from request parameters, filenames, metadata, MIME-type hints, upload attributes, administrative input, or upstream service responses. Validate the fix with a controlled test by attempting to pass Content-Type values containing raw CRLF and encoded CRLF sequences and confirming they are rejected, escaped, or normalized and do not create additional HTTP headers on the wire. Packet capture or an intercepting proxy should show exactly one intended Content-Type header and no attacker-supplied header lines.

Typical attack path

1. Identify an application or service using a vulnerable libsoup version to construct HTTP requests or responses.
2. Find a parameter, metadata field, uploaded object property, API input, or administrative setting that is later used to set the Content-Type header.
3. Submit a Content-Type value containing a CRLF sequence followed by an additional HTTP header name and value.
4. Trigger the application path that calls `soup_message_headers_set_content_type()` with the attacker-controlled value.
5. Cause the malformed HTTP message to be sent to a browser, proxy, cache, upstream service, or downstream client.
6. Abuse the injected header behavior to manipulate cookies, caching, redirects, policy enforcement, or client-side interpretation.

How to detect it

To assess whether this was already exploited, review application, reverse proxy, WAF, API gateway, and HTTP access logs for inputs that contain CRLF sequences followed by header-like strings. Focus on parameters or fields related to MIME type, media type, upload content type, file metadata, document type, callback configuration, integrations, or administrative content settings. Search for both raw and encoded CRLF forms, including `%0d%0a`, `%0D%0A`, `%0a`, `%0A`, double-encoded variants such as `%250d%250a`, and escaped forms such as `\r\n`. Investigate events where such sequences are followed by header names including `Set-Cookie`, `Location`, `Cache-Control`, `Content-Length`, `Transfer-Encoding`, `Content-Security-Policy`, `Access-Control-Allow-Origin`, or `Refresh`. On endpoints, review application logs for validation errors, unusual Content-Type values, crashes in HTTP handling, or outbound responses/requests containing unexpected duplicate headers. Network captures, proxy logs, and CDN logs can help confirm whether injected headers were emitted on the wire. If exploitation is suspected, examine browser-facing responses and intermediary caches for unauthorized cookies, unexpected redirects, poisoned cached objects, or altered security headers.

• %0d%0aSet-Cookie:
• %0D%0ASet-Cookie:
• %0d%0aLocation:
• %0D%0ALocation:
• %0d%0aCache-Control:
• %0D%0ACache-Control:
• %0d%0aContent-Length:
• %0D%0AContent-Length:
• %0d%0aTransfer-Encoding:
• %0D%0ATransfer-Encoding:
• %0d%0aContent-Security-Policy:
• %0D%0AContent-Security-Policy:
• %0d%0aAccess-Control-Allow-Origin:
• %0D%0AAccess-Control-Allow-Origin:
• %0d%0aRefresh:
• %0D%0ARefresh:
• %250d%250aSet-Cookie:
• %250D%250ASet-Cookie:
• %250d%250aLocation:
• %250D%250ALocation:
• \r\nSet-Cookie:
• \r\nLocation:
• \r\nCache-Control:
• \r\nContent-Length:
• \r\nTransfer-Encoding:
• soup_message_headers_set_content_type

What your security team should do

• Inventory systems and applications using GNOME libsoup, including indirect dependencies on Red Hat Enterprise Linux and desktop/server components.
• Track vendor advisories and patch libsoup through supported package repositories once fixed builds are available.
• Prioritize remediation for internet-facing applications, applications processing user-uploaded content, API gateways, desktop applications handling untrusted remote content, and services where Content-Type is derived from user-controlled metadata.
• Ask application teams to audit any code that calls `soup_message_headers_set_content_type()` or otherwise constructs Content-Type from untrusted input.
• Add input validation to reject CR, LF, percent-encoded CRLF, and other control characters in MIME type values and related metadata fields.
• Add WAF, reverse proxy, or API gateway rules to flag or block CRLF injection attempts in parameters likely to influence headers.
• Review logs for historical attempts involving encoded or literal CRLF sequences followed by header names such as `Set-Cookie`, `Location`, `Cache-Control`, or `Content-Length`.
• Treat confirmed header injection as a potential session, cache, or redirect manipulation incident and scope affected users, cached responses, and downstream services.