A crafted link to your app can make the page it opens point its links, form actions, redirects and assets at another host. A login form could then send a user's password to the attacker, or the page could load the attacker's scripts. The attacker needs the user to follow that link.
Request::getBaseUrl() could take a host from the start of the request path when building the base URL.
Apps on symfony/http-foundation (also part of symfony/symfony) whose front controller sits in a subdirectory, with a web server that sends it paths that don't start with that directory. A root .htaccess that rewrites every URL to public/ does that. The Symfony advisory also lists servers that set SCRIPT_NAME to the request path, such as some nginx setups without fastcgi_split_path_info, and php -S with a router script outside the document root.
framework.trusted_hosts doesn't help. The server setups recommended in Symfony's docs aren't affected.
Update to 5.4.56, 6.4.50, 7.4.23 or 8.1.11. If you're on 8.0, update to 8.1.11. The fix returns an empty base URL for these requests, so generated URLs stay on your host.
Reported by Nicolas Grekas.
Check your app with an agent
Paste this into a coding agent that can read your project, such as Claude Code, Codex or Amp. It checks your composer.lock against the versions above and tells you what to update, without changing anything.
Check whether the PHP project you have access to is affected by this security advisory, and tell me what to update. Do a read-only check: don't edit files, don't run composer update or composer require, and don't try to reproduce the flaw.
Advisory: Symfony HttpFoundation: Crafted Links Make Generated URLs Point Elsewhere (PKSA-B2GG-VK1G-6D5Q)
Details: https://phpnews.net/security/symfony/pksa-b2gg-vk1g-6d5q
Affected versions, as Composer constraints:
- symfony/http-foundation, symfony/symfony: >=2.0.0,<2.1.0|>=2.1.0,<2.2.0|>=2.2.0,<2.3.0|>=2.3.0,<2.4.0|>=2.4.0,<2.5.0|>=2.5.0,<2.6.0|>=2.6.0,<2.7.0|>=2.7.0,<2.8.0|>=2.8.0,<3.0.0|>=3.0.0,<3.1.0|>=3.1.0,<3.2.0|>=3.2.0,<3.3.0|>=3.3.0,<3.4.0|>=3.4.0,<4.0.0|>=4.0.0,<4.1.0|>=4.1.0,<4.2.0|>=4.2.0,<4.3.0|>=4.3.0,<4.4.0|>=4.4.0,<5.0.0|>=5.0.0,<5.1.0|>=5.1.0,<5.2.0|>=5.2.0,<5.3.0|>=5.3.0,<5.4.0|>=5.4.0,<5.4.56|>=6.0.0,<6.1.0|>=6.1.0,<6.2.0|>=6.2.0,<6.3.0|>=6.3.0,<6.4.0|>=6.4.0,<6.4.50|>=7.0.0,<7.1.0|>=7.1.0,<7.2.0|>=7.2.0,<7.3.0|>=7.3.0,<7.4.0|>=7.4.0,<7.4.23|>=8.0.0,<8.1.0|>=8.1.0,<8.1.11
Fixed releases on branches that still get security fixes:
- 8.1.0 – 8.1.10: update to 8.1.11
- 7.4.0 – 7.4.22: update to 7.4.23
- 6.4.0 – 6.4.49: update to 6.4.50
- 5.4.0 – 5.4.55: update to 5.4.56
1. Find every composer.lock in the project outside vendor/ (a monorepo can have one per app) and read the installed version of each package above. Packages installed as dependencies of other packages count too.
2. Compare each installed version with its constraint: "|" separates alternative ranges, and "," means both bounds apply.
3. For each affected install, read "What this means" at https://phpnews.net/security/symfony/pksa-b2gg-vk1g-6d5q and check whether the project meets the conditions it describes (a feature in use, a config value, a driver). Say which conditions you could check and which you couldn't.
4. Report a table: lock file | package | installed version | affected (yes, no or unknown) | conditions met (yes, no or unknown) | update to | evidence. For each affected package, give the command that would fix it, without running it: composer update <package> --with-dependencies when it is only installed as a dependency of another package, or composer require with the fixed version when composer.json requires it directly. If the installed version is on a branch with no fixed release listed, say it needs a move to a newer branch.
