CVE-2024-54133

What it actually does

This vulnerability affects Action Pack/Rails applications using the `content_security_policy` helper to build Content-Security-Policy headers from untrusted or insufficiently validated input. A crafted input value can inject additional CSP directives into the generated header, weakening or overriding the intended policy. The flaw does not automatically execute code on the server; it enables browser-side policy bypass, which can make existing or separately introduced content-injection issues exploitable as cross-site scripting or allow resources from attacker-controlled origins that the application intended to block.

Why it matters to the business

Successful exploitation can reduce browser-side protections that prevent malicious script execution, increasing the risk of account takeover, session theft, fraudulent actions performed in a user’s browser, data exposure visible to the affected user, and reputational impact from client-side compromise. The issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, and has low EPSS probability, but it has been public since 2024-12-10, so affected Rails applications should be treated as overdue for routine security patching, especially where CSP values are derived from request parameters, user profiles, tenant settings, redirects, or other user-controlled configuration.

How an attack unfolds

An attacker first identifies an application endpoint that returns a Content-Security-Policy header generated with Action Pack’s `content_security_policy` helper and influenced by attacker-controlled input. The attacker supplies a specially crafted value that causes the helper to emit an unintended additional CSP directive, such as a more permissive `script-src`, `default-src`, `img-src`, `connect-src`, or related directive. When a victim loads the affected page, the browser enforces the attacker-influenced CSP rather than the intended restrictive policy. If the page also contains script injection, user-generated HTML, unsafe redirects, JSONP-style behavior, or another client-side injection primitive that CSP would normally mitigate, the attacker can use the weakened policy to execute JavaScript, load attacker-controlled resources, or bypass restrictions intended to prevent XSS. Exploitation generally requires application-specific conditions: dynamic CSP construction from untrusted input and user interaction with a crafted link or page.

How to fix it

Upgrade Action Pack/Rails to a fixed release: 7.0.8.7, 7.1.5.1, 7.2.2.1, 8.0.0.1, or later. For source-based Rails deployments, ensure the fix commit `778eab826538be6da355d848aecaea2245e3b8ce` or a later upstream commit is present. If using the affected Ubuntu `notary` package, update to `0.1~ds1-1` or later from the appropriate supported repository. As a workaround until upgrade, do not build CSP headers directly from untrusted input. Replace dynamic CSP values with strict allowlists, canonicalize and validate hosts/schemes, reject directive separators such as semicolons and newlines, and avoid allowing user-controlled values to influence `script-src`, `default-src`, `object-src`, `base-uri`, `frame-ancestors`, `connect-src`, or `report-uri`/`report-to` without strict validation. Review any custom middleware or controller logic that mutates CSP headers after Rails generates them.

How to confirm the fix worked

Confirm the deployed Action Pack/Rails version is fixed by checking dependency manifests and runtime versions, for example `bundle info actionpack`, `bundle list | grep actionpack`, `Gemfile.lock`, container SBOMs, or package inventories. Verify the running application returns the expected Content-Security-Policy header and that attacker-controlled inputs cannot add new directives, change directive boundaries, or introduce permissive sources. Test representative endpoints with benign payloads containing semicolons, commas, spaces, encoded semicolons, CR/LF encodings, and CSP directive names, and confirm the response header remains unchanged or safely rejects the input. Re-run application security tests for CSP regressions and browser-side XSS paths after patching. If compensating controls were applied, validate they reject untrusted CSP source expressions rather than merely escaping display output.

Typical attack path

1. Find a Rails/Action Pack application running an affected version from 5.2.0 before 7.0.8.7, 7.1.5.1, 7.2.2.1, or 8.0.0.1.
2. Identify an endpoint where the Content-Security-Policy response header changes based on request parameters, user-controlled settings, profile fields, hostnames, redirect destinations, or other untrusted input.
3. Submit crafted input containing CSP directive separators or directive names to inject a new or more permissive policy directive.
4. Deliver the crafted URL, form, or stored setting to a victim so their browser receives the attacker-influenced CSP header.
5. Use the weakened CSP to load attacker-controlled script or resources, or to make a separate content-injection flaw exploitable as browser-side script execution.
6. Abuse the victim’s browser session to read accessible page data, perform actions as the user, or pivot to additional client-side attacks.

How to detect it

To determine whether this was already exploited, review web access logs, WAF logs, reverse proxy logs, Rails application logs, CDN logs, and CSP violation report endpoints for requests where user-controlled parameters contain CSP directive names, semicolon-separated directives, CR/LF encodings, or permissive script policy keywords. Compare historical Content-Security-Policy response headers for affected endpoints before and after suspicious requests, looking for unexpected directives or sources that were not part of the approved policy. Investigate CSP reports showing blocked or allowed script, frame, connect, image, or style loads from unfamiliar domains, especially when correlated with requests containing encoded separators or CSP keywords. Browser-side exploitation may leave limited server-side evidence; prioritize correlation among suspicious inbound payloads, altered CSP headers, CSP violation reports, unusual outbound resource domains in client telemetry, and subsequent user-account activity anomalies.

• Content-Security-Policy
• script-src
• default-src
• object-src
• base-uri
• frame-ancestors
• connect-src
• report-uri
• report-to
• unsafe-inline
• unsafe-eval
• data:
• blob:
• %3Bscript-src
• %3Bdefault-src
• %3Bobject-src
• %3Bconnect-src
• %0d%0aContent-Security-Policy
• %0D%0AContent-Security-Policy
• ; script-src
• ; default-src
• ; object-src
• ; connect-src

What your security team should do

• Inventory Rails and Action Pack versions across applications, containers, build artifacts, and source repositories; prioritize anything using Action Pack 5.2.0 or later below the fixed versions.
• Patch to Rails/Action Pack 7.0.8.7, 7.1.5.1, 7.2.2.1, 8.0.0.1, or later during the next security maintenance window; accelerate internet-facing or high-trust applications that use dynamic CSP generation.
• Search code for dynamic CSP construction from request parameters, database-backed user settings, profile fields, tenant configuration, redirect URLs, host headers, or other untrusted sources.
• Implement allowlist-based validation for CSP source values and reject semicolons, CR/LF characters, and unexpected CSP directive tokens in any value that can influence security headers.
• Review historical access logs and application logs for CSP directive-injection attempts, especially requests containing encoded semicolons, CR/LF sequences, `script-src`, `default-src`, or `'unsafe-inline'` in parameters.
• Add regression tests that assert CSP headers cannot be modified by user-controlled input.
• Monitor CSP violation reports, browser telemetry, WAF alerts, and web logs for sudden policy changes or resource loads from unexpected domains.
• Because the issue is not currently KEV-listed and has low EPSS, prioritize based on exposure and application behavior rather than treating it as an actively exploited emergency.