Affected versions

Symfony versions <5.4.53, >=6, <6.4.41, >=7, <7.4.13, >=8, <8.0.13 of the Symfony Routing component are affected by this security issue.

The issue has been fixed in Symfony 5.4.53, 6.4.41, 7.4.13, 8.0.13.

Description

Symfony\Component\Routing\Generator\UrlGenerator::doGenerate() percent-encodes . and .. path segments so that the generated URL still resolves to the originating route after RFC 3986 §5.2.4 dot-segment removal (which strict RFC-3986 consumers, routers, reverse proxies, HTTP clients, perform before percent-decoding).

The encoding was implemented as strtr($url, ['/../' => '/%2E%2E/', '/./' => '/%2E/']) plus a trailing-segment fixup. strtr advances past the trailing / of each match, so the next dot-segment in a chained sequence was left unescaped:

1
2
3
4
Input                | Output (before fix)         | Expected
-------------------- | --------------------------- | --------------------------------
/../../../           | /%2E%2E/../%2E%2E/          | /%2E%2E/%2E%2E/%2E%2E/
/foo/../../../bar    | /foo/%2E%2E/../%2E%2E/bar   | /foo/%2E%2E/%2E%2E/%2E%2E/bar

When a route exposes a parameter constrained by a permissive requirement (.+, .*, or similar) that accepts dots and slashes, attacker-controlled chained .. or . segments produce a generated URL that, under strict RFC 3986 normalization, collapses to a different path than the originating route. The Twig path() / url() helpers and any server-side use of UrlGenerator are affected. Same class of route round-trip integrity issue as CVE-2026-45065.

Note: WHATWG-conformant browsers treat %2E/%2E%2E as dot-segments during URL parsing, so the encoding never protected browser-side traversal. The defense exists for RFC-3986-conformant consumers; restoring it for chained segments closes the gap there.

Resolution

UrlGenerator now matches every /. or /.. dot-segment in a single left-to-right preg_replace_callback pass using a lookahead that does not consume the trailing /, so adjacent dot-segments are encoded correctly.

The patches for this issue are available here for branch 5.4 (and forward-ported to 6.4, 7.4, 8.0 and 8.1).

Credits

We would like to thank alexpott for reporting the issue and Nicolas Grekas for providing the fix.