GHSA-h5x3-xfc9-m39h
Symfony: UrlGenerator Dot-Segment Encoding Skips Every Other Chained `../` or `./` → Generated URL Collapses Off-Route Under RFC 3986 Normalization
Blast Radius
symfony/routing🐘symfony/routing🐘symfony/routing🐘symfony/routing🐘symfony/symfony🐘symfony/symfony🐘symfony/symfony🐘symfony/symfonyReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.
Description
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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | symfony/routing | all versions | 5.4.53 |
| 🐘Packagist | symfony/routing | ≥ 6.0.0&&< 6.4.41 | 6.4.41 |
| 🐘Packagist | symfony/routing | ≥ 7.0.0&&< 7.4.13 | 7.4.13 |
| 🐘Packagist | symfony/routing | ≥ 8.0.0&&< 8.0.13 | 8.0.13 |
| 🐘Packagist | symfony/symfony | all versions | 5.4.53 |
| 🐘Packagist | symfony/symfony | ≥ 6.0.0&&< 6.4.41 | 6.4.41 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for symfony/routing. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update symfony/routing to 5.4.53 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-h5x3-xfc9-m39h is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-h5x3-xfc9-m39h is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-h5x3-xfc9-m39h. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-h5x3-xfc9-m39h in your dependencies?
O3 detects GHSA-h5x3-xfc9-m39h across Packagist dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.