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
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.