PHP2Shell and Symfony: What Developers Need to Do

As of 23 October 2026, PHP has fixed both PHP2Shell flaws in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. We found no PHP2Shell statement on the Symfony blog as of that date. Exploitation attempts are widely reported, but confirmed successful compromises are not publicly documented, and CISA has not added the flaws to its Known Exploited Vulnerabilities (KEV) catalog.

The direct answer: PHP2Shell (CVE-2026-109618 and CVE-2026-109619) is a flaw in the PHP engine, not in Symfony. Researchers at Calif confirmed that it could be used against Symfony 8.1, but the weakness sits below your code, in how PHP handles requests. Updating Symfony or running composer update does not fix it. A fixed PHP build on every server or image does, followed by a restart of every PHP process, including Messenger workers.

This guide covers which PHP each maintained Symfony branch needs, the special case of Symfony 6.4 LTS on PHP 8.1, Docker setups built on FrankenPHP, and long-running workers. For background, read what PHP2Shell is.

Is Symfony Affected by PHP2Shell?

Yes, through PHP. PHP describes the two flaws this way. CVE-2026-109618: out-of-memory handling "can interrupt PHP while internal request data is only partially initialized." CVE-2026-109619: request-owned internal state "can survive after its backing memory has been freed," so that a later request on the same worker may use it. Both happen in PHP's own request startup and cleanup, before or around your Symfony kernel.

Calif's write-up lists Symfony 8.1 among 11 PHP apps where it "confirmed pre-auth RCE," meaning it could run code on the server without logging in. Wiz, the other main research team, demonstrated attacks only against WordPress, Drupal and Joomla. Neither team named an older Symfony branch, but that is not a sign of safety. The flaw is in PHP, so any Symfony version on an unpatched PHP build is exposed.

The Dutch National Cyber Security Centre (NCSC-NL) keeps a public list of affected software. It marks the "Symfony framework" as Vulnerable and individual components such as HttpFoundation and HttpKernel as under investigation. The list itself warns that its entries "should still be treated as investigation leads until they are backed by an upstream or vendor source."

We checked the Symfony blog on 23 October 2026 and found no PHP2Shell post. If Symfony publishes guidance later, follow it.

Symfony Branches and the PHP They Need

From the Symfony releases page, as shown on 23 October 2026:

Symfony 7.3 and older are unmaintained. If you run one of those, patch PHP now and plan the framework upgrade separately. Don't combine a rushed framework upgrade with an emergency PHP fix if you can avoid it.

Symfony 6.4 LTS on PHP 8.1: The Gap to Close

Symfony 6.4 is still a maintained long-term support branch, and it runs on PHP 8.1. PHP 8.1 reached end of life on 31 December 2025. PHP's 21 October announcement says "PHP 8.1 and older no longer receive updates from the PHP project. Some distributions and LTS vendors provide backported fixes."

So a 6.4 app on PHP 8.1 is only safe if the PHP build under it carries a backport, for example from your Linux distribution's security updates. PHP also published minimal source-only backports for 7.4, 8.0 and 8.1 for people who build PHP themselves, but there are no official 8.1 releases or binaries. The official Docker php:8.1 image had not been rebuilt as of 23 October.

The practical route for most teams: move the 6.4 app to PHP 8.2 or newer, which Symfony 6.4 accepts. PHP 8.2 itself ends on 31 December 2026, so 8.3 or 8.4 buys more time. Test on staging first, because a PHP version jump can surface deprecation warnings and behavior changes in your own code. Our PHP 8.1 guide covers the backport options.

Who Patches PHP Under Your Symfony App

Symfony is a framework, so there is no vendor cloud that patches it for you by default. Who updates PHP depends on hosting:

• Your own VPS or dedicated server: you. Install the distribution's fixed PHP packages and restart PHP-FPM or Apache.
• Containers you build: you. Rebuild every image from a fixed base and redeploy. Google Cloud puts it plainly: "Container images you build yourself are your responsibility."
• A platform-as-a-service: usually the platform, for its built-in runtimes, but check. Some platforms patch in place and others need a redeploy.
• A managed agency or host: ask them in writing which PHP build now serves the app and when workers were restarted.

Our shared responsibility guide explains how to work out who owns which layer.

