PHP2Shell (Oct 21, 2026): How It Happened, Who Got Hit, and What To Do

On October 21, 2026, the PHP project shipped emergency patches for two critical remote-code-execution (RCE) vulnerabilities in the PHP engine itself — not a plugin, not a theme, the language a large share of the web actually runs on. The industry is calling the pair "PHP2Shell." This isn't a hypothetical risk: it leaked before the planned announcement, got scanned for within hours, and took real websites offline the same day. If your site runs on PHP, this is worth five minutes of real attention.

How it happened

PHP's security team had this fix scheduled under a coordinated embargo, originally set for release the next day. That plan broke on October 20, when details leaked online ahead of schedule — an anonymous post describing the flaws went up, came down, but not before screenshots of it (and of a proof-of-concept tool people started calling "PHP2Shell") had already spread to X and Mastodon. Security firm watchTowr was the first to confirm the leak was real rather than a rumor. Its CEO, Benjamin Harris, told BleepingComputer at the time: "In the last hour, two remote code execution vulnerabilities in PHP have been leaked. These vulnerabilities were previously scheduled under embargo." watchTowr said it had reproduced one of the two flaws itself, but deliberately held back technical details until a patch existed.

With the embargo already broken and a working exploit concept circulating publicly, PHP's security team moved its own release forward rather than sticking to the original date — and then beat even that moved-up deadline, shipping the actual fix about 25 minutes early on October 21. That decision is why this moved from "leaked rumor" to "patched same day" instead of sitting exposed for longer.

What PHP said

PHP's own advisory doesn't hedge. It rates both flaws 9.2 out of 10 on CVSS v4.0 — critical — and states plainly: "All PHP users are strongly encouraged to update immediately," and "there are no complete mitigations, updating is the only safe choice." In plain terms from the advisory: CVE-2026-109618 is caused by out-of-memory handling that can interrupt PHP while internal request data is only partially initialized, and that corrupted state then gets treated as valid during cleanup. CVE-2026-109619 is caused by request-owned internal state that can outlive its own freed memory and get reused by a later request on the same worker before it's properly reset. Both can lead to unauthenticated remote code execution — no login, no form, no access required to attempt it.

What cPanel said

cPanel's own EasyApache 4 changelog is terse to the point of blunt — the entry for build 25.91 simply reads: "(CVE-2026-109618, CVE-2026-109619) Security: Two vulnerabilities in PHP (critical)." Behind that one line, cPanel had patched builds of ea-php82 (8.2.34 → 8.2.35), ea-php83 (8.3.35 → 8.3.36), and ea-php84 (8.4.26 → 8.4.27) ready by roughly 13:45 UTC on the 21st, with ea-php85 patched to 8.5.12 alongside them — and backported fixes to its older ea-php74, ea-php80, and ea-php81 packages even though PHP itself no longer supports those lines directly. For any cPanel/WHM server, the fix means running the EasyApache 4 update in WHM and restarting Apache and PHP-FPM so the patched build actually takes effect — installing it isn't enough on its own.

What's affected

• Any server running PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, or LiteSpeed on an unpatched PHP version — risk is highest on mod_php specifically, where demonstrated exploits use a fully unauthenticated request
• cPanel/WHM servers running EasyApache 4 builds before 25.91
• Any PHP installation on versions earlier than 8.5.12, 8.4.27, 8.3.36, or 8.2.35 — PHP 8.1 and older no longer receive updates at all
• WordPress, Drupal, Joomla, Magento, and custom PHP applications of every kind — the flaw sits below the CMS, so the application itself can't fix it

Real sites that went dark

This wasn't an abstract advisory that sat in inboxes. Password-manager alias service addy.io took its own website and web app offline the same day as a precaution — its team logged the exact timeline on their own blog: offline at 12:07 UTC, website back at 15:18, web app back at 15:33, once the patched PHP build was confirmed installed. In the Netherlands, government organizations including the national cybersecurity center (NCSC) pulled their own sites offline rather than risk staying exposed. More broadly across Europe, a number of government agencies, schools, and hospitals took websites down the same day as a precaution while patching caught up — not because they'd necessarily been breached, but because the honest answer to "are we exposed right now" was yes until the patch was actually applied.

How fast attackers moved

