PHP2Shell: Two Critical PHP Flaws, and What to Ask Your Developer Today

On 21 October 2026 (3 weeks ago) at 13:30 UTC (9:30 pm in Perth), the PHP team released fixes for two flaws that let an attacker run commands on a web server with a couple of crafted requests. No password needed, and no bug in your website required.

How much of the internet is affected?

Sources: W3Techs, 22 October 2026, and VirusTotal via BleepingComputer. PHP also powers Drupal, Joomla, Magento, Laravel and a lot of custom business systems.

What is the flaw?

One request makes PHP fail in a particular way. A second takes advantage of the mess left behind, and the attacker's code runs on your server with your website's permissions. Another version of the attack reads passwords, login tokens and API keys out of the server's memory.

Wiz Research, who found and reported both flaws, put it plainly: "Exploitation does not depend on a flaw in the application's code." A plain "Hello World" page is enough.

Which versions are fixed?

Ubuntu, Debian, Red Hat and other Linux vendors ship the fix under their own version numbers, so check your vendor's notice too. Every setup is affected: Apache with mod_php (the highest risk), PHP-FPM, FrankenPHP and LiteSpeed.

Is it being used in attacks?

Yes. Cloudflare and watchTowr saw attack traffic on release day, and ELLIO logged one attacker writing a backdoor onto a server 81 minutes after first probing it.

The day before the fix, details leaked on social media and security researcher Kirill Firsov posted a video of the attack running against WordPress 7.1.3, Magento 2.4.9, a Laravel 8 site behind nginx, and plain PHP on Apache.

What has happened since?

• Attacks started before the fix. Amazon saw the first attempt on 17 October, four days before the patches. It could not say whether any worked.
• The US government confirms attacks. On 26 October CISA added both flaws to its list of vulnerabilities known to be exploited, and gave US federal agencies until 29 October to patch.
• One reported breach was withdrawn. On 23 October Unit 42 linked an attack on a European government agency to PHP2Shell, then withdrew the link two days later: it could not confirm how the attackers got in.
• PHP found one more, smaller gap. On 23 October PHP advised keeping session.upload_progress.enabled=0 in place, even after patching, until its next regular release. The new flaw (CVE-2026-115560) only affects an unusual setup.
• The public exploit code is still unreliable. Elias Taylor found the exploits on GitHub "do not work against a vanilla PHP instance," and the author of the first one later dropped the theory it was built on. The rest are fake or only work in a lab. Do not run them against your own servers: you cannot easily tell what they really do.

Why are attackers not using it everywhere?

An attack that works on one server does not work on the next. Security researcher s1r1us of Hacktron tested this: they gave five AI models a working PHP2Shell attack for one common setup (Apache with mod_php) and asked each to adapt it to a MediaWiki site on a different setup, which it could only reach over the web.

Each new target means working out its PHP setup from the outside, then guessing its memory layout. Only the two most capable models managed it, and their makers restrict their use for attacks. The open models most criminals download all failed. s1r1us thinks this skill gap is one reason, though probably not the only one, that mass attacks have not happened.

Do not treat this as breathing room. Open models have been catching up within months, as GLM-5.3 showed. And an attacker only has to adapt the attack once for a popular setup, such as WordPress on a common host, to reuse it against every server set up the same way. Patch.

How did AI come into it?

Two teams found these bugs separately, both using AI. Wiz used Google's Gemini 4 Argon and OpenAI's GPT-5.6 Sol, and Calif found one of the flaws with GPT-5.6 Sol. The bugs had been in PHP for more than ten years. Wiz found the first one on 19 August, had a working attack on WordPress two days later, and reported it to PHP on 24 August.

OpenAI calls it "one of the most impactful security issues in recent memory" and expects findings like this to "increase sharply in the coming months."

What should you do?

Ask your host or developer three questions today:

1. Which PHP version do our sites run? Include the old ones: the 2019 microsite, the booking plugin, the staff intranet.
2. Who is updating them, and by when? You want a name and a day this week.
3. Is anything on PHP 8.1 or older? That needs an upgrade, not a patch, so it needs a plan.

