PHP2Shell and Laravel: how to patch and what to rotate

Does PHP2Shell affect Laravel?

Every Laravel app runs on PHP, so if that PHP is vulnerable, the app is exposed — whatever Laravel version you run. Updating Laravel or Composer packages doesn’t help. You need to upgrade PHP itself.

1. Find the PHP that serves the app

php artisan about is handy, but it reports the command-line PHP. Your HTTP traffic is usually served by PHP-FPM, which can be a different version:

php artisan about | grep -i 'php version'   # CLI PHP
/usr/sbin/php-fpm8.3 -v                      # FPM PHP (Ubuntu / Forge / Ploi)

More options in how to check your PHP version.

2. Patch PHP for your setup

Laravel Forge, Ploi and similar panels

These panels provision Ubuntu servers, usually with PHP from Ondřej Surý’s repository. Update PHP from the server’s PHP settings in your panel if it offers a patch/update action, or SSH in and follow the Ubuntu guide. Make sure every PHP version installed on the server is updated, not only the default one.

Docker and Laravel Sail

Rebuild your images on a patched base and redeploy — see the Docker guide. For Sail, run sail build --no-cache and then sail up -d.

Serverless and managed platforms

On serverless or managed runtimes, the provider supplies PHP. Check their status page or changelog for a patched runtime and redeploy your app so it picks it up.

3. Restart everything that runs PHP

sudo systemctl restart php8.3-fpm

Laravel Octane (Swoole, RoadRunner or FrankenPHP) keeps workers alive between requests — exactly where CVE-2026-109619 is most relevant. After upgrading PHP, restart the Octane server process itself (via Supervisor, systemd or your container orchestrator); octane:reload alone reuses the same PHP binary.

Queue workers and the scheduler run on the CLI. They aren’t the main PHP2Shell concern, but restart them so they use the patched binary too:

php artisan queue:restart

4. Rotate secrets the app held in memory

PHP2Shell can expose memory from PHP workers, so assume anything in .env that the app loads could have leaked if you were exposed:

• Database, Redis, mail and third-party API credentials — rotate them and update .env.

• APP_KEY — rotate it gracefully. Since Laravel 11 you can move the old key into APP_PREVIOUS_KEYS so existing encrypted values and cookies can still be decrypted:

  # .env
  APP_KEY=base64:NEW_KEY_HERE
  APP_PREVIOUS_KEYS=base64:OLD_KEY_HERE

  Generate a new key with php artisan key:generate --show, set it as APP_KEY, then clear and rebuild caches with php artisan config:cache.

• Sessions — log everyone out by clearing your session store (for example, empty the sessions table or the Redis session database).

• Signing secrets for webhooks, JWT and OAuth clients.

5. Check for compromise

Look for files that shouldn’t be there (especially .php files under storage/ or public/), unexpected admin accounts, and the log patterns in our compromise checklist.

find public storage -name '*.php' -newermt '2026-10-17' -not -path 'public/index.php'

Need a hand with a production rollout? We can patch it for you.