How to fix PHP on Ubuntu and Debian

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.

Inventory and prepare the update

Start with an inventory of public websites, internal services, workers, containers and vendor appliances. Record the owner, host, operating system, PHP package source and runtime for each application.

On a Linux server, these inspection commands provide a starting point:

php -v
php --ini
command -v php
systemctl list-units --type=service --all 'php*-fpm.service'

The first three inspect the default command-line PHP. They do not prove which PHP serves a website. Check the site's configured FPM socket or upstream, Apache module, container image, or hosting runtime setting. Inspect every active branch. Where necessary, use an authenticated internal diagnostic that returns only the runtime version; remove it afterward. Avoid publishing a full phpinfo() page.

Check where your packages come from

Forge and many Ubuntu servers hosted on DigitalOcean use the ondrej/php PPA. For these installations, the corrected package must come from that configured publisher; an Ubuntu security notice does not establish the status of a PPA package. Debian systems may use the separate packages.sury.org repository rather than an Ubuntu PPA. Do not add an unfamiliar repository during an emergency.

Ubuntu and Debian can backport fixes while retaining an older upstream version string. An 8.3.6-0ubuntu... package is not automatically vulnerable or automatically fixed: compare its complete revision and OS release with the vendor security record for both CVEs. Inspect apt-cache policy output to distinguish installed and candidate versions and their origin. Check package holds and mirror availability if the fix is missing.

Install the confirmed fixed packages

Before changing packages, confirm a recoverable backup, save relevant configuration, and test the update on a representative instance. For a fleet, drain and update one instance first, then roll through the remaining instances after health checks.

Inspect installed packages and available candidates:

dpkg-query -W 'php*' 'libapache2-mod-php*'
sudo apt-get update
apt-cache policy php8.3-fpm php8.3-cli php8.3-common

The following example is for an existing PHP 8.3 FPM installation. Substitute the packages actually installed on your server and include its installed PHP extensions. First review the simulated transaction:

sudo apt-get -s install --only-upgrade php8.3-fpm php8.3-cli php8.3-common

Only proceed once the candidate is confirmed fixed by its publisher and the transaction is appropriate:

sudo apt-get install --only-upgrade php8.3-fpm php8.3-cli php8.3-common
sudo systemctl restart php8.3-fpm
sudo systemctl status php8.3-fpm --no-pager

Repeat for every active branch and its extensions. An Apache mod_php installation needs its module package updated and Apache restarted. Restart relevant long-running PHP application processes through their process manager. Plan for interrupted requests when restarting services.

An empty upgrade list is not proof of remediation: a mirror may lag, a package may be held, or the configured repository may not yet provide the fix. For RPM-based systems, use your distribution's advisory and package tools; the Ubuntu commands above do not apply. Source-built PHP requires rebuilding and deploying the corrected runtime through your existing build process.

For mod_php, use the installed branch's libapache2-mod-php package and matching PHP packages. Run apache2ctl configtest before restarting apache2. For FPM, validate the selected branch's configuration, for example sudo php-fpm8.3 -t, before the restart. Restarting Apache or FPM can interrupt requests; drain the instance first when a load balancer is available.

If a fixed package is not available yet

Restrict access while your existing repository publishes a corrected candidate. The main advisory explains temporary controls separately for each CVE. Do not mistake disabling upload progress, changing memory limits or adding a WAF rule for a complete patch.

Serve maintenance without invoking PHP

For Nginx, adapt the following within the affected server block and provide a readable static maintenance.html under its configured document root:

location / { return 503; } 
error_page 503 /maintenance.html; 
location = /maintenance.html { 
    internal; 
    add_header Retry-After 3600 always; 
}

Preserve TLS listeners and other server blocks. Disable or override every PHP or FastCGI route in this affected server block while maintenance is active: a regex PHP location can otherwise take precedence over location /. Check alternate paths, domains and direct origin access too. Validate with nginx -t, reload Nginx and confirm that both normal URLs and direct PHP URLs return 503 without reaching PHP. A response of 200 would incorrectly present the maintenance page as normal content.

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" -ls

The 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 and vendor records

• 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
• Ubuntu first CVE record
• Ubuntu second CVE record
• Debian first CVE tracker
• Debian second CVE tracker