SYMFONY/FILESYSTEM · GHSA-6prc-h956-hxjq · Package
FIX → 8.1.11 · 7.4.23 · 6.4.50 · 5.4.56
The Symfony Filesystem Path helpers treat anything before the first "://" as a root, so ".." segments in that prefix are not resolved. An application that checks or opens user-built paths with isBasePath(), canonicalize() or similar can be made to read or write files outside its intended directory; AssetMapper can also be made to write files outside assets/vendor via a malicious remote package's CSS.
first public Nov 4, 2026 · 1 source
Could this affect your app?
Free first check from your website. Connect your repo for the full answer.
Applications that use symfony/filesystem or the full symfony/symfony framework and pass user-influenced paths into Path::isBasePath(), canonicalize(), join(), makeAbsolute() or makeRelative() before reading or writing files. On Symfony 6.4 and later, projects using AssetMapper with remote packages are also exposed to a malicious package writing outside assets/vendor. Projects that never build paths from untrusted input with these helpers are unlikely to be affected.
Most methods of Symfony\Component\Filesystem\Path rely on Path::split(), which takes everything before the first :// as the root of a path. It doesn't check that this prefix is a URI scheme, so the .. segments in that prefix are never resolved. PHP sees a scheme only at the start of a string. So /base/../x://../secret.txt is a plain local path to /secret.txt for PHP, while Path::isBasePath('/base', '/base/../x://../secret.txt') returns true. canonicalize(), join(), makeAbsolute() and makeRelative() are affected the same way.
Some applications check a path built from user input with isBasePath() or , and then open it. They can be made to read or write files outside the expected directory.
Check it with your coding agent
It reads this page and tells you if your code is affected.
Are you affected?
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
Not affected if auth-required, no-user-input-in-paths, static-paths-only
Who cares assetmapper, composer, php, symfony, symfony-filesystem
composer show symfony/filesystem and composer show symfony/symfony, and compare against the fixed versions below.Path::isBasePath, Path::canonicalize, Path::join or Path::makeAbsolute applied to user-supplied paths before a file is opened.importmap:require or importmap:install.Upgrade to 8.1.11 · 7.4.23 · 6.4.50 · 5.4.56
symfony/filesystem 5.4 branch: 5.4.56; 6.x: 6.4.50; 7.x: 7.4.23; 8.x: 8.1.11symfony/symfony 5.4 branch: 5.4.56; 6.x: 6.4.50; 7.x: 7.4.23; 8.x: 8.1.11canonicalize()On Symfony 6.4 and later, the AssetMapper component builds with Path::join() the path of the files that a remote package references from its CSS. A malicious or compromised package can therefore make importmap:require or importmap:install write a file of its choice outside assets/vendor. For example, the CSS url(../../../../../public/x://shell.php) writes public/x:/shell.php.
A prefix is now a scheme only when PHP would look for a stream wrapper with that name. That is two or more letters, digits, +, - or ., followed by :// at the start of the path. Other prefixes are regular path segments, and the .. segments after them are resolved. Real schemes such as phar://, file://, vfs:// or compress.zlib:// keep working.
The patch for this issue is available here for branch 5.4 (and forward-ported to 6.4, 7.4, 8.1 and 8.2).
We would like to thank Nicolas Grekas for reporting the issue and providing the fix.