In short: The Laravel vulnerability that many developers are searching for right now is PHP2Shell and sits in PHP itself. A Laravel update does not close it. What matters is patched PHP, the restart of all processes including queue workers and Octane, and a check of .env, storage and public.
What PHP2Shell means for Laravel applications
Laravel is the foundation of many in-house developments: customer portals, internal tools, booking systems, APIs for apps. According to the PHP team, the PHP flaws CVE-2026-109618 and CVE-2026-109619 allow remote code execution without authentication. How clean the Laravel code is plays no role here.
The operating modes PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed are affected. Laravel Octane can use FrankenPHP as its server; in that case PHP is part of the FrankenPHP binary or the container image and is updated together with it. What this looks like for FrankenPHP is described in Securing FrankenPHP.
Laravel vulnerability: checking the PHP version and processes
On the command line, php artisan about shows the PHP version, the Laravel version and important settings such as the environment and debug mode. That is, however, the version of the CLI PHP. Web requests are handled by PHP-FPM or Octane, and that can be a different version. If in doubt, have the operator confirm which package status is running on all paths.
Fixed upstream versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35; backports can carry older numbers. Which PHP versions your Laravel version supports can be found in the documentation on laravel.com.
After the update comes the part that is most often forgotten with Laravel: the long-running processes.
# Show versions and configuration
php artisan about
# Tell queue workers to exit after the current job
php artisan queue:restart
# Terminate Horizon so that the process manager restarts it
php artisan horizon:terminate
The workers only start again afterwards if a process manager such as Supervisor or systemd monitors them. Octane servers and containers must be restarted completely or rolled out with a new image. For container setups, Patching PHP in Docker containers applies.
Where Laravel applications are vulnerable
| Location | Content | What to check |
|---|---|---|
.env |
APP_KEY, database, mail, API keys |
Must never be retrievable via the web |
bootstrap/cache/config.php |
Cached configuration with secrets | Permissions, modification date |
public/ |
Document root with index.php |
Additional PHP files |
storage/app/public |
Uploads, reachable via public/storage |
No PHP files |
storage/logs/ |
laravel.log, often with request data |
Secure, not public |
vendor/ |
Composer packages | composer audit, compare with composer.lock |
The folder storage/app/public is reachable through a symbolic link at public/storage. A PHP file placed there can, depending on the server configuration, be executed directly. Block that at web server level.
APP_DEBUG must be set to false in production. An error page with debug output can reveal environment variables, paths and parts of the code, and makes every attacker's work easier.
Admin interfaces and packages as a risk
Laravel applications have no uniform admin interface. Often these are custom areas or packages such as Filament or Nova. Check who has admin rights, whether the login has a two-factor step and whether admin routes need to be reachable from outside. API tokens, for example from Sanctum or Passport, should also be revoked and reissued if you suspect an incident.
Also check whether development tools are reachable in production, such as debug bars, Telescope or test routes. They often show requests, queries and configuration and belong behind a login or removed from the production environment altogether.
Composer packages are the second big block. Every dependency brings its own code, and unmaintained packages later block PHP upgrades. composer audit shows known vulnerabilities but does not replace a review of your own code.
What a Laravel update can and cannot do
An update of Laravel or individual packages closes known flaws in that code. It does not patch PHP, does not restart workers, does not renew a leaked APP_KEY and does not remove files from storage or public. Whether something happened before the patch can only be clarified by reviewing logs, files and database.
For teams with a deployment pipeline, the following applies: the PHP update also belongs in the build environment and in the base images, otherwise the next deployment brings an old version back. Also check whether staging or review environments are publicly reachable. They often run with APP_DEBUG=true and real data and are easily overlooked during security updates.
How does PHP SOS help?
- We check the web, CLI and worker PHP of your Laravel application and support the orderly restart of all processes.
- We secure logs from 20 October 2026 onward, the database and the code state, and compare it with your repository.
- We check
.env, configuration cache,storage,public, admin accounts and API tokens. - For a deeper review of your own code, we arrange a security audit or penetration test through specialised partners.
Frequently asked questions
Do I need to update Laravel because of PHP2Shell?
A Laravel update does not close PHP2Shell, because the flaw is in the PHP interpreter. Keep Laravel up to date anyway. For PHP2Shell you need patched PHP and a restart of all PHP processes, including the workers.
Why is restarting PHP-FPM often not enough for Laravel?
Queue workers, Horizon, Octane and the scheduler run as their own PHP processes on the command line. They load PHP once at startup and then keep working with the old version in memory until they are restarted.
What should I do if the .env file may have leaked?
Then you should renew APP_KEY, the database password and all keys for external services. Note that a new APP_KEY ends existing sessions and makes data encrypted with the old key unreadable; plan this with your developers.