PHP2Shell Let Strangers Run Code on Any Unpatched PHP Server

Two bugs in PHP, the software that turns most websites into pages, let an attacker run their own code on a server without logging in. They were found in October 2026. The fixes went out on 21 October, and by then attempted attacks had already been seen in the wild. If your site runs PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12, you are past it. If it runs anything below those numbers, that is the only thing worth checking today.

What the bug did, and why it reached every WordPress site

PHP handles every request by keeping some working memory for it. Two flaws, CVE-2026-109618 and CVE-2026-109619, meant that memory could still be used after a request had finished, or read before it had been set up properly. A request built a certain way could then push PHP into running code the attacker sent, with no password and no account. Security researchers named the pair php2shell.

The pair scored 9.2 out of 10 on the standard severity scale, and both are classed as remote code execution with no login needed, which is the worst combination a server bug can have. The PHP project published a security release and rated Apache running PHP as an embedded module the highest risk, because of how closely it ties into the web server process.

WordPress is written in PHP. So are its plugins, its themes and most of the tools your host puts around it. A hole in PHP sits underneath all of it, which is why the advisories went out to hosting companies and container vendors rather than to bloggers.

The CISA alert lists every common way of serving PHP as affected: Apache with the PHP module, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed. If your site answers to any of those, it runs PHP, and it needed the patched build.

The week it happened

• 17 October. Reporting afterwards said Amazon saw exploitation attempts against its sensors four days before the fixes existed, which means people were already probing for this before the public knew what it was.
• 20 October, around 15:00 UTC. The two CVE numbers began circulating online with no technical detail attached. The PHP project pulled its pre-announcement forward and published it that evening, and moved the release date up by a day.
• 21 October, 07:41 UTC. A container vendor shipped images containing the fix roughly six hours ahead of the agreed time, against the plan the researchers had spent weeks arranging.
• 21 October, 14:00 UTC. The patches went public in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, with minimal backports for the older 7.4, 8.0 and 8.1 lines.
• 21 October. CISA issued its alert asking for immediate patching.
• 22 October. Vendors published their own advisories, F5, Citrix and QNAP among them. WordPress published guidance saying plainly that no WordPress update is required or planned, because this is a server problem.
• 23 October. CISA added a detection rule for spotting exploitation, and national cyber agencies in the UK, Canada, Australia and New Zealand issued their own alerts.

Which versions were affected

Anything below those numbers in its own line was affected, so 8.2.33 was vulnerable while 8.2.35 was not. That one digit is the whole difference between a patched site and an open door. Most things on a website cannot be settled that cleanly. An SEO change with no failure condition written down gets read as a win either way.

One caveat arrived after the patch, and it is a different bug. On 23 October PHP published an informational advisory for CVE-2026-115560. It can run code only on an unusual setup: an application that sets the session serialize handler to php_binary or php_serialize in its config, then switches it to php at runtime before calling session_start().

None of the 21 October releases fix it, and PHP is not issuing an emergency patch. Its advice is to set session.upload_progress.enabled=0 until the next routine release, which is the same line it already recommended for CVE-2026-109619, so if you applied that on 21 October, leave it in place. No attack against this flaw has been reported, and the attempts logged since 21 October target the two patched bugs.

MilesWeb patched 8.2.33 to 8.2.35 within a day

My blog runs on LiteSpeed with PHP 8.2. On 22 October I checked the response header and it said 8.2.33, which sat inside the affected range. By the evening the same header said 8.2.35. My host, MilesWeb, had patched it during the day without me asking.

I went looking anyway, because a bug that lets strangers run code is worth ten minutes. Two user accounts, mine and the editor login, both created in August. Four plugins, all expected. One theme. Nothing that should not be there. Patching mid-week costs a few minutes of downtime, and a 503 served during patching keeps the URLs in the index. That is cheaper than a month of cleanup.

What to do if you run a site

• Find your version. In WordPress it is under Tools, Site Health, Info, Server. In your host panel it is usually a PHP selector. Write the exact number down, not just 8.2. There is a step-by-step for the panel side in checking the PHP version and changing it.
• Compare it. Below the patched build for your line, ask your host to move you today.
• Ask two specific questions. Which patched build am I on, and have you applied firewall rules for the two CVE numbers while any server is still catching up.
• Change your passwords once you are patched. Your admin password, and any application passwords or API keys the site uses. Cheap insurance if you were on an affected build for a few days.
• Ask for the logs. Request the access logs for 20 to 23 October and a malware scan, especially if anything about the site looked strange this week. The seven signs a compromised site leaves are easier to see with the logs in hand.
• Ask them to hide the version. Your server probably announces its exact PHP version in a response header. That is free reconnaissance for anyone scanning, and turning it off costs nothing.

AI found more of these bugs, and the disclosure ran a day early

The PHP Foundation said AI tools have surfaced more PHP bugs than before, with 15 new CVEs published since 1 July. The disclosure also leaked a day early, so the patches arrived before the date everyone had agreed on, and exploit attempts began before many hosts had shipped the fix.

Neither of those is unusual now. Bugs get found faster than they can be coordinated, and the window between a leak and exploitation is measured in hours.

Check your PHP version. If it is patched, close this and get on with your day. If it is not, that is the one thing worth doing this week, and your host can do it for you in a few minutes.

More WordPress and hosting arguments sit in WordPress Care.

Updated 25 October with the 23 October advisory for CVE-2026-115560 and the setting that covers it. CISA added both CVE numbers to its Known Exploited Vulnerabilities catalog on 26 October.