CVE-2026-48784

Updated on 15 Jun 2026

Severity

Awaiting Analysis

Details

Overview

About vulnerability

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

Symfony would like to thank Alex Pott for reporting the issue and Nicolas Grekas for providing the fix.

Details

Affected packages:
framework @ 5.4.36 (+14 more)

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

Symfony would like to thank Alex Pott for reporting the issue and Nicolas Grekas for providing the fix.