secure_headers manages application of security headers with many safe defaults. Prior to 7.3.0, secure_headers builds the Content-Security-Policy value by stitching directives with ; separators, and build_sandbox_list_directive, build_media_type_list_directive, and build_report_to_directive interpolate caller-supplied strings without scrubbing ;, \r, or \n. When untrusted input reaches SecureHeaders.override_content_security_policy_directives or append APIs for :sandbox, :plugin_types, or :report_to, an attacker can inject a CSP directive such as script-src 'unsafe-inline' * before the legitimate script-src, enabling XSS reachability through these sinks or CSP report exfiltration. This issue is fixed in version 7.3.0.

Affected: RubyGems: secure_headers

## 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](https://www.w3.org/TR/CSP3/#parse-serialized-policy), defeating the application's real `script-src`. End result: an `'unsafe-inline' *` policy is forced for inline `<script>` 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 on…

Affected: Ubuntu:18.04:LTS: ruby-secure-headers, Ubuntu:20.04:LTS: ruby-secure-headers, Ubuntu:22.04:LTS: ruby-secure-headers, Ubuntu:24.04:LTS: ruby-secure-headers, Ubuntu:26.04:LTS: ruby-secure-headers

secure_headers manages application of security headers with many safe defaults. Prior to 7.3.0, secure_headers builds the Content-Security-Policy value by stitching directives with ; separators, and build_sandbox_list_directive, build_media_type_list_directive, and build_report_to_directive interpolate caller-supplied strings without scrubbing ;, \r, or \n. When untrusted input reaches SecureHeaders.override_content_security_policy_directives or append APIs for :sandbox, :plugin_types, or :report_to, an attacker can inject a CSP directive such as script-src 'unsafe-inline' * before the legitimate script-src, enabling XSS reachability through these sinks or CSP report exfiltration. This issue is fixed in version 7.3.0.