<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Sun, 04 Oct 2026 17:41:18 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-338968</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-338968</link>
      <description>EUVD-2026-338968</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-338968</guid>
    </item>
    <item>
      <title>fkie_cve-2026-54163</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-54163</link>
      <description>&lt;p&gt;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 &amp;#39;unsafe-inline&amp;#39; * before the legitimate script-src, enabling XSS reachability through these sinks or CSP report exfiltration. This issue is fixed in version 7.3.0.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;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 &amp;#39;unsafe-inline&amp;#39; * before the legitimate script-src, enabling XSS reachability through these sinks or CSP report exfiltration. This issue is fixed in version 7.3.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-54163</guid>
    </item>
    <item>
      <title>GHSA-rqq5-2gf9-4w4q — Secure Headers: CSP directive injection via sandbox, plugin_types, and report_to when given untrusted input</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-rqq5-2gf9-4w4q</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; RubyGems: secure_headers&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;`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`.&lt;/p&gt;
&lt;p&gt;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&amp;#39;s real `script-src`. End result: an `&amp;#39;unsafe-inline&amp;#39; *` policy is forced for inline `&amp;lt;script&amp;gt;` despite the configured strict CSP, giving full XSS reachability anywhere reflected or stored content meets one of these three sinks.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;## Impact&lt;/p&gt;
&lt;p&gt;Although piping untrusted input into CSP directives is generally discouraged, applications that do so for on…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; RubyGems: secure_headers&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;`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`.&lt;/p&gt;
&lt;p&gt;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&amp;#39;s real `script-src`. End result: an `&amp;#39;unsafe-inline&amp;#39; *` policy is forced for inline `&amp;lt;script&amp;gt;` despite the configured strict CSP, giving full XSS reachability anywhere reflected or stored content meets one of these three sinks.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;## Impact&lt;/p&gt;
&lt;p&gt;Although piping untrusted input into CSP directives is generally discouraged, applications that do so for on…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-rqq5-2gf9-4w4q</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-54163</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-54163</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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&lt;/p&gt;
&lt;p&gt;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 &amp;#39;unsafe-inline&amp;#39; * before the legitimate script-src, enabling XSS reachability through these sinks or CSP report exfiltration. This issue is fixed in version 7.3.0.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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&lt;/p&gt;
&lt;p&gt;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 &amp;#39;unsafe-inline&amp;#39; * before the legitimate script-src, enabling XSS reachability through these sinks or CSP report exfiltration. This issue is fixed in version 7.3.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-54163</guid>
    </item>
  </channel>
</rss>
