PHP2Shell is a pair of critical flaws in the PHP engine (CVE-2026-109618 and CVE-2026-109619) that let attackers take over a web server with a single request. If you missed the background, read what PHP2Shell is and who is affected. This guide is about one thing: fixing it.
The short answer: update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or later), restart every PHP worker, and rebuild your containers. On PHP 8.1 or older, there is no official binary fix, so upgrade now.
How to fix PHP2Shell in 5 steps
The only complete fix is updating PHP. Configuration changes and firewalls only reduce risk. Follow these steps in order.
Step 1: Find every PHP installation
You can't patch what you don't know about. Check every server, container image, CI runner, staging box and client site:
php -vshows the command-line versionphp-fpm8.3 -vshows the FPM version (repeat for each version installed)ls /etc/php/lists every PHP version installed on Debian and Ubuntudocker images | grep -i phplists PHP container images
The command-line PHP and the PHP your web server uses are often different binaries. Always check the web runtime too (see the verification section below).
Step 2: Update PHP to a patched release
Target PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or any later release. Exact commands for your platform are in the next section.
Step 3: Restart every PHP worker
Installing a new package does nothing to processes already running. Old workers keep serving vulnerable code until restarted.
sudo systemctl restart php8.3-fpm(repeat for every FPM version)sudo systemctl restart apache2if you use mod_php (httpd on RHEL)sudo systemctl restart lswsif you use LiteSpeed
Step 4: Rebuild and redeploy containers
A running container never changes when its image tag does. Pull the patched base image, rebuild without cache, and redeploy every service.
Step 5: Upgrade off end-of-life PHP
PHP 8.1 and older get no official binary fix. In order of preference: upgrade to PHP 8.3 or 8.4, use your distribution or LTS vendor's backport, or build from source with the PHP team's 7.4, 8.0 and 8.1 backport patches. Treat this as urgent, not a "next quarter" project. Stuck on legacy code that won't run on PHP 8? Our application modernization team handles exactly this.
PHP2Shell fix by platform
Ubuntu and Debian (apt)
sudo apt updatesudo apt install --only-upgrade 'php8.3*'(change 8.3 to your version)sudo systemctl restart php8.3-fpm
Using Ondřej Surý's PPA or packages.sury.org? The same commands apply once the updated packages land in that repository.
RHEL, AlmaLinux, Rocky Linux and CentOS Stream (dnf)
sudo dnf upgrade 'php*'sudo systemctl restart php-fpm httpd
If you use the volunteer-run Remi repository, it was not expected to have same-day updates. Switch to your distribution's packages or build from source if Remi hasn't published the fix yet.
Docker and Kubernetes
Pin your Dockerfile to an exact patched tag, for example (or 8.4.27-fpm, 8.5.12-fpm, 8.2.35-fpm), then rebuild and redeploy:
docker build --pull --no-cache -t your-app:patched .docker compose up -d --force-recreatefor Docker Composekubectl rollout restart deployment/your-appfor Kubernetes, after pushing the new image
Pinning an exact patch version stops an old cached php:8.3-fpm layer from sneaking back in.
Coolify, CapRover, Dokku and other self-hosted PaaS
Update the PHP version in your Dockerfile or build pack, then trigger a redeploy with force rebuild or no cache enabled. A normal redeploy may reuse the old, vulnerable image layer.
cPanel and WHM (EasyApache 4)
Run system updates from WHM or over SSH ( or ), then confirm each ea-phpXX package includes the fix. In MultiPHP Manager, move every site off end-of-life versions such as ea-php74 and ea-php81.
Plesk
Go to Tools & Settings, then Updates, and install the latest PHP handler updates, or run over SSH. Then switch any site on PHP 8.1 or older to a supported version under Hosting & DNS, then PHP.
Laravel Forge, Vapor and Laravel Cloud
Laravel's team has been getting patched PHP into its base images. On Forge, update PHP on each server (through the server's PHP settings or apt over SSH) and restart FPM. On Vapor and Laravel Cloud, redeploy your apps so they pick up the patched runtime.
WordPress on managed or shared hosting
You usually can't patch PHP yourself. Ask your host to confirm in writing that your server runs a PHP2Shell-patched build, and switch your site to PHP 8.3 or newer in your hosting panel. Updating WordPress itself does not fix PHP2Shell. If your host can't confirm, put the site behind Cloudflare (WAF rules are available on the free plan) while you move hosts.
Google Cloud, AWS and other clouds
App Engine Standard on PHP 8.2 and newer updates automatically. App Engine Flexible, Cloud Run without automatic base image updates, GKE and any custom container need a rebuild and redeploy. On AWS, Azure and other clouds, update the PHP runtime or container image yourself and redeploy.
How to verify you are patched
- Check the web runtime, not just the CLI. Create a temporary file containing , load it in a browser, then delete it immediately.
- On distro packages, check the changelog for the CVE numbers, since version numbers may not match upstream. Debian and Ubuntu: . RHEL family: . If both CVE numbers appear, the fix is in.
- Confirm no old workers are running. Run . Every worker's start time should be after your update.
- Hide your PHP version from attackers scanning for vulnerable sites by setting in php.ini.
Can't patch today? Temporary PHP2Shell mitigations
These steps reduce risk but do not make you safe. The PHP advisories are clear that updating is the only complete fix. Use them to buy hours, not weeks.
- Put a WAF in front of the site. Cloudflare's PHP2Shell rules are available on every plan, including free.
- Disable session upload progress with . It's rarely used and is a confirmed attack path, so keep it off even after patching.
- On PHP 8.5, set .
- Tighten request limits: keep post_max_size small and enforce body size at your reverse proxy; lower max_input_nesting_level, max_input_vars and max_file_uploads.
- Block multipart requests at the edge on endpoints that don't accept uploads.
- Recycle FPM workers aggressively if performance allows () to break attacks that span two requests.
- Prefer PHP-FPM over mod_php. mod_php is the most exposed setup.
- Clean up INI warnings: remove deprecated or invalid directives, especially php_value lines in .htaccess and PHP_VALUE from nginx, since startup warnings are part of one attack path.
Apply .ini changes in your main PHP configuration and restart every worker afterwards.
How to check if you've been hacked
PHP2Shell attacks happen below your application, so app logs may show very little. Look for:
- Unusual multipart requests followed by memory-limit errors or bursts of HTTP 500 responses
- Abnormally large or garbled PHPSESSID cookies in responses
- PHP workers crashing or restarting for no clear reason
- New or modified .php files in upload, cache or plugin folders (possible web shells)
- New admin users, unexpected cron jobs, or outbound connections from web server processes
If you see signs of compromise, assume secrets in memory were exposed. After patching, rotate database passwords, API keys, app secrets (Laravel APP_KEY, WordPress salts) and session secrets, and restore from a clean backup if files were changed.
PHP2Shell fix FAQ
Which PHP versions fix PHP2Shell?
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, or any later release. Distro packages may use different version numbers, so check the package changelog for the CVE IDs.
Does updating WordPress or Laravel fix PHP2Shell?
No. The bug is in PHP itself, so you must update PHP on the server. Updating your CMS or framework alone does nothing for this issue.
I'm on PHP 7.4 or 8.1. What should I do?
There is no official binary fix for end-of-life versions. Upgrade to PHP 8.3 or 8.4 as soon as possible, or use a vendor that provides backported security fixes.
Does disabling session.upload_progress fix PHP2Shell?
No. It blocks one confirmed attack path, but PHP core developers have stated plainly that updating is the only real mitigation.
Does Cloudflare protect me from PHP2Shell?
Cloudflare's WAF rules block known exploit patterns and help while you patch, but Cloudflare itself describes them as a stopgap. New attack variants may get through.
Do I need to restart anything after updating PHP?
Yes. Restart PHP-FPM, Apache or LiteSpeed, and rebuild and redeploy containers. Running workers keep using the old, vulnerable code until they restart.
Need help patching PHP2Shell?
Peham builds and runs PHP systems for clients and for our own SaaS products. If you need help auditing your servers, patching WordPress or Laravel, upgrading off end-of-life PHP, rebuilding containers, or setting up a WAF and monitoring, our Cloud & DevOps team can help.
Book a free 30-minute PHP2Shell security check and talk it through with our engineers.
