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.
Choose the procedure for your deployment
DigitalOcean hosts several different deployment models. A self-managed Droplet needs an operating-system update. App Platform needs a deployment containing a fixed runtime. Kubernetes workloads need corrected application images. Identify your model before starting.
Update a self managed Droplet
Inventory every web and worker Droplet, its PHP branches and its package source. Take a recoverable backup, preserve configuration and drain one instance if you run behind a load balancer. For Ubuntu or Debian, follow the linked Linux guide to inspect candidates, upgrade the installed PHP packages and extensions, validate configuration and restart the serving processes.
Many Ubuntu Droplets use the ondrej/php PPA. If that is your source, verify the PPA's corrected package rather than applying an Ubuntu base-version rule. Vendor backports can retain older upstream version strings; compare the complete package revision with its publisher's advisory. Do not add a new, unfamiliar repository simply to obtain an apparently higher version.
A restart without an installed fix leaves the runtime vulnerable. Verify the website's FPM socket, Apache module or container instead of relying only on php -v. Update the reusable image or provisioning configuration used to create new Droplets, and repeat for separate worker hosts.
Rebuild an App Platform application
App Platform can build PHP applications using a buildpack or a Dockerfile. Confirm that the selected buildpack offers a fixed runtime, or update the Docker image used by your application. Rebuild, deploy and verify the runtime in the resulting workload. A PHP constraint in composer.json expresses a requirement; it does not prove what an already-running deployment contains. DigitalOcean PHP buildpack documentation
For a buildpack deployment, check the build log and selected PHP version, then perform a rebuild using a fixed runtime offered by the platform. If no fixed runtime is available, contact support and restrict exposure until there is a supported path. A restart reuses the existing deployment; it is not a runtime rebuild.
For a Dockerfile deployment, update the base image or build inputs, rebuild and test the application, and deploy the new image. Confirm the fixed runtime in the running workload. Treat web services, workers and jobs as separate deployment targets. If you use FrankenPHP, replace its embedded PHP through a corrected binary or image.
Update DigitalOcean Kubernetes workloads
Build and push a corrected application image, change the image reference in your deployment source and roll out every PHP workload. Confirm the running image IDs and web runtime after the rollout. Include scheduled jobs and worker containers. Updating nodes alone does not patch PHP inside an application image; the AWS container guide also explains the same image-replacement principle.
If you cannot deploy the fix yet
Use the main advisory's CVE-specific temporary controls or a static maintenance response at the frontend. Check direct origin access as well as the public hostname. PHP-FPM and a WAF do not make an unpatched installation safe. The Linux guide includes a 503 maintenance example.
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 /var/www -type f -newermt "2026-10-20" -lsThe date is pinned to the leak date rather than a moving two-day window. Replace /var/www 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
