<?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, 15 Oct 2026 22:38:29 +0000</lastBuildDate>
    <item>
      <title>CVE-2024-12224 — idna accepts Punycode labels that do not produce any non-ASCII when decoded</title>
      <link>https://cve.radiocsirt.org/vuln/cve-2024-12224</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; servo rust-url&lt;/p&gt;
&lt;p&gt;Improper Validation of Unsafe Equivalence in punycode by the idna crate from Servo rust-url allows an attacker to create a punycode hostname that one part of a system might treat as distinct while another part of that system would treat as equivalent to another hostname.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; servo rust-url&lt;/p&gt;
&lt;p&gt;Improper Validation of Unsafe Equivalence in punycode by the idna crate from Servo rust-url allows an attacker to create a punycode hostname that one part of a system might treat as distinct while another part of that system would treat as equivalent to another hostname.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cve-2024-12224</guid>
    </item>
    <item>
      <title>GHSA-h97m-ww89-6jmq — `idna` accepts Punycode labels that do not produce any non-ASCII when decoded</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-h97m-ww89-6jmq</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; crates.io: idna&lt;/p&gt;
&lt;p&gt;`idna` 0.5.0 and earlier accepts Punycode labels that do not produce any non-ASCII output, which means that either ASCII labels or the empty root label can be masked such that they appear unequal without IDNA processing or when processed with a different implementation and equal when processed with `idna` 0.5.0 or earlier.&lt;/p&gt;
&lt;p&gt;Concretely, `example.org` and `xn--example-.org` become equal after processing by `idna` 0.5.0 or earlier. Also, `example.org.xn--` and `example.org.` become equal after processing by `idna` 0.5.0 or earlier.&lt;/p&gt;
&lt;p&gt;In applications using `idna` (but not in `idna` itself) this may be able to lead to privilege escalation when host name comparison is part of a privilege check and the behavior is combined with a client that resolves domains with such labels instead of treating them as errors that preclude DNS resolution / URL fetching and with the attacker managing to introduce a DNS entry (and TLS certificate) for an `xn--`-masked name that turns into the name of the target when processed by `idna` 0.5.0 or earlier.&lt;/p&gt;
&lt;p&gt;## Remedy&lt;/p&gt;
&lt;p&gt;Upgrade to `idna` 1.0.3 or later, if depending on `idna` directly, or to `url` 2.5.4 or later, if depending on `idna` via `url`. (This issue was fixed in `idna` 1.0.0, but versions earlier than 1.0.3 are not recommended for other reasons.)&lt;/p&gt;
&lt;p&gt;When upgrading, please take a moment to read about [alternative Unicode back ends for `idna`](https://docs.rs/crate/idna_adapter/latest).&lt;/p&gt;
&lt;p&gt;If you are using Rust earlier than 1.81 in combination with SQLx…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; crates.io: idna&lt;/p&gt;
&lt;p&gt;`idna` 0.5.0 and earlier accepts Punycode labels that do not produce any non-ASCII output, which means that either ASCII labels or the empty root label can be masked such that they appear unequal without IDNA processing or when processed with a different implementation and equal when processed with `idna` 0.5.0 or earlier.&lt;/p&gt;
&lt;p&gt;Concretely, `example.org` and `xn--example-.org` become equal after processing by `idna` 0.5.0 or earlier. Also, `example.org.xn--` and `example.org.` become equal after processing by `idna` 0.5.0 or earlier.&lt;/p&gt;
&lt;p&gt;In applications using `idna` (but not in `idna` itself) this may be able to lead to privilege escalation when host name comparison is part of a privilege check and the behavior is combined with a client that resolves domains with such labels instead of treating them as errors that preclude DNS resolution / URL fetching and with the attacker managing to introduce a DNS entry (and TLS certificate) for an `xn--`-masked name that turns into the name of the target when processed by `idna` 0.5.0 or earlier.&lt;/p&gt;
&lt;p&gt;## Remedy&lt;/p&gt;
&lt;p&gt;Upgrade to `idna` 1.0.3 or later, if depending on `idna` directly, or to `url` 2.5.4 or later, if depending on `idna` via `url`. (This issue was fixed in `idna` 1.0.0, but versions earlier than 1.0.3 are not recommended for other reasons.)&lt;/p&gt;
&lt;p&gt;When upgrading, please take a moment to read about [alternative Unicode back ends for `idna`](https://docs.rs/crate/idna_adapter/latest).&lt;/p&gt;
&lt;p&gt;If you are using Rust earlier than 1.81 in combination with SQLx…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-h97m-ww89-6jmq</guid>
    </item>
  </channel>
</rss>
