Upgrade the PHP runtime serving your website. Updating WordPress, Drupal or a plugin does not update PHP. Match your branch to the fixed release below, install your vendor's update, then restart the workers that serve web requests.
Last verified against php.net advisory: 2026-10-21
PHP2Shell patch versions by branch
| Branch | Fixed in | Notes |
|---|---|---|
| 8.6 | 8.6.0 RC4 | RC1 to RC3 are affected |
| 8.5 | 8.5.12 | |
| 8.4 | 8.4.27 | |
| 8.3 | 8.3.36 | Recommended upgrade target from 8.1 and older |
| 8.2 | 8.2.35 | Branch reaches end of life on 31 December 2026 |
| 8.1 and older | none | No official fix; some distributions ship backported builds |
These are upstream version thresholds, not a complete test of a distribution package. PHP 8.6 is a release candidate branch; do not move production sites onto an RC to fix this issue.
Before changing a production server
- Back up application files, database and PHP configuration. Check application compatibility with the intended PHP branch.
- Identify the site's PHP version and SAPI in the hosting panel.
php -vshows the command-line interpreter, which may differ from PHP-FPM or mod_php. - Use the same trusted package source or image family already serving the site. The examples below are for administrators with server access; shared-hosting customers should ask their host to update the per-domain runtime.
Debian and Ubuntu: apt package example
This example assumes PHP 8.3 FPM is already installed under these package names. Substitute the installed branch and include its installed extensions. It upgrades packages from your configured repositories; it does not guarantee that those repositories already contain the fix.
php -v sudo apt-get update apt-cache policy php8.3-fpm php8.3-cli php8.3-common sudo apt-get install --only-upgrade php8.3-fpm php8.3-cli php8.3-common sudo systemctl restart php8.3-fpm php -v
For Apache mod_php, update the installed libapache2-mod-php8.3 package as well and restart apache2. Confirm every site's configured runtime; multiple PHP branches can coexist.
Fedora and RHEL family: dnf package example
For installations using the standard php-* package names, inspect the installed packages and update them from your existing repositories. Alternate installations may use different package and service names; use your vendor's instructions.
rpm -qa 'php*' sudo dnf upgrade --refresh 'php*' # For sites served by PHP-FPM: sudo systemctl restart php-fpm php -v
If Apache uses mod_php, restart httpd. Do not switch module streams or add an unfamiliar repository just to make the version number match this table. Check the distribution's security notice for both CVEs.
Docker: replace the image and recreate the PHP service
In compose.yaml, update the PHP service's image tag to a fixed release in the same image family. For example, an existing official PHP 8.3 FPM service can use php:8.3.36-fpm or a later fixed 8.3 tag. Keep the variant, extensions and configuration your application needs. If your service is named php:
docker compose pull php docker compose up -d --no-deps php docker compose exec php php -v
Replace php with your actual service name. Pulling alone does not replace a running container. For a custom Dockerfile, update its base image and rebuild the service with docker compose build --pull php before recreating it. Preserve persistent data in volumes and check the application's health after replacement.
Distribution backports: an older version may include the fix
A vendor can apply a security fix without adopting the upstream patch number. A banner such as 8.3.6-1ubuntu1.2 alone cannot prove whether these CVEs are fixed. Look up CVE-2026-109618 and CVE-2026-109619 in your vendor's advisory, compare the complete installed package release with the fixed package, and confirm the running web workers use it.
The header checker compares advertised upstream versions. It does not inspect your installed package changelog or certify a backport. A hidden version also requires verification on the server.
Verify the update actually reached web requests
- Check the per-domain runtime and loaded SAPI, not just CLI output.
- Restart every affected PHP pool or container and, where applicable, Apache.
- Smoke-test login, forms and uploads, then run the PHP2Shell checker again. A CDN may still hide the runtime version.
- For a vendor backport, keep the advisory and installed package release as evidence.
If upgrading is temporarily blocked, the partial mitigation configuration generator covers one confirmed family of paths. It is not a complete fix.