PHP2Shell Vulnerability: Causes, Risks and How to Protect Your Website

PHP2Shell Vulnerability: Causes, Risks and How to Protect Your Website

If your website runs on PHP, this one is for you. On October 21, 2026, the PHP project shipped emergency fixes for two critical flaws in PHP itself, not in WordPress, not in a plugin, but in the language your site runs on. The pair has been nicknamed PHP2Shell, and attackers were already probing for it before the patch landed.

This is a fast-moving story, so I've kept the facts tight and noted where sources disagree. Here's what happened, why it happened, and what to do about it.

1. What Is PHP2Shell?

It's two use-after-free bugs in PHP's core. In plain terms: PHP frees a chunk of memory, but something keeps using it afterwards. Attackers can steer what ends up in that memory, and that can turn into running their own code as your web server user, no login needed.

One of the two bugs can also leak memory on its own, a bit like Heartbleed did. Sansec's research says that leaked memory can contain passwords, session tokens, API keys and even TLS private keys from other visitors' requests.

A heads-up on confusion: early coverage tied the session upload feature to CVE-2026-109618, while later analysis (ELLIO) says that path belongs to CVE-2026-109619. The patch covers both, so it doesn't change what you do.

2. Why Did This Happen? The Real Causes

1. A feature that's on by default. PHP's session upload-progress feature is enabled out of the box. It runs on file-upload requests before your application code even starts, which means your login screen, firewall plugin or clean code can't protect you. PHP says the risk is highest on mod_php, where an attack can succeed before any app code runs.
2. Memory-safety bugs in old, low-level code. PHP's engine is written in C, where one missed cleanup can leave freed memory still pointed to. Researchers describe one flaw as a fatal error (like running out of memory) interrupting PHP before it cleans up, so a later request or a reused worker treats freed memory as live data.
3. A very long exposure window. The affected code goes back to PHP 5.4 (2012). Millions of servers never moved off old versions.
4. Patching that moves slowly. PHP powers WordPress, Drupal, Joomla, Magento, shared hosting and control panels. CybelAngel found that 59% of exposed hosts run versions that won't get an upstream fix. Shared hosts also patch on their own timeline, not yours.
5. A leak and a fast attacker. Details leaked the day before the fix. Cloudflare reported the first attack attempts around 07:43 UTC on October 21, roughly six hours before the patch, and ELLIO's honeypots saw scans carrying the session upload field climb to 187 in a single hour that evening.

3. Who's Affected?

Any site serving web requests on PHP, which includes WordPress, Laravel, Drupal, Magento and custom PHP apps. And here's the part many people miss: updating WordPress, your theme or your plugins does not fix this. The flaw lives one layer lower, in PHP itself. (That's different from July's wp2shell, which was a WordPress core bug. I covered it in my WordPress security statistics report.)

If You Can't Patch Today

• Set session.upload_progress.enabled = 0 (in php.ini, .user.ini or .htaccess). It closes the session path only, so treat it as a short-term shield, not a full fix.
• Switch on managed WAF rules if your CDN or host offers them. Cloudflare had rules live by 03:02 UTC on October 21.
• Sansec also suggests blocking multipart/form-data requests on pages that never need uploads.

If You're on End-of-Life PHP

PHP 8.1 and older got no upstream release. The honest answer is to move to a supported branch. Since 8.2 only gets security fixes until the end of 2026, aim for 8.3 or newer. As a bonus, newer PHP is also faster, which helps with the slow-site problems I wrote about here.

5. Is It Being Exploited?

Reports vary, and it's changing by the hour. Cloudflare, Aikido, Patchstack's hosting partners and ELLIO all reported attack attempts on October 21. One summary published that day (SOCRadar) noted PHP itself hadn't yet confirmed in-the-wild exploitation and CISA hadn't listed the CVEs. Sansec adds that a successful attack needs specific knowledge of the target server and conditions. So not every unpatched site is instantly owned, but automated tools lower that bar quickly. Treat it as actively targeted and patch.

Frequently Asked Questions