PHP2Shell and Laravel: Forge, Vapor, Cloud and Octane

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, and Laravel's own response post was last updated on 23 October at 08:31 UTC. 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 PHP itself, not in the Laravel framework. What you have to do depends on where your app runs. Laravel Cloud patched every running app for you. On Forge, you must click "Update PHP" on each server. On Vapor, you must redeploy. If you use Octane with FrankenPHP, updating the server's PHP does not patch Octane at all, because FrankenPHP carries its own copy of PHP.

This guide covers each product in turn, plus the queue workers that keep old PHP in memory. For background, see what PHP2Shell is.

Is Laravel Affected by PHP2Shell?

Every Laravel app is exposed while its PHP build is unpatched. Laravel's post, "PHP critical vulnerability response updates", calls these "extremely serious vulnerabilities affecting every PHP application on the web." The post covers Laravel's hosting products; it announces no framework release, because the bug isn't in framework code.

Calif lists "Laravel 13.11" among the PHP apps where it "confirmed pre-auth RCE," meaning an attacker could run code on the server without logging in. That doesn't make other Laravel versions safer. The weakness sits below your code, in PHP's request handling, which is also why composer update won't help: it changes your packages, not the PHP binary that runs them.

Laravel PHP Support by Version

Your Laravel version decides which PHP you can move to. From the Laravel release notes:

PHP 8.1 and older no longer get releases from the PHP project; only some distributions and LTS vendors ship backported fixes. PHP 8.2 reaches end of life on 31 December 2026, so 8.3 or newer is the better target for any upgrade.

Who Patches PHP for Your Laravel App

This split of duties is the shared responsibility model, which our guide to who secures what explains in general terms.

Laravel Forge: Update Every Server Yourself

Forge sets up and manages servers for you, but it does not own their PHP updates. Its security advisory is blunt: "Laravel Forge's automatic security updates do not patch PHP." Forge installs PHP from a separate package repository that Ubuntu's unattended upgrades don't cover.

1. Open each server in Forge and click the PHP tab.
2. Update every installed PHP version. Open the version's dropdown and click Update PHP X.X. Forge says to repeat this "for every PHP version installed on the server, including versions that your sites do not currently use."
3. Expect a brief blip. Forge says sites "may experience a few seconds of downtime" while PHP-FPM restarts.
4. If the button fails, use SSH. The advisory's SSH steps confirm the candidate version with apt-cache policy php8.4-fpm (replace 8.4 with your version) before upgrading.
5. Restart long-running processes. See the queue workers section below.
6. Verify. Over SSH, run php8.4 -v and php-fpm8.4 -v (again, use your version number). FPM should report a fixed release.

Ubuntu 20.04 or older: Laravel says "you will not be able to update PHP. Create a new server on a supported Ubuntu version and move your sites to it. Until you do, we recommend powering down the old server."

PHP 8.1 and older on Forge: Laravel's own pages disagree. The blog says patched builds are available "for every PHP version on Forge, from PHP 5.6 to 8.5." The Forge advisory's table says 8.1 and earlier are "Not patched" and that "servers running these versions will remain vulnerable." A backported fix keeps the old version number, so php -v can't settle it. Follow the advisory and switch those sites to a supported PHP version; until then, treat them as exposed.

The Forge blog also reminds you: "If your servers run Node.js, remember to update it yourself on each server."

Laravel Vapor: Redeploy to Get the Fix

Vapor is Laravel's serverless hosting platform, and Laravel builds the PHP runtimes it uses. Laravel says "The patched PHP runtimes from the security release are now live on Vapor," but they only reach your app when you deploy:

• Native runtime on PHP 8.2 or later: "you will need to redeploy them to get on the patched secure PHP version."
• Custom or Docker image runtime: "you will need a new deployment, not just a redeploy." Rebuild the image from a fixed PHP base.
• PHP 8.0 or 8.1: "no patch is available. Upgrade to PHP 8.2 or later as soon as possible."

