The bugs sit inside PHP itself, need no login to attack, and have landed on the US government's must-fix list.

Most of the web runs on PHP — the language behind WordPress and a huge share of the world's websites, shops and booking systems. So when two critical flaws are found inside PHP itself, and attackers start using them within days, it stops being a story for programmers and becomes a story for everyone who runs, or simply uses, a website.

The flaw pair, nicknamed "php2shell," was fixed in emergency PHP releases on 21 October. On 26 October, the US Cybersecurity and Infrastructure Security Agency (CISA) added both bugs to its Known Exploited Vulnerabilities catalog — its official list of flaws that attackers are actively using — and told organisations to patch immediately.

What happened

The two vulnerabilities, tracked as CVE-2026-109618 and CVE-2026-109619, each carry a severity score of 9.2 out of 10. They were patched in PHP versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Anyone running an older release on the 8.2 to 8.5 branches is exposed, and anyone still on PHP 8.1 or earlier — versions no longer supported — has no fix available at all. CISA's advice for those systems is blunt: take them offline until they can be updated.

The disclosure was messier than planned. Technical details of the flaws leaked before the fixes were ready, which compressed everyone's timeline. Amazon's threat intelligence team recorded an exploitation attempt against its honeypot systems on 17 October — four days before the patch even existed — and more attempts followed within hours of the release. Some government organisations, including in the UK and the Netherlands, took websites offline as a precaution rather than risk running unpatched.

How the flaws work

Both bugs live in the way PHP cleans up after a web request that fails halfway through. In plain terms: PHP can be tricked into abandoning a request at exactly the wrong moment, leaving its internal notes in a corrupted state — and a carefully crafted follow-up request can then use that mess to run the attacker's own code on the server.

The attack arrives as a specially built file-upload style request, and it needs no username, no password and no cooperation from anyone at the victim site. CISA notes it can strike before an application even starts running. The setups at highest risk are servers running Apache with mod_php, which PHP itself flags as the most dangerous configuration; PHP-FPM, php-cgi, FrankenPHP and LiteSpeed setups are affected too.

A successful attack runs code with the permissions of the web server — enough, in practice, to steal a site's database, plant a fake login page, or turn the server into a launchpad for further attacks.

How bad is the exploitation, really?

This is where the story needs care. Exploitation is real but not yet turnkey. In testing a week after disclosure, security firm Tenable found that working exploits have to be carefully tuned to each target's exact PHP build, which is skilled work; its own five test sites were not compromised. Researcher honeypots did record successful attacks — 35 shell executions across three sensors on 24 October — and one reported campaign combined php2shell with a second flaw to break into firewall management servers. Censys counted about 30.3 million PHP services still reporting a vulnerable version on 29 October, though running an old version does not automatically mean a given server can be exploited.

The direction, though, is one-way: every day a server stays unpatched, attackers get more practice against it. That is why CISA set federal agencies a deadline of 29 October to fix or remove affected systems.

What this means for you

• If you run any website, check your PHP version today. In your hosting control panel or server settings, you want 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or later. If you are on PHP 8.1 or older, upgrading is no longer optional maintenance — it is the fix.
• Restart after updating. Patched code only protects you once the running PHP processes are replaced, so restart the PHP service (or ask your host to confirm it was done).
• Patching is not the same as cleaning. If your site was exposed before the fix, check server logs back to at least 17 October for strange upload requests and unexpected activity, as CISA and Amazon both advise — a patch closes the door but does not remove anyone already inside.
• If you only browse the web, there is nothing to install. But do not be surprised if smaller sites you use go briefly offline or behave oddly while their owners patch; that downtime is the system working as it should.

Sources

• CISA, "Critical Vulnerabilities in PHP Require Immediate Patching", 21 October 2026 (updated 26 October 2026)
• Tenable, "php2shell one week later: Why one exploit doesn't work everywhere", 29 October 2026

Related reading: Maximum-Severity GitLab Flaw Is Under Active Attack · Passkeys and Two-Factor Authentication: Stronger Sign-Ins in 15 Minutes