PHP2Shell: What Website Owners Need to Do Now

If your website runs on PHP, and that includes most WordPress, Drupal, Joomla and Magento sites, you need to act today. On October 21, 2026, the PHP project released emergency fixes for two critical remote code execution flaws, CVE-2026-109618 and CVE-2026-109619, now widely called “PHP2Shell.”

Remote code execution means an attacker can run their own commands on your web server. According to Huntress, a working exploit for one common setup can be triggered by an unauthenticated web request before your site’s own code even runs. That means logins, security plugins and application-level checks will not stop it.

Details of the flaws leaked before the patches were ready, and researchers already claim working proof-of-concept exploits (Sophos). Expect attackers to scan for unpatched sites quickly.

Who is affected

The PHP project says all PHP installations serving web requests are at risk. That covers PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, which together cover nearly every shared, VPS and cloud hosting setup (Huntress).

These releases fix both flaws:

PHP branch	Fixed version	Notes
8.5	8.5.12	Supported
8.4	8.4.27	Supported
8.3	8.3.36	Supported
8.2	8.2.35	Supported
8.1 and older	None official	End of life; only unofficial source backports or vendor LTS packages

If your site runs PHP 8.1 or older, there is no official fix. Plan an upgrade to 8.3 or 8.4 now, and test your site after the change.

How to check if your site is vulnerable

The question is simple: what exact PHP version is your site running? Here is how to find out.

1. WordPress sites: In the admin dashboard, go to Tools > Site Health > Info > Server. The PHP version is listed there in full (for example, 8.3.30).
2. cPanel hosting: Open Select PHP Version (or MultiPHP Manager) to see the version assigned to your domain.
3. Your own server: Run php -v for the command-line version, and check each web SAPI separately, such as php-fpm8.3 -v. They can differ.
4. Compare the version to the table above. Anything below the fixed release for its branch is vulnerable.
5. Ask your host. On shared or managed hosting, your provider builds and patches PHP. Ask them in writing whether their PHP builds include the October 21 fixes. Distributions and hosts often backport fixes without changing the version number, so the number alone may not tell the whole story (ma.ttias.be).

Do not rely on your site’s response headers. Most hosts hide the PHP version, and its absence does not mean you are safe.

Remediation options

Patching is the only confirmed fix. If you cannot patch today, take the site offline until you can. If neither is possible, apply the interim mitigations below and treat them as risk reduction, not a cure.

Option	Protection	Downtime	Best for
1. Patch PHP	Full (confirmed fix)	Minutes	Everyone, as soon as a patched build is available
2. Take the site offline temporarily	Full, if PHP never runs	Until patched	Sites that cannot patch today and can tolerate a short outage
3. Interim mitigations	Partial (unproven)	None	Sites that must stay online and cannot patch yet

Option 1: Patch PHP (recommended)

• Shared or managed hosting: Open a ticket with your host today. Ask when the patched builds will be live and get confirmation in writing.
• Your own server: Install your distribution’s updated PHP packages, then restart PHP-FPM, Apache or LiteSpeed. Long-running PHP processes keep the old code in memory until restarted.
• PHP 8.1 or older: Move to a supported branch (8.3 or 8.4). Test themes and plugins on a staging copy first if you can.

Option 2: Take the site offline temporarily

The goal is to stop requests from reaching PHP at all. A WordPress “maintenance mode” plugin does not do this. Those plugins run inside WordPress, and this exploit can fire before WordPress loads.

Instead, serve a plain HTML page at the web server level:

1. Create a simple maintenance.html page in your site’s root folder.
2. Back up your existing .htaccess file.
3. Add these lines to the very top of .htaccess (works on Apache and LiteSpeed):

RewriteEngine On
RewriteCond %{REQUEST_URI} !^/maintenance\.html$
RewriteRule ^ /maintenance.html [R=302,L]

4. Visit the site from a private browser window to confirm every page shows the maintenance page.
5. Once your host confirms PHP is patched, restore your original .htaccess.

Other ways to get the same result: ask your host to suspend PHP for the account, or, if you use Cloudflare, put the site into a Cloudflare maintenance or block rule. A Cloudflare rule only helps if your server refuses traffic that does not come through Cloudflare.

Option 3: Interim mitigations if the site must stay online

These steps are not proven to stop the exploit. Use them only until you can patch.

Turn off PHP session upload progress. Researchers report the attack path uses PHP’s session upload-progress feature, which is on by default (ma.ttias.be).

• In cPanel, go to Select PHP Version > Options and set session.upload_progress.enabled to Off.
• If that option is not available, add session.upload_progress.enabled = 0 to a .user.ini file in your site’s root folder. It is a per-directory setting, so .user.ini works, but ini_set() in your code does not.
• On your own server, set it in php.ini or the PHP-FPM pool (php_admin_flag[session.upload_progress.enabled] = off), then reload PHP.

Block file-upload requests if your site does not need them. The reported exploit relies on multipart upload requests. If your public site has no upload forms, you can block them in .htaccess:

RewriteEngine On
RewriteCond %{HTTP:Content-Type} multipart/form-data [NC]
RewriteRule ^ - [F]

This will break forms with file attachments and media uploads in the WordPress admin, so remove it once you have patched.

Turn on WAF protection. If you use Cloudflare or another web application firewall, enable its managed rules for these CVEs.

Settings like file_uploads = Off or a smaller post_max_size are reported as unlikely to help (ma.ttias.be).

Check for signs of compromise

Patching closes the door, but it does not remove anyone who already got in. No confirmed indicators of compromise have been published yet, so look for the behavior an attacker would leave behind (Huntress):

• New or changed files. Look for recently modified .php files, especially in wp-content/uploads or other folders that should only hold images and documents.
• Unexpected scheduled tasks. Check cPanel > Cron Jobs (or crontab -l on your own server) for anything you did not create.
• New admin accounts in WordPress or your hosting control panel.
• Odd process activity on servers you manage: PHP or web server processes launching shells or tools like curl and wget, or commands such as whoami, id and uname -a.
• A full malware scan with your security plugin (for example, Wordfence) or your host’s scanner.

If you find signs of compromise, take the site offline, preserve your web server and PHP logs, and contact your incident response provider before cleaning anything up. Deleting files first can destroy the evidence you need to understand what happened and what you may need to report.

How Eagle can help

For organizations in regulated industries, an exploited website is more than an IT problem. It can become a reportable incident under HIPAA, NYCRR 500 or Ohio HB 96. Eagle Consulting Partners can help you inventory every system running PHP (including vendor-hosted portals), coordinate patching with your hosting provider or MSP, and review for signs of compromise. Contact us and we will help you work through it.

Sources: Huntress: Rapid Response, php2shell; ma.ttias.be: PHP CVE-2026-109618 and CVE-2026-109619 early mitigation steps; Sophos: Proof-of-concept exploit released for PHP vulnerabilities; watchTowr: PHP RCE FAQ; Sansec: PHP2Shell.