CVE-2026-54163

What it actually does

The flaw is a Content-Security-Policy construction weakness in secure_headers before version 7.3.0. Certain CSP directive builders interpolate caller-controlled strings into the final header without removing semicolons, carriage returns, or newlines. If untrusted data reaches the CSP override or append APIs for sandbox, plugin_types, or report_to, an attacker can break out of the intended directive and inject an additional CSP directive. A successful injection can weaken protections such as script-src, for example by allowing unsafe inline JavaScript or broad script origins, and may also redirect CSP reporting data to an attacker-controlled endpoint. The issue does not directly execute code by itself, but it can make otherwise blocked cross-site scripting paths exploitable or leak CSP violation telemetry.

Why it matters to the business

Applications relying on secure_headers for browser-side protections may unintentionally ship weakened security headers when attacker-controlled input is used in CSP customization. The main business risk is increased likelihood of successful cross-site scripting, which can lead to session theft, fraudulent user actions, data exposure in the browser, or abuse of trusted application workflows. Because exploitation requires a vulnerable integration pattern and user interaction, the practical risk is lower than a standalone remote code execution issue; however, internet-facing applications that dynamically build CSP values from request parameters, user profile fields, tenant settings, or other externally influenced configuration should treat this as a meaningful application-security exposure. The issue is not currently listed in the CISA KEV catalog, is not known to be used in ransomware campaigns, has low EPSS, and has no reported public exploit maturity, but remediation is still recommended because CSP bypasses often become useful as part of broader XSS chains.

How an attack unfolds

An attacker first identifies an application using a vulnerable version of secure_headers where CSP directives are modified dynamically through the affected override or append APIs. The attacker then finds an input path that influences sandbox, plugin_types, or report_to values. By supplying a value containing a directive separator such as a semicolon, or header-control characters such as carriage return or newline where applicable, the attacker causes the application to emit an unintended CSP directive before the legitimate directive. For example, the injected header value may add a permissive script-src directive that allows inline scripts or scripts from arbitrary origins. The attacker then combines the weakened policy with an XSS sink that would normally have been blocked by CSP, or uses the injected reporting directive to send CSP violation reports to infrastructure they control. The victim must load or interact with the affected page for browser-side impact to occur.

How to fix it

Upgrade secure_headers to version 7.3.0 or later wherever it is used. If package manifests or lockfiles pin an earlier release, update both the declared dependency and the resolved lockfile version, then redeploy affected applications. As a defense-in-depth measure, do not pass untrusted input directly into Content-Security-Policy construction APIs. Treat CSP directives as configuration, not user data. If dynamic CSP customization is unavoidable, strictly allowlist expected values, reject semicolons, carriage returns, and newlines, and avoid constructing directives by string concatenation. Review any use of SecureHeaders.override_content_security_policy_directives and append APIs for sandbox, plugin_types, and report_to to ensure all inputs are trusted or validated. Maintain a restrictive CSP that avoids unsafe-inline and broad wildcard script sources unless there is a documented exception.

How to confirm the fix worked

Confirm the installed secure_headers version is 7.3.0 or later in dependency manifests, lockfiles, runtime package inventories, and built deployment artifacts. Review application code for calls to SecureHeaders.override_content_security_policy_directives and CSP append logic involving sandbox, plugin_types, or report_to. Verify those paths do not receive request parameters, user-controlled settings, external API values, or other untrusted strings. In a test environment, attempt to supply values containing semicolons, carriage returns, or newlines to any dynamic CSP inputs and confirm the resulting Content-Security-Policy header does not include injected directives. Capture HTTP responses from representative application routes and verify CSP headers remain as intended, especially that script-src is not unexpectedly loosened and reporting endpoints are trusted.

Typical attack path

1. Fingerprint or infer that the target application uses secure_headers before version 7.3.0 for Content-Security-Policy generation.
2. Find a request parameter, stored setting, profile field, tenant-level configuration value, or API input that is passed into CSP override or append logic for sandbox, plugin_types, or report_to.
3. Submit a crafted value containing a CSP directive separator or control characters to break out of the intended directive.
4. Cause the application to emit a modified Content-Security-Policy header containing attacker-chosen directives such as a permissive script-src or attacker-controlled report-to/report-uri destination.
5. Trigger a victim browser to load the affected page.
6. Use the weakened CSP to execute or enable an XSS payload, or collect CSP reports sent to attacker-controlled infrastructure.

How to detect it

To determine whether this was already exploited, review HTTP access logs, application logs, WAF logs, reverse proxy logs, and any logs that capture request parameters or settings used to build CSP values. Look for attacker-supplied semicolons, carriage returns, newlines, or URL-encoded equivalents in fields that influence CSP sandbox, plugin_types, or report_to configuration. Review captured response headers from CDN, proxy, or application telemetry for unexpected Content-Security-Policy values, especially permissive script-src directives, unsafe-inline, wildcard script origins, duplicate script-src directives, or report-to/report-uri destinations not owned by the organization. Correlate suspicious CSP changes with browser-side security events, CSP violation reports, XSS alerts, abnormal session activity, suspicious user-agent activity, and requests to untrusted script hosts. If CSP reports are collected centrally, search for sudden changes in report destinations or reports referencing unexpected inline script execution. There are no known public threat actors or KEV exploitation records for this issue at the time of the supplied data, so detection should focus on anomalous CSP header generation and attempted delimiter injection rather than named-campaign indicators.

• SecureHeaders.override_content_security_policy_directives
• build_sandbox_list_directive
• build_media_type_list_directive
• build_report_to_directive
• Content-Security-Policy:
• script-src 'unsafe-inline' *
• script-src * 'unsafe-inline'
• script-src *
• 'unsafe-inline'
• report-to http://
• report-to https://
• report-uri http://
• report-uri https://
• %3Bscript-src
• %3bscript-src
• ;script-src
• %0d%0aContent-Security-Policy
• %0D%0AContent-Security-Policy
• \r\nContent-Security-Policy
• plugin-types
• sandbox
• report-to

What your security team should do

• Inventory applications and services that use the secure_headers library and identify versions earlier than 7.3.0.
• Prioritize upgrades for internet-facing applications and applications that dynamically customize CSP based on request, user, tenant, or externally supplied configuration data.
• Search source code for SecureHeaders.override_content_security_policy_directives and append usage involving sandbox, plugin_types, or report_to, then validate input trust boundaries.
• Add automated dependency checks to flag secure_headers versions below 7.3.0.
• Add tests that assert generated Content-Security-Policy headers cannot be altered by semicolons, carriage returns, or newlines in dynamic inputs.
• Review existing CSP policies for unexpected unsafe-inline, wildcard script sources, or untrusted reporting endpoints.
• If suspicious CSP weakening is observed, investigate adjacent XSS indicators, session abuse, and unexpected outbound traffic to CSP reporting collectors.