Skip to content
Patch Next
Sign inAdd to your agent

← Public intelligence

Packagist package

symfony/polyfill-intl-idn

Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.

Open advisories

1 actionable advisory, newest first. Withdrawn advisories and news are excluded. Coverage is partial.

  1. Low, CVSS 2.7PackagistPublished

    symfony/polyfill-intl-idn: xn-- labels with ASCII-only Punycode payloads are treated as equivalent to their decoded form

    CVE-2026-46644 · GHSA-2xf4-cg6j-vhgq

    Affected
    • Packagist symfony/polyfill-intl-idn >= 1.17.1, < 1.38.1
    Fixed in
    1.38.1· Vendor fix available
    Issue
    symfony/polyfill-intl-idn provides a userland implementation of idntoutf8() and idntoascii() 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. 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's native ext-intl rejects them with IDNAERRORINVALIDACELABEL. 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). Example with IDNAUSESTD3RULES | IDNACHECKBIDI | IDNACHECKCONTEXTJ | IDNANONTRANSITIONALTOASCII: | Input | Polyfill output | Native ext-intl output | | ---…

    Recommended action: Upgrade to 1.38.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →