Affected versions
Symfony Filesystem versions >=5.4.0, <5.4.56, >=6, <6.4.50, >=7, <7.4.23, >=8, <8.1.11 are affected by this security issue.
The issue has been fixed in Symfony Filesystem 5.4.56, 6.4.50, 7.4.23, 8.1.11.
Description
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 canonicalize(), and then open it. They can be made to read or write files outside the expected directory.
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.
Resolution
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).
Credits
We would like to thank Nicolas Grekas for reporting the issue and providing the fix.