Redeploy every environment, including staging.

Laravel Octane: FrankenPHP Brings Its Own PHP

Octane keeps your app in memory using FrankenPHP, Swoole or RoadRunner, and the server you picked decides how you patch.

Octane with FrankenPHP

The Octane documentation says: "The FrankenPHP static binary includes its own copy of PHP, so updating your system's PHP installation will not update the PHP version used by Octane." The steps it gives:

1. Check the bundled version with ./frankenphp version from your project root.
2. Delete the frankenphp binary from the project root.
3. Run php artisan octane:install --server=frankenphp "to download the latest release."
4. Restart Octane.

If FrankenPHP is installed system-wide rather than in your project, the docs say to "update it using the method you used to install it." FrankenPHP 1.13.2 (21 October 2026) was the first release built with fixed PHP. Our FrankenPHP guide covers Docker images, packages and worker mode in detail.

Octane with Swoole or RoadRunner

Swoole is a PHP extension, and Octane starts RoadRunner workers with the system's PHP command line. Both use the server's installed PHP, so the fix comes from updating that PHP and then restarting Octane.

Reload or restart?

The Octane docs describe php artisan octane:reload as the command to run "after deployment so that your newly deployed code is loaded into memory." Forge's advisory also lists it after a PHP update. Our conservative advice, not a Laravel statement: after a PHP update, fully stop Octane with php artisan octane:stop and let Supervisor or your process manager start it fresh. For FrankenPHP, replace the binary first; a reload can't swap the PHP compiled into a running binary.

Queue Workers, Horizon, Reverb and Other Long-Running Processes

Forge's advisory warns that "long-running PHP processes started from the CLI keep running the old version of PHP until they are restarted," naming queue workers, Horizon, Octane and Reverb. Its examples, run in each app:

php artisan queue:restart
php artisan horizon:terminate
php artisan octane:reload

Your process manager then starts fresh workers on the new PHP. Confirm their start times are after the update. For every setup, including plain PHP-FPM and containers, see our guide to restarting PHP workers.

If You Can't Patch Today, and After You Do

Updating PHP is the only complete fix. Until then, PHP's interim settings, such as session.upload_progress.enabled=0, block specific attack paths. They must go in php.ini, the FPM pool or server configuration, followed by a worker restart; PHP says ini_set() and .user.ini don't work, and a Laravel config or .env value won't either. Keep upload progress off after patching too, if you don't use it: PHP recommends this until its next regular release because of a related issue, CVE-2026-115560. Our interim mitigations guide lists each setting and what it can break.

CISA's advice for anyone who can't update, or who runs PHP 8.1 or older, is to "take PHP-based systems offline until they can be patched or updated." Beazley Security advises using "a maintenance response or network restriction rather than disabling the PHP handler, which can expose application source code and credentials."

Patching doesn't undo an attack that already happened. Wiz warns that leaked memory "may contain passwords, authentication tokens, API keys and certificates," and a Laravel app loads its database password and API keys from .env. Review logs from at least 17 October, the earliest reported exploitation attempt, for unusual multipart POST requests, memory-exhaustion errors and new PHP files. If you find signs of compromise, rotate those secrets with your developer. Our compromise check guide walks through the review, and our supply chain security guide covers the packages your app depends on.

Conclusion

For Laravel, your host decides the job. Cloud is covered. On Forge, update every PHP version on every server and replace Ubuntu 20.04 or older. On Vapor, redeploy and leave PHP 8.0 and 8.1. On Octane with FrankenPHP, replace the binary. Then restart every worker and confirm the version the web server actually runs. Running Symfony apps too? See our Symfony guide. To have a team patch and verify your Forge servers or Vapor environments, our emergency PHP patching service can help. Every PHP2Shell guide is in our PHP2Shell Resource Center.

Frequently Asked Questions