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:
| 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 Alex Pott for reporting the issue and Nicolas Grekas for providing the fix.
nicolas-grekas Remediation developer
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.strtradvances past the trailing/of each match, so the next dot-segment in a chained sequence was left unescaped:/../../..//%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/barWhen 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 Twigpath()/url()helpers and any server-side use ofUrlGeneratorare affected. Same class of route round-trip integrity issue as CVE-2026-45065.Note: WHATWG-conformant browsers treat
%2E/%2E%2Eas 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
UrlGeneratornow matches every/.or/..dot-segment in a single left-to-rightpreg_replace_callbackpass 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 Alex Pott for reporting the issue and Nicolas Grekas for providing the fix.