<?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>Tue, 06 Oct 2026 06:00:28 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-337876</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-337876</link>
      <description>EUVD-2026-337876</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-337876</guid>
    </item>
    <item>
      <title>fkie_cve-2026-46644</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-46644</link>
      <description>&lt;p&gt;Symfony Polyfill backports PHP features and provides compatibility layers for extensions and functions. From 1.17.1 until 1.38.1, symfony/polyfill-intl-idn accepts xn-- labels whose Punycode payload is empty or decodes to ASCII-only code points because Idn::process() does not enforce the UTS #46 revision 33 requirement that decoded ACE labels contain at least one non-ASCII code point. Originally unequal domain names can be regarded as equal, which can lead to blacklist bypassing, inconsistent URL parsing, and server-side request forgery in applications using the polyfill to canonicalise or compare hostnames. This issue is fixed in version 1.38.1.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Symfony Polyfill backports PHP features and provides compatibility layers for extensions and functions. From 1.17.1 until 1.38.1, symfony/polyfill-intl-idn accepts xn-- labels whose Punycode payload is empty or decodes to ASCII-only code points because Idn::process() does not enforce the UTS #46 revision 33 requirement that decoded ACE labels contain at least one non-ASCII code point. Originally unequal domain names can be regarded as equal, which can lead to blacklist bypassing, inconsistent URL parsing, and server-side request forgery in applications using the polyfill to canonicalise or compare hostnames. This issue is fixed in version 1.38.1.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-46644</guid>
    </item>
    <item>
      <title>GHSA-2xf4-cg6j-vhgq — symfony/polyfill-intl-idn: xn-- labels with ASCII-only Punycode payloads are treated as equivalent to their decoded form</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-2xf4-cg6j-vhgq</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Packagist: symfony/polyfill, Packagist: symfony/polyfill-intl-idn&lt;/p&gt;
