CVE-2023-28362

What it actually does

Rails' redirect_to method may accept redirect target values containing characters that are not valid in HTTP header values, such as control characters. When Rails builds an HTTP redirect response, the invalid value can be placed into the Location header. Some downstream HTTP components, including proxies, gateways, load balancers, security middleware, or strict clients that enforce RFC-compliant headers, may reject or strip the malformed Location header. The primary technical effect is redirect integrity failure: an application path that expects to redirect the user may instead return a response without the intended Location header, potentially altering application control flow or bypassing redirect-dependent logic. The reported impact is integrity-only and low severity; there is no direct indication of code execution, data disclosure, or service-wide denial of service.

Why it matters to the business

Applications relying on Rails redirects may behave inconsistently when malicious or malformed redirect destinations are processed, especially behind strict reverse proxies or gateways. This can cause broken login, logout, payment, onboarding, authorization, or workflow transitions if those flows depend on a valid Location header. The risk is generally limited compared with remote code execution or data theft vulnerabilities, and current exploit likelihood is low based on the provided EPSS score and no known KEV listing, but internet-facing Rails applications should still be updated because redirect behavior often protects business-critical user journeys.

How an attack unfolds

An attacker identifies an application endpoint that calls Rails redirect_to with attacker-influenced input, such as a return URL, next path, callback URL, or redirect parameter. The attacker supplies a redirect value containing characters that are illegal in HTTP header values, commonly encoded control characters. Rails constructs a redirect response using that value. If a downstream HTTP component strictly validates response headers, it may remove or reject the Location header from the response. The attacker's practical objective is to disrupt or alter redirect-dependent application behavior, such as preventing navigation to the expected destination, influencing error handling, or interfering with application state transitions that assume the redirect succeeded. Exploitation depends heavily on application routing, whether user input reaches redirect_to, and the behavior of downstream HTTP infrastructure.

How to fix it

Upgrade Rails to a version or commit containing the fix. For source-based Rails deployments, ensure the code includes commit 1c3f93d1e90a3475f9ae2377ead25ccf11f71441 or a later release that incorporates it. In addition, audit application code for redirect_to calls that use request parameters or other untrusted values. Prefer allowlisted internal paths over arbitrary URLs, reject control characters and invalid URI/header characters before redirecting, and use framework-supported redirect safety controls. As a defense-in-depth measure, configure reverse proxies and application gateways to log malformed response headers rather than silently masking issues, and add tests for redirect endpoints using encoded control characters such as %0d, %0a, %00, and other non-printable characters.

How to confirm the fix worked

Confirm the deployed Rails version or source revision includes commit 1c3f93d1e90a3475f9ae2377ead25ccf11f71441 or a later fixed release. Review dependency manifests, lockfiles, container images, vendored Rails code, and runtime package metadata to ensure the patched Rails code is actually deployed. Exercise application endpoints that call redirect_to with representative malicious redirect values containing encoded control characters and verify that the application rejects, sanitizes, or safely handles the input rather than producing a malformed Location header. Inspect responses through the full production-like request path, including reverse proxies and gateways, to confirm redirect responses retain valid RFC-compliant headers only. Add regression tests around any redirect endpoint that accepts user-controlled destinations.

Typical attack path

1. Find a Rails endpoint that performs an HTTP redirect based on request-controlled input, such as return_to, redirect_url, next, url, destination, or callback parameters.
2. Send requests containing illegal HTTP header characters in the redirect target, often using URL-encoded carriage return, line feed, or other control-character encodings.
3. Trigger Rails to generate a redirect response with a malformed Location header value.
4. Rely on a downstream proxy, gateway, load balancer, WAF, or client enforcing strict HTTP header compliance to strip or reject the Location header.
5. Observe whether the application returns a redirect status without a usable Location header or otherwise diverges from the expected workflow.
6. Use the behavior to disrupt or manipulate redirect-dependent user flows where application logic incorrectly assumes the redirect completed successfully.

How to detect it

Review web access logs, application logs, proxy logs, WAF logs, and gateway logs for requests to redirect-capable endpoints containing encoded or raw control characters in URL paths, query strings, form parameters, or headers. Focus on parameters commonly used for redirects, such as return_to, returnUrl, redirect, redirect_url, next, url, destination, continue, callback, and target. Look for 3xx responses that lack a Location header, proxy warnings about invalid response headers, HTTP parser errors, or gateway messages indicating a response header was dropped. Compare application logs showing a redirect was issued with edge/proxy logs showing the client did not receive a valid Location header. For forensic review, correlate suspicious requests containing %0d, %0a, %00, or other encoded control characters with user sessions, authentication events, failed workflow completions, and unusual error responses. There are no known named threat actors or KEV-listed exploitation campaigns from the provided data, so detection should emphasize malformed redirect probing and abnormal 3xx behavior rather than actor-specific indicators.

• %0d
• %0a
• %0D
• %0A
• %0d%0a
• %0D%0A
• %00
• %09
• %1f
• %7f
• return_to=%0d
• return_to=%0a
• returnUrl=%0d
• returnUrl=%0a
• redirect=%0d
• redirect=%0a
• redirect_url=%0d
• redirect_url=%0a
• next=%0d
• next=%0a
• url=%0d
• url=%0a
• destination=%0d
• destination=%0a
• callback=%0d
• callback=%0a
• target=%0d
• target=%0a
• continue=%0d
• continue=%0a
• Location header removed
• invalid response header
• invalid header value
• malformed response header
• response header too invalid
• 3xx response without Location
• redirect response missing Location
• ActionController::Redirecting
• redirect_to

What your security team should do

• Inventory Rails applications and identify those using source checkouts or versions that may not include commit 1c3f93d1e90a3475f9ae2377ead25ccf11f71441.
• Prioritize patching internet-facing Rails applications and applications with authentication, authorization, payment, or callback flows that depend on redirects.
• Search code for redirect_to calls using request parameters or other untrusted input and replace them with allowlisted internal redirect destinations where possible.
• Add input validation that rejects control characters and invalid URI/header characters in redirect targets.
• Test critical redirect flows through the same proxy, gateway, CDN, and WAF path used in production to detect stripped or missing Location headers.
• Create monitoring for redirect responses where 3xx status codes are returned without a Location header, especially when requests contain encoded control characters.
• Because this issue is not listed in KEV and has low EPSS, handle it as a normal patch-cycle vulnerability unless application-specific exposure makes redirect integrity business-critical.