PHP2Shell (CVE-2026-109618): What Every Website Owner Must Do This Week

October 24, 2026 · 4 min read

On 21 October 2026 the PHP project shipped emergency releases for two critical flaws, CVE-2026-109618 and CVE-2026-109619, now known as PHP2Shell. Both score 9.2 on CVSS 4.0 and let an attacker with no account run code on your web server. Within 45 minutes of disclosure Cloudflare was seeing tens of thousands of exploit attempts; by the next morning it was millions, and on 26 October the US CISA added both CVEs to its Known Exploited Vulnerabilities catalogue. This is the most serious PHP bug in years, and because WordPress, WooCommerce, Laravel and most of the web run on PHP, it almost certainly affects you.

Here is what happened, what we have already done for the sites we host and maintain, and what you should check if your site is hosted elsewhere.

What PHP2Shell is

PHP processes every web request through a “SAPI”: Apache’s mod_php, PHP-FPM, php-cgi, LiteSpeed or FrankenPHP. The two bugs sit in that request-handling layer, so every PHP installation that serves web traffic is affected, whatever framework or CMS runs on top. CISA singles out Apache with mod_php as the highest-risk setup. A successful exploit gives the attacker a shell as the web-server user: enough to read wp-config.php, dump the database, plant a backdoor and pivot to other sites on the same server.

Amazon’s honeypots logged the first attempt on 17 October, four days before the patches existed. Sophos and Arctic Wolf have since watched botnets try to drop a Mirai variant through it. The good news from Wordfence and other researchers is that a reliable exploit has proved harder to build than the headlines suggested, so most of the noise so far is scanning. That window will not stay open.

The fixed versions

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

PHP 8.1 and older receive no fix. CISA’s advice for those servers is blunt: take them offline until they are upgraded. If your host still offers PHP 7.4 or 8.0 as a “compatible” option, that option is now a liability.

A third bug, still unpatched

Two days later PHP disclosed CVE-2026-115560. It is related, but only triggers on an unusual configuration: an application that sets session.serialize_handler to php_binary or php_serialize, switches it back to php with ini_set() before session_start(), and has session upload progress on. PHP calls it an unlikely risk and will fix it in the next routine release. Until then the mitigation is one line in php.ini:

session.upload_progress.enabled = 0

That same setting is PHP’s recommended belt-and-braces mitigation for CVE-2026-109619, and WordPress does not use session upload progress, so there is no downside to turning it off.

What we have done for MymenTech clients

Every site on our hosting and maintenance plans, including mymentech.com itself, was moved to PHP 8.3.36 on the day of the release, and session.upload_progress is disabled across the board. We then ran a malware scan on each site looking for the things CISA’s detection rule flags: PHP worker processes spawning shells, unexpected .php files in wp-content/uploads, and new administrator accounts. Nothing was found, and the scans now run daily rather than weekly for the rest of the quarter.

What to do if we do not host your site

1. Find your PHP version. In WordPress go to Tools → Site Health → Info → Server. In cPanel or hPanel it is under “PHP configuration” or “Select PHP version”. Anything below the four versions above is vulnerable.
2. Update or ask your host to. Managed hosts (Hostinger, Kinsta, WP Engine, SiteGround, Cloudways) patched within hours; shared cPanel hosts vary. If the control panel offers 8.3.36 or 8.4.27, pick it. If it does not, open a ticket today and ask when it will.
3. If you cannot patch, put a WAF in front. Cloudflare’s free plan and the Wordfence firewall both have PHP2Shell rules. It is a stopgap, not a fix.
4. Check you were not already hit. Run a scan with Wordfence, Solid Security or your host’s scanner. Look at Users for accounts you did not create, and at wp-content/uploads for any .php file at all. Check that .user.ini and .htaccess contain nothing you do not recognise.
5. Rotate secrets if anything looks wrong. Database password, the salts in wp-config.php, API keys for payment gateways and email, then every admin password.
6. Retire PHP 8.1 and older for good. WordPress 7.1 runs well on 8.3; the modest work of testing a plugin or two is cheaper than the alternative.

How to tell if your host handled it

Open your site in a browser, then view the response headers (in Chrome: DevTools → Network → click the first request → Headers). Many servers send x-powered-by: PHP/x.y.z. If yours shows 8.3.36, 8.4.27, 8.5.12 or 8.2.35, you are patched. If the header is hidden, Site Health is the next best place, and if you are still unsure, send us the URL and we will check it and reply the same day, free, whether or not you are a client.

Sources: CISA alert, 21–26 October 2026; The Hacker News on CVE-2026-115560; Datadog Security Labs analysis.