&lt;p&gt;### Description&lt;/p&gt;
&lt;p&gt;`symfony/polyfill-intl-idn` provides a userland implementation of `idn_to_utf8()` and `idn_to_ascii()` for runtimes that lack the `intl` extension. Its `Idn::process()` method decodes labels prefixed with `xn--` using Punycode but never enforces the validity criterion added in UTS #46 revision 33 Section 4 step 4.1.2: after a successful Punycode decode, the result must contain at least one non-ASCII code point.&lt;/p&gt;
&lt;p&gt;As a consequence, `xn--` labels whose Punycode payload is empty (`xn--`) or decodes to a string made of only ASCII code points (e.g. `xn--kc1zs4-`) are accepted by the polyfill while PHP&amp;#39;s native `ext-intl` rejects them with `IDNA_ERROR_INVALID_ACE_LABEL`. Originally unequal domain names are therefore regarded as equal, which can lead to blacklist bypassing, inconsistent URL parsing and server-side request forgery (similar to CVE-2024-12224).&lt;/p&gt;
&lt;p&gt;Example with `IDNA_USE_STD3_RULES | IDNA_CHECK_BIDI | IDNA_CHECK_CONTEXTJ | IDNA_NONTRANSITIONAL_TO_ASCII`:&lt;/p&gt;
&lt;p&gt;| Input | Polyfill output | Native `ext-intl` output |
| --- | --- | --- |
| `poc.xn--kc1zs4-.com` | `poc.kc1zs4.com` | `false` (`errors=1024`) |
| `poc.kc1zs4.xn--` | `poc.kc1zs4.` | `false` (`errors=1024`) |&lt;/p&gt;
&lt;p&gt;Applications using the polyfill to canonicalise or compare hostnames inherit the inconsistency.&lt;/p&gt;
&lt;p&gt;### Resolution&lt;/p&gt;
&lt;p&gt;`Idn::process()` now records `IDNA_ERROR_INVALID_ACE_LABEL` when a Punycode payload decodes to an empty string or to a string containing only ASCII code points, matching the native `ext…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Packagist: symfony/polyfill, Packagist: symfony/polyfill-intl-idn&lt;/p&gt;
&lt;p&gt;### Description&lt;/p&gt;
&lt;p&gt;`symfony/polyfill-intl-idn` provides a userland implementation of `idn_to_utf8()` and `idn_to_ascii()` for runtimes that lack the `intl` extension. Its `Idn::process()` method decodes labels prefixed with `xn--` using Punycode but never enforces the validity criterion added in UTS #46 revision 33 Section 4 step 4.1.2: after a successful Punycode decode, the result must contain at least one non-ASCII code point.&lt;/p&gt;
&lt;p&gt;As a consequence, `xn--` labels whose Punycode payload is empty (`xn--`) or decodes to a string made of only ASCII code points (e.g. `xn--kc1zs4-`) are accepted by the polyfill while PHP&amp;#39;s native `ext-intl` rejects them with `IDNA_ERROR_INVALID_ACE_LABEL`. Originally unequal domain names are therefore regarded as equal, which can lead to blacklist bypassing, inconsistent URL parsing and server-side request forgery (similar to CVE-2024-12224).&lt;/p&gt;
&lt;p&gt;Example with `IDNA_USE_STD3_RULES | IDNA_CHECK_BIDI | IDNA_CHECK_CONTEXTJ | IDNA_NONTRANSITIONAL_TO_ASCII`:&lt;/p&gt;
&lt;p&gt;| Input | Polyfill output | Native `ext-intl` output |
| --- | --- | --- |
| `poc.xn--kc1zs4-.com` | `poc.kc1zs4.com` | `false` (`errors=1024`) |
| `poc.kc1zs4.xn--` | `poc.kc1zs4.` | `false` (`errors=1024`) |&lt;/p&gt;
&lt;p&gt;Applications using the polyfill to canonicalise or compare hostnames inherit the inconsistency.&lt;/p&gt;
&lt;p&gt;### Resolution&lt;/p&gt;
&lt;p&gt;`Idn::process()` now records `IDNA_ERROR_INVALID_ACE_LABEL` when a Punycode payload decodes to an empty string or to a string containing only ASCII code points, matching the native `ext…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-2xf4-cg6j-vhgq</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-46644</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-46644</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:18.04:LTS: php-symfony-polyfill, Ubuntu:22.04:LTS: php-symfony-polyfill, Ubuntu:24.04:LTS: php-symfony-polyfill, Ubuntu:25.10: php-symfony-polyfill, Ubuntu:26.04:LTS: php-symfony-polyfill&lt;/p&gt;
&lt;p&gt;Symfony Polyfill backports PHP features and provides compatibility layers for extensions and functions. From 1.17.1 until 1.38.1, symfony/polyfill-intl-idn accepts xn-- labels whose Punycode payload is empty or decodes to ASCII-only code points because Idn::process() does not enforce the UTS #46 revision 33 requirement that decoded ACE labels contain at least one non-ASCII code point. Originally unequal domain names can be regarded as equal, which can lead to blacklist bypassing, inconsistent URL parsing, and server-side request forgery in applications using the polyfill to canonicalise or compare hostnames. This issue is fixed in version 1.38.1.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:18.04:LTS: php-symfony-polyfill, Ubuntu:22.04:LTS: php-symfony-polyfill, Ubuntu:24.04:LTS: php-symfony-polyfill, Ubuntu:25.10: php-symfony-polyfill, Ubuntu:26.04:LTS: php-symfony-polyfill&lt;/p&gt;
&lt;p&gt;Symfony Polyfill backports PHP features and provides compatibility layers for extensions and functions. From 1.17.1 until 1.38.1, symfony/polyfill-intl-idn accepts xn-- labels whose Punycode payload is empty or decodes to ASCII-only code points because Idn::process() does not enforce the UTS #46 revision 33 requirement that decoded ACE labels contain at least one non-ASCII code point. Originally unequal domain names can be regarded as equal, which can lead to blacklist bypassing, inconsistent URL parsing, and server-side request forgery in applications using the polyfill to canonicalise or compare hostnames. This issue is fixed in version 1.38.1.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-46644</guid>
    </item>
  </channel>
</rss>
