<?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 10:47:15 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-330233</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-330233</link>
      <description>EUVD-2026-330233</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-330233</guid>
    </item>
    <item>
      <title>fkie_cve-2026-49440</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-49440</link>
      <description>&lt;p&gt;Deno is a JavaScript, TypeScript, and WebAssembly runtime. Prior to 2.8.1, node:crypto.checkPrime(candidate[, options][, callback]) and crypto.checkPrimeSync(candidate[, options]) ran no Miller-Rabin rounds at all when the caller left options.checks at its default of 0. In that mode, the only test applied to the candidate was trial division by the primes up to 17,863. Any composite whose smallest prime factor exceeds that bound — for example the product of two primes just above it, such as 17,881 × 17,891 — was reported as true (&amp;#34;probably prime&amp;#34;). The same divergence affected the lower-level op_node_check_prime / op_node_check_prime_bytes paths that the polyfill calls into. This vulnerability is fixed in 2.8.1.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Deno is a JavaScript, TypeScript, and WebAssembly runtime. Prior to 2.8.1, node:crypto.checkPrime(candidate[, options][, callback]) and crypto.checkPrimeSync(candidate[, options]) ran no Miller-Rabin rounds at all when the caller left options.checks at its default of 0. In that mode, the only test applied to the candidate was trial division by the primes up to 17,863. Any composite whose smallest prime factor exceeds that bound — for example the product of two primes just above it, such as 17,881 × 17,891 — was reported as true (&amp;#34;probably prime&amp;#34;). The same divergence affected the lower-level op_node_check_prime / op_node_check_prime_bytes paths that the polyfill calls into. This vulnerability is fixed in 2.8.1.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-49440</guid>
    </item>
    <item>
      <title>GHSA-9xg4-qhm4-g43w — Deno: Miller-Rabin Primality Test Allows Zero Rounds</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-9xg4-qhm4-g43w</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; crates.io: deno&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;`node:crypto.checkPrime(candidate[, options][, callback])` and `crypto.checkPrimeSync(candidate[, options])` ran no Miller-Rabin rounds at all when the caller left `options.checks` at its default of `0`. In that mode, the only test applied to the candidate was trial division by the primes up to `17,863`. Any composite whose smallest prime factor exceeds that bound — for example the product of two primes just above it, such as `17,881 × 17,891` — was reported as `true` (&amp;#34;probably prime&amp;#34;).&lt;/p&gt;
&lt;p&gt;The same divergence affected the lower-level `op_node_check_prime` / `op_node_check_prime_bytes` paths that the polyfill calls into.&lt;/p&gt;
&lt;p&gt;Node.js itself does not have this problem: it forwards `checks = 0` to OpenSSL&amp;#39;s `BN_check_prime`, which substitutes a sensible default number of rounds based on the candidate&amp;#39;s bit length (per FIPS 186-4 Appendix C.3 Table C.1). Deno&amp;#39;s Rust implementation had no equivalent fallback, so `count = 0` meant &amp;#34;skip the loop entirely.&amp;#34;&lt;/p&gt;
&lt;p&gt;## Affected APIs&lt;/p&gt;
&lt;p&gt;- `crypto.checkPrime(candidate)` (callback form, default options)
- `crypto.checkPrime(candidate, { checks: 0 }, callback)`
- `crypto.checkPrimeSync(candidate)` (default options)
- `crypto.checkPrimeSync(candidate, { checks: 0 })`&lt;/p&gt;
&lt;p&gt;Callers who explicitly passed `checks &amp;gt;= 1` were less affected, the loop ran the number of rounds they asked for, but were still receiving fewer rounds than Node would have applied for the same bit length. With the patched version they get at least the FIPS minimum.&lt;/p&gt;
&lt;p&gt;## Not a…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; crates.io: deno&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;`node:crypto.checkPrime(candidate[, options][, callback])` and `crypto.checkPrimeSync(candidate[, options])` ran no Miller-Rabin rounds at all when the caller left `options.checks` at its default of `0`. In that mode, the only test applied to the candidate was trial division by the primes up to `17,863`. Any composite whose smallest prime factor exceeds that bound — for example the product of two primes just above it, such as `17,881 × 17,891` — was reported as `true` (&amp;#34;probably prime&amp;#34;).&lt;/p&gt;
&lt;p&gt;The same divergence affected the lower-level `op_node_check_prime` / `op_node_check_prime_bytes` paths that the polyfill calls into.&lt;/p&gt;
&lt;p&gt;Node.js itself does not have this problem: it forwards `checks = 0` to OpenSSL&amp;#39;s `BN_check_prime`, which substitutes a sensible default number of rounds based on the candidate&amp;#39;s bit length (per FIPS 186-4 Appendix C.3 Table C.1). Deno&amp;#39;s Rust implementation had no equivalent fallback, so `count = 0` meant &amp;#34;skip the loop entirely.&amp;#34;&lt;/p&gt;
&lt;p&gt;## Affected APIs&lt;/p&gt;
&lt;p&gt;- `crypto.checkPrime(candidate)` (callback form, default options)
- `crypto.checkPrime(candidate, { checks: 0 }, callback)`
- `crypto.checkPrimeSync(candidate)` (default options)
- `crypto.checkPrimeSync(candidate, { checks: 0 })`&lt;/p&gt;
&lt;p&gt;Callers who explicitly passed `checks &amp;gt;= 1` were less affected, the loop ran the number of rounds they asked for, but were still receiving fewer rounds than Node would have applied for the same bit length. With the patched version they get at least the FIPS minimum.&lt;/p&gt;
&lt;p&gt;## Not a…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-9xg4-qhm4-g43w</guid>
    </item>
  </channel>
</rss>
