CVE-2026-32762

What it actually does

CVE-2026-32762 is an improper input validation flaw in Rack's parsing of the RFC 7239 Forwarded HTTP header. Affected Rack versions split Forwarded header values on semicolons before correctly accounting for quoted strings, even though semicolons are valid inside quoted values. As a result, a crafted header can cause Rack to interpret attacker-controlled text inside a quoted value as additional Forwarded parameters such as host, proto, for, or by. The impact depends heavily on how the application and its upstream proxy, CDN, WAF, or load balancer use Forwarded headers. In vulnerable deployments, this can lead to incorrect client IP attribution, scheme confusion, host confusion, logging inaccuracies, incorrect URL generation, or bypass of application logic that trusts proxy-normalized forwarding metadata.

Why it matters to the business

The most likely business impact is misrouting of trust decisions that depend on forwarded request metadata, such as identifying the original client IP, determining whether a request is HTTPS, or building absolute URLs. This may cause security controls, audit trails, rate limits, access rules, redirects, or application behavior to rely on attacker-influenced values. The CVSS score is moderate, EPSS is very low and stable at 0.0018 over 30 days, there is no known CISA KEV listing, no ransomware association, and no reported exploit maturity, so this should generally be treated as a controlled patching issue rather than an emergency response event. However, Rack is a common Ruby web interface used by many Ruby web applications and frameworks, so exposure may be widespread across application stacks even when Rack is not directly managed by application owners.

How an attack unfolds

An attacker sends an HTTP request containing a deliberately crafted RFC 7239 Forwarded header with a semicolon embedded inside a quoted-string value. An upstream proxy, WAF, CDN, or load balancer may consider the quoted value valid and either preserve it or validate it as a single parameter. The vulnerable Rack parser later splits the header on semicolons too early and treats portions of the quoted value as separate Forwarded directives. If the Ruby application or middleware trusts Rack's parsed forwarded values, the attacker may influence perceived client IP, original protocol, host, or proxy chain metadata. The practical outcome depends on application logic: possible effects include spoofed logging, incorrect secure/insecure request handling, host-based logic manipulation, bad redirect or URL generation, or bypass of controls that depend on trusted forwarded metadata. Successful exploitation generally requires a deployment-specific mismatch between upstream intermediary handling and Rack's parser behavior, which is why attack complexity is high.

How to fix it

Upgrade Rack to a patched version. Versions before 3.1.21 in the 3.1.x line should be upgraded to Rack 3.1.21 or later. Versions 3.2.0 through before 3.2.6 should be upgraded to Rack 3.2.6 or later. If using dependency managers, update the locked Rack dependency and rebuild/redeploy affected Ruby applications. If immediate upgrade is not possible, reduce risk by normalizing or rejecting ambiguous Forwarded headers at the edge, especially headers containing quoted values with semicolons; prefer a single trusted forwarding header strategy; ensure applications only trust forwarding metadata from known proxies; and avoid making authorization, host validation, or security-sensitive decisions directly from untrusted Forwarded header contents. Confirm that upstream proxies overwrite rather than append or preserve untrusted client-supplied Forwarded headers where appropriate.

How to confirm the fix worked

Confirm the deployed Rack version is 3.1.21 or later for the 3.1 branch, or 3.2.6 or later for the 3.2 branch. Review dependency lockfiles and runtime package inventories, not only top-level application manifests, because Rack is often a transitive dependency. Send benign validation requests containing RFC 7239 Forwarded headers with semicolons inside quoted values and verify that the application does not interpret embedded text as separate host, proto, for, or by parameters. Check edge proxy and application behavior together to ensure they parse or normalize Forwarded consistently. Validate that logs, request metadata, generated URLs, redirect behavior, and any access-control decisions remain unchanged when ambiguous Forwarded headers are supplied.

Typical attack path

1. Identify a Ruby web application or service using an affected Rack version from 3.0.0.beta1 through versions before 3.1.21, or 3.2.0 through versions before 3.2.6.
2. Determine whether the application or middleware consumes RFC 7239 Forwarded header values for client IP, scheme, host, proxy chain, redirects, logging, or authorization decisions.
3. Send test requests containing Forwarded headers with quoted-string values that include semicolons and embedded parameter-looking text.
4. Observe behavioral differences between upstream proxy handling and backend application behavior, such as changed perceived host, protocol, or client address.
5. Use the parsing discrepancy to inject misleading forwarded metadata into application logic or logs.
6. Leverage the influenced metadata to bypass weak trust controls, create misleading audit records, alter generated links, or affect routing and security decisions where the application relies on those values.

How to detect it

Look for signs of crafted Forwarded headers in HTTP access logs, reverse proxy logs, WAF logs, CDN request logs, application request logs, and any structured request-header telemetry. Focus on Forwarded header values where a quoted string contains a semicolon followed by text resembling another RFC 7239 parameter, such as host=, proto=, for=, or by=. Investigate requests where the edge device recorded one Forwarded interpretation but the backend application logged a different client IP, host, or scheme. Review authentication, authorization, rate-limit, redirect, and error logs for unusual behavior correlated with suspicious Forwarded headers. Because this vulnerability does not inherently create files, processes, registry keys, or persistent artifacts, detection is primarily log-based. No named threat actors, ransomware campaigns, or known public exploitation are currently associated with this issue based on the provided data.

• Forwarded: for=";host=
• Forwarded: for=";proto=
• Forwarded: for=";for=
• Forwarded: for=";by=
• Forwarded: host=";for=
• Forwarded: host=";proto=
• Forwarded: proto=";host=
• Forwarded: by=";for=
• Forwarded: for="_hidden;host=
• Forwarded: for="unknown;host=
• Forwarded: for="127.0.0.1;host=
• Forwarded: for="localhost;host=

What your security team should do

• Inventory Ruby applications, containers, and services that include Rack, including transitive dependencies through frameworks or middleware.
• Prioritize upgrading internet-facing applications and services that sit behind proxies, CDNs, WAFs, ingress controllers, or load balancers that preserve Forwarded headers.
• Upgrade affected Rack deployments to 3.1.21 or later on the 3.1 branch, or 3.2.6 or later on the 3.2 branch.
• At the edge, strip or overwrite untrusted client-supplied Forwarded headers unless they are explicitly required and normalized by a trusted proxy layer.
• Search access logs for Forwarded headers containing semicolons inside quoted strings, especially where embedded text resembles host=, proto=, for=, or by= parameters.
• Review application code and middleware for trust decisions based on Forwarded-derived host, scheme, or client IP values.
• Add regression tests for quoted Forwarded header parsing to prevent future parser/proxy inconsistencies.
• Treat this as moderate priority unless local evidence shows security-sensitive reliance on Forwarded metadata or active probing in logs.