In short: Symfony security after PHP2Shell means: patch PHP, restart all processes including Messenger workers, and then check secrets, cache and profiler. The flaw is in PHP, not in Symfony; a Symfony update alone does not close it.
Why PHP2Shell affects every Symfony project
Symfony is the foundation of many business applications, APIs and portals, and it is also part of systems such as Shopware 6 and Contao. According to the PHP team, the PHP flaws CVE-2026-109618 and CVE-2026-109619 allow code execution without authentication. Whether the application is cleanly programmed plays no role here.
The PHP team rates the risk highest for mod_php, but PHP-FPM, php-cgi, FrankenPHP and LiteSpeed are also affected. Symfony projects that run via Symfony Runtime with FrankenPHP or other permanently running servers need a complete restart or a new image after the update.
Symfony security: checking the PHP version and processes
php bin/console about shows the Symfony version, environment, debug mode and the PHP version of the command line. Web requests, however, run through PHP-FPM or an application server, and that can be a different version. Check both paths or have the operator confirm them.
Fixed upstream versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35; distribution backports often carry older numbers. Which PHP versions your Symfony version supports can be found in the system requirements in the documentation on symfony.com.
# Show environment, debug mode and PHP version
php bin/console about
# Have Messenger workers exit after the current message
php bin/console messenger:stop-workers
# Known vulnerabilities in dependencies
composer audit
If several instances run behind a load balancer or in containers, every single one must be patched and restarted. A forgotten instance keeps serving part of the requests with old PHP.
Messenger workers, cron commands and other background processes load PHP once at startup. Until they are restarted, they run with the old PHP in memory. A process manager must bring them back up after the stop.
Where Symfony applications are vulnerable
| Location | Content | What to check |
|---|---|---|
.env, .env.local, .env.local.php |
Environment variables, often database and API keys | Not retrievable from the web root, renew values if you suspect an incident |
config/secrets/prod/ |
Encrypted secrets | The private decryption key does not belong in the repository |
public/ |
Document root with index.php |
Additional PHP files |
var/cache/prod/ |
Generated container and templates as PHP | Delete and regenerate if you suspect an incident |
var/log/ |
Logs | Secure them |
config/packages/security.yaml |
Firewalls, roles, access rules | Unexpected changes |
The cache is an underestimated hiding place. Symfony generates PHP files there that are loaded on every request. A change to these files does not show up in the repository, because the cache is not versioned.
In production, APP_ENV=prod and APP_DEBUG=0 must be set, and the WebProfilerBundle must not be active. A publicly reachable profiler at /_profiler reveals configuration and request data.
Admin areas, bundles and dependencies
Depending on their structure, Symfony projects have their own admin areas, often with bundles such as EasyAdmin or Sonata. In security.yaml, check which paths require which roles, and in the database who holds these roles. Admin paths that are only needed internally should be restricted to known networks at web server level.
Bundles and Composer packages are third-party code with their own flaws. composer audit shows known problems; more detail is under Checking Composer dependencies for vulnerabilities. Outdated packages are also the most common reason why a PHP upgrade in Symfony projects takes longer than planned.
What a Symfony update achieves and what it does not
An update of Symfony components closes flaws in the framework. It does not patch PHP, does not restart workers, does not renew leaked secrets and does not remove a manipulated cache. Signs of an attack are described in Have I already been compromised?. Since there are no confirmed indicators of compromise, the main help is observing unusual behaviour, such as unexpected processes or outbound connections.
If the project is delivered as a container, the new PHP belongs in the base image. Rebuild the image even if nothing has changed in the code, and roll it out in all environments. A look at the Dockerfile shows which base image is used; a pinned old tag would otherwise prevent the rebuild from receiving the patched PHP at all. Details are under Patching PHP in Docker containers.
How does PHP SOS help?
- We establish which PHP the web, CLI and workers of your Symfony project use, and support the orderly restart.
- We secure logs from 20 October 2026 onward and compare the code on the server with your repository.
- We check environment files, secrets, cache, profiler settings and admin roles.
- For ongoing monitoring of processes and connections, we offer security monitoring.
Frequently asked questions
Is Symfony affected by PHP2Shell?
Symfony itself has no new flaw. PHP2Shell sits in PHP, the runtime environment of every Symfony application. The flaw is closed by a PHP update or a confirmed backport and a restart of all PHP processes.
How do I stop Messenger workers after a PHP update?
php bin/console messenger:stop-workers tells running workers to exit after the current message. A process manager such as Supervisor or systemd then restarts them with the new PHP.
Why is the Symfony profiler dangerous in production?
The profiler shows requests, configuration and often environment variables. If it is active on a public server, anyone can retrieve this information. It belongs only in the development environment.
What happens to the cache after an attack?
The cache under var/cache contains generated PHP code. An attacker can store code there that runs along with every request. If you suspect an incident, the cache should be deleted and regenerated from the verified source code.