PHP2Shell: Two Critical PHP Flaws, an AI-Assisted Discovery, and the Patch Every Site Needs

On October 21, 2026, the PHP project shipped an emergency security release a full day ahead of schedule, fixing two critical vulnerabilities in the engine that runs most of the web. Both flaws — CVE-2026-109618 and CVE-2026-109619, quickly dubbed "PHP2Shell" — score 9.2 under CVSS v4.0 and can give an unauthenticated attacker code execution with the web worker's privileges. The release was not supposed to happen until October 22. It moved after the CVE identifiers leaked on October 20 alongside a wrong "CVSS 10.0" claim and an accidentally posted proof-of-concept video. Amazon Threat Intelligence had already logged an exploitation attempt against its MadPot honeypots on October 17, four days before the public knew anything. Two days after the patch, on October 23, PHP disclosed a third, narrower flaw. If your site runs on PHP — and most sites do — this is your story too.

The two bugs, in plain English

Neither flaw lives in WordPress, Drupal, Laravel or any other application. Both live in PHP itself, in memory-management and error-handling code nearly every request touches, and the vulnerable code dates back to PHP 5.4 (2012). Updating your CMS or its plugins does nothing here: the hole is underneath them.

CVE-2026-109618 — memory corruption during out-of-memory handling. PHP enforces its memory_limit by aborting a request the moment an allocation fails. If that abort lands while internal request data is only partially initialised — for example, while PHP is parsing a form-based file upload — request cleanup can treat the half-built data as valid and free memory that was never properly set up — memory that can still hold bytes from earlier allocations an attacker controls. Sansec notes the same bug can also leak live server memory — passwords, session tokens, API keys, even TLS private keys from other requests — inside a PHPSESSID response cookie.

CVE-2026-109619 — use-after-free via stale global state. PHP workers are reused across many requests. Internal state owned by one request can survive after its backing memory has been freed — after a fatal error or a timeout — and a later request on the same worker can pick up that stale state before normal initialisation resets it. Session upload progress, enabled by default, is one early consumer of the stale state, which means an application does not even need to call session_start() to be exposed.

Every PHP setup is in scope: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP considers mod_php the highest risk because a demonstrated exploit fires before any application code executes. Researcher Ryan Austin of Calif built an exploit tool, PHP2Shell, that chains both bugs, and reported successful unauthenticated code execution against current releases of WordPress, Drupal, Joomla, Magento, Laravel, phpMyAdmin, Nextcloud and other widely used PHP applications.

Who is affected, and the versions that fix it

PHP powers roughly 70% of websites whose server-side language is known. The bugs are present in every unpatched PHP release since 5.4, per Sansec. The fix landed in four supported branches:

One wrinkle matters: many distributions, LTS vendors and control-panel packages backport the fix onto the previous release, so your version number may not change even though you are patched. In that case, the build date (October 21, 2026 or later) or a package changelog entry naming the CVE IDs is the real proof.

Should you panic? The honest exploitability picture

This is where the story needs care, because the first day of coverage ran hotter than the evidence. On October 22, Sansec updated its research with an unusual walk-back: mass exploitation is less likely than it expected on release day. The public proof-of-concept exploits do not work against a default PHP installation. A working attack needs specific knowledge of the target server and specific conditions on it — in several tested cases, a pre-existing local file inclusion bug in the application. Nobody has demonstrated the single generic request that made Log4Shell and Shellshock so dangerous.

Rapid7's testing points the same way: each public PoC works only against a specific combination of operating system, PHP version and web server, its own exploit worked only under narrow lab conditions, and it has seen attempts rather than confirmed successful exploitation in the wild. Treat the current difficulty as a window to patch, Rapid7 advises, not a reason to delay. Amazon's framing is hotter — it describes the vulnerability as broadly exploited — and Sophos initially reported a breach before correcting that to scanning and failed attempts. The vendors disagree about how bad it is today. They do not disagree about what to do.

Defenders with the most to lose did not wait for the argument to settle. On October 21, Tweakers, the Dutch House of Representatives, the Netherlands' NCSC and Security.NL all went offline as a precaution. CERT-EU's advice is blunt: patch immediately, and where that is not feasible, consider isolating internet-facing applications from public networks until the fix is applied and verified. Cloudflare reported early attacks at 07:43 UTC that day, hours before the fixed versions shipped.

The AI angle: machines found these bugs, and machines weaponised them

For an AI news site, the most important part of this story is how the bugs were found. Calif's Ryan Austin discovered the first attack paths in August while auditing PHP for OpenAI's Patch the Planet programme, and reported the initial flaw on August 11 — the same day OpenAI independently reported the same root cause. Wiz Research found its first related vulnerability on August 19 using AI-assisted research — its Atlas agent working alongside frontier models including Google's Gemini 4 Argon and GPT-5.6 Sol — and reported further attack paths on August 24. Wiz described the exploit chain as being at the edge of what human researchers could practically achieve, until frontier AI models lowered the barrier.

The same acceleration applies on offence. Security firm Tolmo's Matt Suiche said his team built a working exploit in under 24 hours with AI assistance — work he estimated would previously have taken weeks. The defensive lesson is uncomfortable but simple: the window between disclosure and exploitation is now measured in hours, not weeks, and patch latency is becoming the metric that decides who gets breached.

