<?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>Thu, 08 Oct 2026 19:47:27 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-270743</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-270743</link>
      <description>EUVD-2026-270743</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-270743</guid>
    </item>
    <item>
      <title>fkie_cve-2026-22866</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-22866</link>
      <description>&lt;p&gt;Ethereum Name Service (ENS) is a distributed, open, and extensible naming system based on the Ethereum blockchain. In versions 1.6.2 and prior, the `RSASHA256Algorithm` and `RSASHA1Algorithm` contracts fail to validate PKCS#1 v1.5 padding structure when verifying RSA signatures. The contracts only check if the last 32 (or 20) bytes of the decrypted signature match the expected hash. This enables Bleichenbacher&amp;#39;s 2006 signature forgery attack against DNS zones using RSA keys with low public exponents (e=3). Two ENS-supported TLDs (.cc and .name) use e=3 for their Key Signing Keys, allowing any domain under these TLDs to be fraudulently claimed on ENS without DNS ownership. Apatch was merged at commit c76c5ad0dc9de1c966443bd946fafc6351f87587. Possible workarounds include deploying the patched contracts and pointing DNSSECImpl.setAlgorithm to the deployed contract.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ethereum Name Service (ENS) is a distributed, open, and extensible naming system based on the Ethereum blockchain. In versions 1.6.2 and prior, the `RSASHA256Algorithm` and `RSASHA1Algorithm` contracts fail to validate PKCS#1 v1.5 padding structure when verifying RSA signatures. The contracts only check if the last 32 (or 20) bytes of the decrypted signature match the expected hash. This enables Bleichenbacher&amp;#39;s 2006 signature forgery attack against DNS zones using RSA keys with low public exponents (e=3). Two ENS-supported TLDs (.cc and .name) use e=3 for their Key Signing Keys, allowing any domain under these TLDs to be fraudulently claimed on ENS without DNS ownership. Apatch was merged at commit c76c5ad0dc9de1c966443bd946fafc6351f87587. Possible workarounds include deploying the patched contracts and pointing DNSSECImpl.setAlgorithm to the deployed contract.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-22866</guid>
    </item>
    <item>
      <title>GHSA-c6rr-7pmc-73wc — ENS DNSSEC Oracle Vulnerable to RSA Signature Forgery via Missing PKCS#1 v1.5 Padding Validation</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-c6rr-7pmc-73wc</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: @ensdomains/ens-contracts&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;The `RSASHA256Algorithm` and `RSASHA1Algorithm` contracts fail to validate PKCS#1 v1.5 padding structure when verifying RSA signatures. The contracts only check if the last 32 (or 20) bytes of the decrypted signature match the expected hash. This enables Bleichenbacher&amp;#39;s 2006 signature forgery attack against DNS zones using RSA keys with low public exponents (e=3). Two ENS-supported TLDs (.cc and .name) use e=3 for their Key Signing Keys, allowing any domain under these TLDs to be fraudulently claimed on ENS without DNS ownership.&lt;/p&gt;
&lt;p&gt;Affected contracts&lt;/p&gt;
&lt;p&gt;Contract | Address | Status
-- | -- | --
RSASHA256Algorithm | 0x9D1B5a639597f558bC37Cf81813724076c5C1e96 | Vulnerable
RSASHA1Algorithm | 0x6ca8624Bc207F043D140125486De0f7E624e37A1 | Vulnerable
DNSSECImpl | 0x0fc3152971714E5ed7723FAFa650F86A4BaF30C5 | Uses vulnerable algorithms
DNSRegistrar | 0xB32cB5677a7C971689228EC835800432B339bA2B | Attack entry point&lt;/p&gt;
&lt;p&gt;### Patches&lt;/p&gt;
&lt;p&gt;The bug was reported via Immunefi with possible solutions. The patch was merged at https://github.com/ensdomains/ens-contracts/commit/c76c5ad0dc9de1c966443bd946fafc6351f87587&lt;/p&gt;
&lt;p&gt;### Workarounds&lt;/p&gt;
&lt;p&gt;- Deploy the patched contracts
- Point DNSSECImpl.setAlgorithm to the deployed contract&lt;/p&gt;
&lt;p&gt;### Resources&lt;/p&gt;
&lt;p&gt;https://github.com/ensdomains/ens-contracts-bug-62248-pr-509&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: @ensdomains/ens-contracts&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;The `RSASHA256Algorithm` and `RSASHA1Algorithm` contracts fail to validate PKCS#1 v1.5 padding structure when verifying RSA signatures. The contracts only check if the last 32 (or 20) bytes of the decrypted signature match the expected hash. This enables Bleichenbacher&amp;#39;s 2006 signature forgery attack against DNS zones using RSA keys with low public exponents (e=3). Two ENS-supported TLDs (.cc and .name) use e=3 for their Key Signing Keys, allowing any domain under these TLDs to be fraudulently claimed on ENS without DNS ownership.&lt;/p&gt;
&lt;p&gt;Affected contracts&lt;/p&gt;
&lt;p&gt;Contract | Address | Status
-- | -- | --
RSASHA256Algorithm | 0x9D1B5a639597f558bC37Cf81813724076c5C1e96 | Vulnerable
RSASHA1Algorithm | 0x6ca8624Bc207F043D140125486De0f7E624e37A1 | Vulnerable
DNSSECImpl | 0x0fc3152971714E5ed7723FAFa650F86A4BaF30C5 | Uses vulnerable algorithms
DNSRegistrar | 0xB32cB5677a7C971689228EC835800432B339bA2B | Attack entry point&lt;/p&gt;
&lt;p&gt;### Patches&lt;/p&gt;
&lt;p&gt;The bug was reported via Immunefi with possible solutions. The patch was merged at https://github.com/ensdomains/ens-contracts/commit/c76c5ad0dc9de1c966443bd946fafc6351f87587&lt;/p&gt;
&lt;p&gt;### Workarounds&lt;/p&gt;
&lt;p&gt;- Deploy the patched contracts
- Point DNSSECImpl.setAlgorithm to the deployed contract&lt;/p&gt;
&lt;p&gt;### Resources&lt;/p&gt;
&lt;p&gt;https://github.com/ensdomains/ens-contracts-bug-62248-pr-509&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-c6rr-7pmc-73wc</guid>
    </item>
  </channel>
</rss>
