GitHub Advisoryadvisory · RubyGems

GHSA-rqq5-2gf9-4w4q Secure Headers: CSP directive injection via sandbox, plugin_types, and report_to when given untrusted input

MEDIUM Published 2026-07-10 Modified 2026-07-10 Official page ↗
Aliases
CVE-2026-54163
Ecosystem
RubyGems
Packages
secure_headers
Severity
Moderate
CVSS vector
CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:L/A:N
Weaknesses
CWE-113, CWE-79
Reviewed
2026-07-10

Affected packages

• RubyGems secure_headers: < 7.3.0 → fixed in 7.3.0

Description

Summary `secure_headers` builds the `Content-Security-Policy` value by stitching every configured directive together with `; ` separators. Three directive builders (`build_sandbox_list_directive`, `build_media_type_list_directive`, `build_report_to_directive`) interpolate caller-supplied strings into that value without scrubbing `;`, `\r`, or `\n`. When an application forwards untrusted input into `SecureHeaders.override_content_security_policy_directives` (or `append_…`) for `:sandbox`, `:plugin_types`, or `:report_to`, an attacker can embed a literal `;` and inject an arbitrary CSP directive into the header value. Because `:sandbox` and `:plugin_types` both sort alphabetically before `:script_src` in `BODY_DIRECTIVES`, the injected `script-src` lands earlier in the header and wins under the CSP first-occurrence rule, defeating the application's real `script-src`. End result: an `'unsafe-inline' *` policy is forced for inline `` despite the configured strict CSP, giving full XSS reachability anywhere reflected or stored content meets one of these three sinks. An existing `;`/`\n` scrub is already present in the source-list builder (`build_source_list_directive`), but the three sibling builders here never received the same treatment and still emit caller bytes verbatim into the CSP value. Impact Although piping untrusted input into CSP directives is generally discouraged, applications that do so for one of the three uncovered directives turn that endpoint into an XSS sink with an effective `*` `'unsafe-inline'` `script-src`, even though the global config says `script_src: %w('self')`. The same primitive can also be used to point `report-to` / `report-uri` at attacker infrastructure to silently siphon CSP violation reports — which include the violated URL, blocked-uri, source-file, line-number and a sample-snippet, useful for fingerprinting and for harvesting victim-internal URLs. The global default CSP set in `Configuration.default` is supposed to be a backstop: even if a controller appends a single risky value, the strict `script-src` should remain the first match. This bug breaks that property by letting the appended value redefine the policy header upstream of the legitimate `script-src`. Affected • Package: `secure_headers` (RubyGems) • Vulnerable versions: `document.body.appendChild(Object.assign(" \ "document.createElement('div'),{id:'pwn',innerText:" \ "'XSS-EXECUTED via '+location.pathname}));" class App def call(env) req = Rack::Request.new(env) case req.path_info when "/sandbox" # Vecto…

Related

Alias · CVE (1)

  • CVE-2026-54163 secure_headers manages application of security headers with many safe defaults. vulnerability

Weakness · CWE (2)

  • CWE-113 Improper Neutralization of CRLF Sequences in HTTP Headers weakness
  • CWE-79 Improper Neutralization of Input During Web Page Generation weakness

References