Why the fix took two years

The PHP Foundation's own postmortem is strikingly candid. The first signs of the out-of-memory flaw surfaced in 2024, during PHP's first external security audit in years, carried out by Quarkslab. A developer spotted the warning signs, but no concrete attack path was found. The security team drafted several competing fixes, and each carried a real cost: breaking backward compatibility, introducing a new denial-of-service risk, or forcing coordinated changes across third-party extensions. Working by consensus, with only a handful of developers who know the engine deeply, the effort stalled and restarted for months. The Foundation's verdict on itself: "We won't pretend otherwise: the delay was a structural failure, caused by both the security team's decision process and its lack of resources." It is now moving security decisions to majority vote, and asking the organisations that depend on PHP to help fund the work — while noting that AI-assisted research has sharply increased the reports its small team must handle.

And then a third flaw

On October 23, PHP disclosed CVE-2026-115560, another potential RCE — but one that affects only applications configured in an unusual, non-standard way, and PHP considers it an unlikely risk. There will be no emergency release for it; the fix arrives in the next routine bugfix release. Until then, PHP and CERT-EU both point to one mitigation: set session.upload_progress.enabled=0 and restart every worker.

What to do now

1. Find every PHP you run. On a server, php -v is the start — but the command line can use a different build from your web server, so confirm with a temporary phpinfo() page (read the version and build date, then delete it immediately) or your hosting panel. In WordPress, the version is under Tools > Site Health > Info > Server. Check every site and every PHP version.

2. Update to the fixed release for your branch — 8.5.12, 8.4.27, 8.3.36 or 8.2.35 — from your distribution's packages, the ondrej/php PPA, your panel (cPanel's EasyApache 4 shipped patched ea-php82 through ea-php85 packages, plus backports for 7.4, 8.0 and 8.1), or the official Docker images. On managed hosting, ask your provider which build you are running and when it was built — many patched silently. Restart PHP-FPM or Apache afterwards so workers load the new binary.

3. If you are on PHP 8.1 or older, no official fixed release is coming. Your options are a vendor backport (distribution, LTS provider or cPanel), PHP's minimal source backports for 7.4, 8.0 and 8.1, or — the only durable answer — upgrading to a supported branch.

4. If you cannot patch today, PHP publishes temporary mitigations in its official security advisory: enforce memory_limit=-1 administratively so applications cannot override it, keep post_max_size low (8M without uploads, 32M with), set session.upload_progress.enabled=0, and on PHP 8.5 also set fatal_error_backtraces=0, restarting every worker. PHP is explicit that these measures are incomplete — in its release notes' words, there are no complete mitigations and updating is the only safe choice. CERT-EU's fuller guidance is in its advisory 2026-018, and the technical deep-dives are at Sansec and Rapid7.

FAQ

My WordPress is fully updated. Am I safe?

Not necessarily. The flaws are in PHP itself, not in WordPress or its plugins, so application updates cannot fix them. What matters is the PHP version your server runs — check it against the fixed releases above.

Is PHP2Shell being exploited right now?

Attempts are confirmed: Amazon logged one on October 17, before disclosure, and Cloudflare saw early attacks on October 21. Vendors disagree on successful exploitation — Rapid7 has seen attempts and unreliable public exploits, not confirmed in-the-wild code execution — but all agree: patch now.

Do I need to take my site offline?

Sansec's updated assessment says no — update PHP instead. CERT-EU suggests isolating internet-facing applications only where patching is not feasible.

I'm stuck on PHP 8.1. What are my real options?

No fix is coming for 8.1 or older. Use a backported package from your distribution, an LTS vendor or cPanel's EasyApache 4, or PHP's minimal source backports — and schedule the upgrade to 8.2 or later.

What is CVE-2026-115560?

A third PHP flaw disclosed on October 23, 2026. It can lead to RCE only on unusually configured applications, PHP rates it an unlikely risk, and it gets no emergency release. Setting session.upload_progress.enabled=0 and restarting workers covers it until the routine fix.

Key takeaways

• PHP2Shell (CVE-2026-109618 and CVE-2026-109619, both CVSS 9.2) is a pair of unauthenticated remote code execution flaws in the PHP engine itself — fixed October 21, 2026 in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
• Public exploits do not work against a default PHP installation and need target-specific conditions — but exploitation attempts began before disclosure, so patch on an emergency basis anyway.
• AI-assisted research (Calif for OpenAI, OpenAI itself, and Wiz Research) found bugs that had lurked since PHP 5.4 — and AI also cut exploit development from weeks to under a day.
• The PHP Foundation calls the two-year delay in fixing the root cause a "structural failure" of its decision process and resources, and is changing both.
• A third flaw, CVE-2026-115560, affects only unusually configured apps; set session.upload_progress.enabled=0 until the routine fix lands.

October 24, 2026 — PHP2Shell will not be the last emergency patch for the software that runs most of the web. It may be the one that resets expectations: found by AI, leaked early, attacked before disclosure, fixed a day ahead of schedule. The sites that come out of this fine will be the ones that patched first and argued later.