This is the part that makes "we'll patch it next week" the wrong instinct. Within hours of the leak, researchers were already seeing botnets scanning broad blocks of IPv4 and IPv6 addresses specifically looking for exposed PHP servers. Cloudflare's own CTO reported early attack traffic against the vulnerabilities at 07:43 UTC on October 21 — the same day the official patch shipped. Security firm watchTowr observed active exploitation attempts against its own global honeypot network, and Hadrian reported seeing PHP2Shell exploited in the wild at scale, mostly by abusing PHP's session upload-progress feature. E-commerce security firm Sansec went further, confirming working, unauthenticated remote code execution against live Magento installations and several other widely used PHP applications — not a lab demo, a real exploit against real production software. Palo Alto Networks' Cortex Xpanse team estimated more than 22.6 million internet-exposed PHP instances were potentially vulnerable at the time. The gap between a flaw leaking and it being actively, automatically exploited at scale was measured in hours, not weeks.

What needs to be done

Update. That's the entire fix — there's no configuration workaround that fully closes this. If your host or server is managed by someone else, confirm directly that PHP has been updated to a patched version and, if the server runs cPanel/WHM, that EasyApache 4 has actually been rebuilt to 25.91 or later (not just downloaded) and Apache/PHP-FPM restarted. If you manage your own server, this is not a task to leave for next week — the scanning for unpatched servers started within hours of the leak, not after the official announcement.

If your site is hosted with us

Applying exactly this kind of critical, server-level security patch is part of what our managed hosting plans are built to cover — it's not a separate billable emergency, it's the baseline. If you're a current hosting client and want direct confirmation your specific site is on a patched build, reach out and we'll check it with you.

• PHP.net — official advisory (2026-10-21) ↗
• cPanel — EasyApache 4 Change Log 25 (build 25.91) ↗
• BleepingComputer — PHP ships emergency patches for critical PHP2Shell flaws ↗
• watchTowr — PHP2Shell: PHP Remote Code Execution Exploited ↗
• CISA — Critical Vulnerabilities in PHP Require Immediate Patching ↗
• addy.io — why we went offline for the PHP2Shell vulnerability ↗
• Managed Hosting — security patching included
• Talk to us about your site's PHP version

QWhat are CVE-2026-109618 and CVE-2026-109619?

Two critical remote-code-execution vulnerabilities in the PHP engine, disclosed October 21, 2026 and nicknamed "PHP2Shell." CVE-2026-109618 involves out-of-memory handling corrupting partially initialized request data; CVE-2026-109619 involves stale internal state surviving past its own memory being freed and getting reused in a later request. Both are rated 9.2/10 (critical) and can let an attacker run unauthorized code on the server without logging in.

QHow did PHP2Shell actually leak before the official announcement?

The fix was originally under a coordinated embargo. Details and a proof-of-concept leaked online on October 20, a day ahead of schedule, spreading to social media before PHP's official release. Security firm watchTowr confirmed the leak was genuine rather than a rumor, and PHP's team responded by shipping the actual patch early on October 21 instead of waiting out the original timeline.

QWere any real websites actually taken down by this?

Yes. Password-alias service addy.io took its own site and app offline on October 21 as a precaution, with a published timeline of roughly three hours. Dutch government bodies including the NCSC, and a number of European government agencies, schools, and hospitals, also took their own sites offline the same day while confirming their servers were patched.

QHow quickly did attackers start exploiting it?

Within hours. Automated scans for exposed PHP servers were observed starting shortly after the leak, and Cloudflare reported real attack traffic at 07:43 UTC on October 21 — the same day the patch shipped. Security researchers confirmed working exploitation against live Magento installations and other PHP applications, and one assessment estimated over 22 million internet-exposed PHP instances were potentially vulnerable.

QDo I need to be a hacker's direct target for this to affect me?

No. The realistic threat here is automated scanning, not a targeted attacker — bots were scanning broad swaths of the internet for exposed PHP servers within hours of the leak, with no login or prior access needed to attempt the exploit.

QIs updating WordPress or my CMS enough to fix this?

No. This vulnerability is in the PHP engine itself, below your CMS or application. Updating WordPress, plugins, or your own code doesn't touch it — the PHP version, and on cPanel servers the EasyApache 4 build, has to be updated and the web server restarted directly.

QHow do I know if my site has already been patched?

Check your PHP version against the patched releases — 8.5.12, 8.4.27, 8.3.36, or 8.2.35 or later — or, on a cPanel/WHM server, confirm EasyApache 4 is on build 25.91 or later and that Apache/PHP-FPM were restarted afterward. If you're not sure how to check, ask whoever manages your hosting directly rather than assuming.