Updated 21 October 2026. Emergency patches are available.
CVE-2026-109618 and CVE-2026-109619 are PHP runtime vulnerabilities that can allow unauthenticated remote code execution. The first fixed upstream releases are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. A vendor-confirmed backport is also a valid fix. Updating your application alone does not update its PHP runtime. PHP release guidance
Identify the runtime that serves real requests, update it, replace its old workers and check for compromise. PHP-FPM is affected too.
Identify every PHP version in use
A Forge server may have different versions for sites, the command line, queues and scheduled commands. Record each site's PHP setting and inspect its actual FPM configuration. Check worker commands and any manually installed runtimes as well; Forge's inventory does not include PHP installed outside its management.
Apply the patch through Forge
In Forge, open the server's Runtime → PHP, locate the branch, open its menu and choose Update. Repeat for each branch used by a site or worker. Confirm the resulting package version and that the relevant FPM workers have restarted.
Forge supports multiple PHP versions, each with a separate FPM process. Changing the default PHP version does not switch existing sites. Check site settings as well as the CLI default, queue processes and scheduled commands. Manually installed PHP may not appear in Forge's inventory. Forge PHP documentation
Save relevant configuration and ensure recoverable backups before the change. For a fleet, drain and patch one server, validate the application and then continue. Review the update result rather than treating a successful button click as proof that the fixed package was installed. If the action fails or the candidate is still vulnerable, inspect the repository and package status using the Linux guide.
Verify the package source
Forge servers commonly use the ondrej/php PPA. Confirm the installed and candidate versions with apt-cache policy for the relevant branch. The patch must come from that source; an Ubuntu security notice applies to Ubuntu packages, not automatically to a PPA build. Ubuntu may carry fixes in an older-looking base version such as 8.3.6-0ubuntu..., so verify the complete revision against the appropriate publisher's advisory. Do not add unfamiliar repositories during the incident.
Replace long running application processes
After updating PHP, ensure all FPM workers for every affected branch have restarted. Then restart applicable queue workers through your normal deployment or process-manager workflow. For Laravel queues, queue:restart requests a graceful exit; for Horizon, horizon:terminate allows the supervisor to start a fresh process. Check that the replacement processes really started with the corrected PHP executable, and investigate jobs that prevent old workers from exiting.
php artisan queue:restart
# For a Horizon-managed deployment instead:
php artisan horizon:terminateRun the appropriate command as the application's deployment user from its project directory, with the intended PHP binary. These commands are alternatives for the relevant process model, not substitutes for patching or restarting FPM. Forge queue documentation
Check Octane and FrankenPHP separately
If Octane uses FrankenPHP, updating system PHP does not update its embedded runtime. Replace or rebuild the FrankenPHP binary or image with fixed PHP, then restart the service that actually executes it and verify the deployed build. FrankenPHP is likely susceptible to application-independent attacks like mod_php.
For other persistent Octane runtimes, update the PHP executable used by the service and replace the existing processes through your process manager. A framework code reload is not proof that the executable in memory was replaced. Include scheduled commands and all other background processes in verification.
If the package update is delayed
See the main advisory for temporary controls separated by CVE. Apply early-request settings in the correct FPM or server configuration and restart every worker. Laravel maintenance mode still invokes PHP; to remove exposure, use a static frontend response or restrict access before PHP. The Linux guide includes a 503 example that also addresses direct PHP paths.
Verify the running application
Record the installed package revision or image digest and the advisory that confirms it is fixed. Check the web runtime through an authenticated internal diagnostic or the hosting control panel; do not expose a public phpinfo page. The default command-line PHP may be different.
Confirm that old workers have stopped. Test login, sessions, uploads, important transactions and background jobs. Check error rates and service health. Update the images and deployment templates used for new instances so the next deployment cannot restore vulnerable PHP. Keep a tested recovery plan, but do not return a vulnerable runtime to public service as a rollback.
Check for compromise before closing the incident
Preserve access, error, application and security logs, then review activity from 20 October 2026 onward. Look for unexpected PHP files, new administrator accounts, changed scheduled tasks, unusual outbound connections and web workers launching shell commands. Correlate findings with deployments and legitimate administrative work.
For a Linux webroot, this is a starting point, not a malware scanner:
sudo find /home/forge -type f -newermt "2026-10-20" -lsThe date is pinned to the leak date rather than a moving two-day window. Replace /home/forge with the actual application paths and account for the server timezone. Attackers can alter timestamps, so a clean result does not prove the server is clean. Compare with trusted deployment artifacts and review logs as well.
If you find suspicious activity, isolate the affected workload, preserve evidence and involve your incident responder. Restore or rebuild from trusted material and rotate exposed secrets from a clean environment. Patching alone does not remove a backdoor.
Get your PHP update completed
Send this guide to the person responsible for your server and ask for confirmation of the fixed runtime, completed worker restart and compromise review. If you need help, contact your hosting provider or development team with the package version, hosting platform and affected sites so they can act quickly.
Related guides
- Main PHP2Shell security advisory
- How to fix PHP on Ubuntu and Debian
- How to fix PHP on AWS EC2 ECS and EKS
- How to fix PHP on DigitalOcean
- How to fix PHP on Laravel Forge
- How to fix PHP on WordPress and shared hosting