Symfony Docker and FrankenPHP

Many newer Symfony projects start from the Symfony Docker template, which its README describes as a runtime "with FrankenPHP and Caddy inside," using "the worker mode of FrankenPHP." FrankenPHP compiles PHP into its binary and images. You can't update PHP inside it with a package manager. You need a FrankenPHP image built with fixed PHP.

1. Check your Dockerfile's base image. The current template starts from dunglas/frankenphp:1-php8.5, a floating tag. Your project's copy may differ, depending on when it was created.
2. Rebuild with a fresh pull. The template's own instructions use docker compose build --pull --no-cache, which fetches the newest base image instead of a cached one.
3. Recreate the containers. Pulling or building alone leaves the old container running. docker compose up -d (or your orchestrator's rollout) replaces containers whose image changed.
4. Consider pinning. A tag naming both versions makes the PHP inside obvious. FrankenPHP 1.13.2 was the first release built with fixed PHP.

Restarting FrankenPHP workers through its admin API re-runs your app inside the same process, with the same built-in PHP. That's useful for new code, not new PHP. Our FrankenPHP guide covers every install method.

Messenger Workers and Other Long-Running Processes

A PHP process that is already running keeps the PHP it started with. In a Symfony app, the usual long-running processes are Messenger consumers (messenger:consume), FrankenPHP or other worker-mode runtimes, and any custom daemon commands.

The Messenger documentation describes php bin/console messenger:stop-workers: it "sets a cache flag that tells each worker to finish its current message and exit cleanly. The process manager then restarts them." After a PHP update, the new workers start on the new PHP. Two things to check:

• The docs note that if your app "runs on multiple hosts," the app cache must use a shared adapter so the stop signal reaches every worker.
• Make sure something restarts the workers: Supervisor, systemd or your container platform. Then confirm their start times are after the update.

For PHP-FPM, use a full restart rather than relying on a reload. Our guide to restarting PHP workers has the exact commands for each Linux distribution, Apache and containers.

Step by Step: What to Do Today

1. List every environment. Production, staging, preview and demo servers, plus any old instances still in DNS. Staging on a public URL is as reachable as production.
2. Find the PHP that serves each one. The command-line php -v can differ from the web server's PHP, so check what PHP-FPM or the container actually runs. Our PHP version guide explains the reliable ways.
3. Update or rebuild. Fixed releases are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. On distribution builds, confirm the fix in the package changelog, because backported packages keep their old version numbers.
4. Restart everything that runs PHP. PHP-FPM or Apache, Messenger workers, FrankenPHP processes and containers.
5. Verify. Recheck the serving PHP version or build, and confirm process start times.
6. Review logs from 17 October onward. Look for unusual multipart requests, memory-exhaustion errors and worker crashes.

What Updating Symfony or Composer Does Not Do

Keeping Symfony and its packages current matters for Symfony's own security fixes. It does nothing for PHP2Shell. A few related traps:

• Framework-level request limits run after PHP has already parsed the request, so they can't block a flaw in PHP's own parsing.
• Interim settings belong in php.ini or the FPM pool, not in ini_set() calls or .user.ini files, which PHP says don't work for these mitigations. PHP also says to remove invalid or deprecated per-request settings that produce warnings before a request starts. Our interim mitigations guide covers each setting.
• Your local machine is not production. The Symfony CLI docs say its local web server "is not intended for production use." Update your laptop's PHP when you can, but don't treat that as part of the server fix.

Keep session.upload_progress.enabled=0 after patching too, if you don't use PHP's built-in upload progress. PHP's 23 October advisory on a related issue, CVE-2026-115560, recommends it until the next regular PHP release.

Conclusion

For Symfony teams, PHP2Shell is a runtime job. Put every environment on a fixed PHP build, move Symfony 6.4 apps off PHP 8.1, rebuild FrankenPHP-based images with a fresh pull, and stop Messenger workers so they come back on the new PHP. Then verify the version the web server actually runs. Your Docker base images and Composer packages are part of your supply chain, so track their versions the way our supply chain security guide describes. If you'd like help patching and verifying several environments at once, our emergency PHP patching service can step in. Every PHP2Shell guide is in our PHP2Shell Resource Center.

Frequently Asked Questions