<?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>Fri, 02 Oct 2026 19:40:08 +0000</lastBuildDate>
    <item>
      <title>CLEANSTART-2026-AZ47953 — Security fix for CVE-2026-48815 applied in: pulumi 3.248.0-r0, renovate 44.31.0-r2, renovate 44.32.4-r1, renovate 44.32…</title>
      <link>https://cve.radiocsirt.org/vuln/cleanstart-2026-az47953</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; CleanStart: pulumi, CleanStart: renovate&lt;/p&gt;
&lt;p&gt;CVE-2026-48815 affects multiple packages. This issue is resolved in later releases. See references for individual vulnerability details.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; CleanStart: pulumi, CleanStart: renovate&lt;/p&gt;
&lt;p&gt;CVE-2026-48815 affects multiple packages. This issue is resolved in later releases. See references for individual vulnerability details.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cleanstart-2026-az47953</guid>
    </item>
    <item>
      <title>EUVD-2026-337882</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-337882</link>
      <description>EUVD-2026-337882</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-337882</guid>
    </item>
    <item>
      <title>fkie_cve-2026-48815</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-48815</link>
      <description>&lt;p&gt;sigstore-js provides JavaScript libraries for interacting with Sigstore services. Prior to 4.1.1, the documented certificateOIDs option in sigstore.verify() is accepted by the public API but discarded before verification, so required certificate extension OIDs are never checked and applications relying on certificateOIDs to restrict which certificates may sign artifacts can accept unauthorized certificates. This issue is fixed in version 4.1.1.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;sigstore-js provides JavaScript libraries for interacting with Sigstore services. Prior to 4.1.1, the documented certificateOIDs option in sigstore.verify() is accepted by the public API but discarded before verification, so required certificate extension OIDs are never checked and applications relying on certificateOIDs to restrict which certificates may sign artifacts can accept unauthorized certificates. This issue is fixed in version 4.1.1.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-48815</guid>
    </item>
    <item>
      <title>GHSA-52v5-jr5w-gjxr — sigstore's `certificateOIDs` verification constraints are silently dropped and never enforced</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-52v5-jr5w-gjxr</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: sigstore&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;The documented `certificateOIDs` option in `sigstore.verify()` is accepted by the public API but discarded before verification, so required certificate extension OIDs are never checked.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;The public verify options include `certificateOIDs` and the documentation says those OID/value pairs “must be present in the certificate’s extension list.” The policy-construction path used by `sigstore.verify()` and `createVerifier()` only copies the SAN and issuer settings into the verification policy and completely ignores `certificateOIDs`.&lt;/p&gt;
&lt;p&gt;As a result, callers can believe they are constraining verification to certificates carrying specific Fulcio or workload-identifying OIDs, while the actual verifier never receives those constraints. Any bundle that satisfies the remaining checks is accepted even if the required OID extensions are absent or mismatched.&lt;/p&gt;
&lt;p&gt;This is reachable from supported usage through the documented `certificateOIDs` verify option.&lt;/p&gt;
&lt;p&gt;### PoC&lt;/p&gt;
&lt;p&gt;```javascript
const { createVerificationPolicy } = require(&amp;#34;sigstore/dist/config&amp;#34;);&lt;/p&gt;
&lt;p&gt;const policy = createVerificationPolicy({
  certificateIssuer: &amp;#34;https://issuer.example&amp;#34;,
  certificateIdentityEmail: &amp;#34;victim@example.com&amp;#34;,
  certificateOIDs: {
    &amp;#34;1.2.3.4&amp;#34;: &amp;#34;required-value&amp;#34;,
  },
});&lt;/p&gt;
&lt;p&gt;console.log(&amp;#34;certificateOIDs&amp;#34; in policy, JSON.stringify(policy));
// false {&amp;#34;subjectAlternativeName&amp;#34;:&amp;#34;victim@example.com&amp;#34;,&amp;#34;extensions&amp;#34;:{&amp;#34;issuer&amp;#34;:&amp;#34;https://issuer.example&amp;#34;}}
```&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;Applications that rely on `certific…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: sigstore&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;The documented `certificateOIDs` option in `sigstore.verify()` is accepted by the public API but discarded before verification, so required certificate extension OIDs are never checked.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;The public verify options include `certificateOIDs` and the documentation says those OID/value pairs “must be present in the certificate’s extension list.” The policy-construction path used by `sigstore.verify()` and `createVerifier()` only copies the SAN and issuer settings into the verification policy and completely ignores `certificateOIDs`.&lt;/p&gt;
&lt;p&gt;As a result, callers can believe they are constraining verification to certificates carrying specific Fulcio or workload-identifying OIDs, while the actual verifier never receives those constraints. Any bundle that satisfies the remaining checks is accepted even if the required OID extensions are absent or mismatched.&lt;/p&gt;
&lt;p&gt;This is reachable from supported usage through the documented `certificateOIDs` verify option.&lt;/p&gt;
&lt;p&gt;### PoC&lt;/p&gt;
&lt;p&gt;```javascript
const { createVerificationPolicy } = require(&amp;#34;sigstore/dist/config&amp;#34;);&lt;/p&gt;
&lt;p&gt;const policy = createVerificationPolicy({
  certificateIssuer: &amp;#34;https://issuer.example&amp;#34;,
  certificateIdentityEmail: &amp;#34;victim@example.com&amp;#34;,
  certificateOIDs: {
    &amp;#34;1.2.3.4&amp;#34;: &amp;#34;required-value&amp;#34;,
  },
});&lt;/p&gt;
&lt;p&gt;console.log(&amp;#34;certificateOIDs&amp;#34; in policy, JSON.stringify(policy));
// false {&amp;#34;subjectAlternativeName&amp;#34;:&amp;#34;victim@example.com&amp;#34;,&amp;#34;extensions&amp;#34;:{&amp;#34;issuer&amp;#34;:&amp;#34;https://issuer.example&amp;#34;}}
```&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;Applications that rely on `certific…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-52v5-jr5w-gjxr</guid>
    </item>
  </channel>
</rss>