If something cannot be patched quickly, the UK NCSC's advice is to apply the workarounds, or take it offline.

For technical teams

• Check the version you actually run. OpenAI's PHP2Shell checker flags vulnerable versions.
• Patch, then restart every PHP worker. Old PHP-FPM or Apache processes still run the old code.
• Rebuild container images and redeploy. Laravel Forge and Laravel Cloud apps may need a redeploy too.
• Put a firewall in front while you patch. Cloudflare's managed rules have covered it on every plan, free included, since 03:02 UTC on 21 October. Set them to block, not log.
• If you cannot patch yet, set session.upload_progress.enabled=0 and tighten post_max_size. These reduce the risk; they do not remove it.
• Keep that setting after patching until the next regular bugfix release, when PHP will ship a full advisory for CVE-2026-115560 (23 October advisory).
• Look for signs of attack: unusual multipart uploads followed by memory errors or bursts of HTTP 500s, and odd PHPSESSID cookies. If a server was exposed for a while, rotate the passwords and keys it held.
• Check appliances. Firewalls, NAS boxes and control panels often ship their own PHP.

Under the Essential Eight, internet-facing services must be patched within 48 hours when a flaw is critical or a working exploit exists. PHP2Shell is both.

What we have done

Every PHP server we maintain was checked within hours of the release. Our clients' servers are patched or scheduled, and anyone on an old PHP version has been contacted about an upgrade.

Frequently asked questions

Our WordPress site is with a managed host. Are we safe?

Probably soon, if not already. Ask them to confirm the date they patched. If you run your own server, even a cheap one, it is your job.

Our site is built with Laravel. Does updating Laravel fix it?

No. The flaw is in PHP, not Laravel. Firsov's video shows a Laravel site being taken over. Update PHP.

We are on PHP 7. What now?

PHP published minimal source backports for 7.4, 8.0 and 8.1, and some long-term support vendors offer their own patches, but the real fix is moving to a supported version. Start now: an application untouched for years takes work to move. Our save my project service exists for exactly this.

Not sure what PHP version you run? Send us your website address and we will tell you, free. For ongoing patching, see our cloud maintenance service.

Photo credits. All images used under the Unsplash License — free for commercial use, attribution appreciated:

• The elePHPant, PHP's mascot, on a laptop — Ben Griffiths

Sources

• PHP advisory for CVE-2026-109618 and CVE-2026-109619 — PHP security team, 21 October 2026.
• PHP2Shell: AI uncovers critical RCE vulnerabilities — Wiz Research. Discovery, AI use, signs of attack.
• Patch the Planet — OpenAI, 21 October 2026. Who found what, the coordinated response, the version checker.
• PHP usage statistics and WordPress usage statistics — W3Techs, 22 October 2026.
• php2shell demo video — Kirill Firsov, 20 October 2026.
• CERT-EU Security Advisory 2026-018 and UK NCSC alert — 21 October 2026.
• Cloudflare deploys protections against php2shell — Cloudflare.
• PHP2Shell: what we observed — ELLIO. Attack traffic.
• There isn't an easy exploit for this PHP vulnerability — Elias Taylor, and PHP2Shell exploitation explained — Recorded Future. Status of public exploit code.
• PHP ships emergency patches — BleepingComputer. Exposure estimate.
• Amazon says PHP2Shell exploitation began 4 days before patches — BleepingComputer, 22 October 2026.
• Known Exploited Vulnerabilities Catalog — CISA. Both CVEs added 26 October 2026.
• Threat Brief: CVE-2026-109618, CVE-2026-109619 — Unit 42, Palo Alto Networks. Retraction of 25 October 2026.
• php2shell: which models can exploit? — s1r1us, Hacktron, 26 October 2026, and the thread on X. AI benchmark.
• Informational advisory: Session upload progress — PHP, 23 October 2026. CVE-2026-115560.