PHP2Shell Explained: The Critical PHP Vulnerabilities Shaking the Web

What is PHP2Shell?

PHP2Shell is a pair of memory-safety bugs inside the PHP interpreter itself, not inside WordPress, Laravel or any single application. Because the flaw sits below the application layer, any website running a vulnerable PHP version is exposed, whatever code it runs.

PHP powers a very large share of the web, including WordPress, Drupal, Joomla, Magento and Laravel sites. That reach is why security teams, hosting companies and governments around the world reacted within hours.

CVE-2026-109618: RCE via out-of-memory corruption
When PHP runs out of memory, it bails out of the current context abruptly. If that happens while internal request data is only partly set up, the cleanup routine that runs afterwards can treat the half-built data as valid. An attacker who can deliberately trigger that out-of-memory condition can turn the resulting corruption into code execution.

CVE-2026-109619: RCE via stale global state
PHP keeps some global state that points at memory belonging to an individual request. Under the right conditions, that state outlives the memory it points to. The next request handled by the same worker process may then use the stale pointer before normal initialization resets it — a classic use-after-free that can be abused for code execution or for reading leftover memory.

Key facts at a glance

Who is affected?

In short: almost every PHP web server that has not been updated since October 21, 2026.

• All server modes are in scope: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.
• mod_php is the highest-risk setup. According to the PHP project’s advisory as summarized by Patchstack and Help Net Security, a single unauthenticated request can trigger the attack there before any application code runs.
• All major PHP applications are exposed if they sit on a vulnerable runtime. Wiz Research demonstrated unauthenticated RCE against the latest WordPress, Drupal and Joomla container images, and said even a bare “Hello World” script was exploitable.
• Memory leaks are a risk even without full takeover. Wiz also showed it could read PHP worker memory, which can hold passwords, session tokens and API keys.
• Old, unsupported versions are affected too. Every release back to PHP 5.4 carries at least one of the two bugs.

Timeline: how the PHP2Shell story unfolded

• October 17, 2026: Amazon Threat Intelligence’s MadPot honeypot network logged a PHP2Shell exploitation attempt from an anonymized IP address — four days before public disclosure, while the bugs were still under embargo.
• October 20, 2026: Details leaked ahead of the coordinated disclosure, and the name “PHP2Shell” began circulating. watchTowr confirmed the flaws were real. The PHP security team announced a release for the next day.
• October 21, 2026 (morning, UTC): Patchstack’s hosting partners reported active exploitation incidents. Cloudflare said it was seeing early attacks and pushed emergency WAF rules to all customers, including free plans.
• October 21, 2026 (precautionary shutdowns): Several high-profile services went offline until a patch was available, including the Dutch government portals DigiD and MijnOverheid, the Dutch House of Representatives website, Tweakers, a number of major Japanese platforms, and The SEO Framework’s servers.
• October 21, 2026, ~13:34–13:52 UTC: GitHub security advisories went live, followed by PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
• October 21, 2026 (government response): CISA (US), the UK’s NCSC and CERT-EU issued alerts urging immediate patching, and recommended taking unpatchable systems offline.
• October 22, 2026: Amazon disclosed its pre-disclosure honeypot finding, raising the question of how an attacker had exploit details before the embargo ended.

The controversy: why PHP2Shell is being debated worldwide

The technical facts are fairly settled. What people are arguing about is everything around them.

1. The leak and the broken embargo

Coordinated disclosure is meant to give vendors and Linux distributions time to ship fixes before attackers learn the details. With PHP2Shell, details leaked a day early, and Amazon’s honeypot data suggests at least one attacker was already testing an exploit on October 17. How that happened is still unknown, and it has reopened the long-running debate about whether large, multi-party embargoes can stay secret.

2. Conflicting reports on exploitation

Different organizations are telling slightly different stories, which is why headlines vary so much:

• Cloudflare and Patchstack’s hosting partners reported early attacks.
• Patchstack’s own telemetry shortly after the patch showed mostly probing, without hard evidence of breaches yet.
• Cisco’s PSIRT said it was not aware of malicious use against its products.

These positions are not necessarily contradictory: probing usually comes first, and confirmed breaches follow as exploit code spreads. For defenders the practical takeaway is the same — patch now rather than waiting for confirmation.

3. The role of AI in finding the exploit

Wiz researchers said the underlying flaws had existed for decades, but turning them into a working exploit needed a very complex chain of steps. They credited frontier AI models with lowering that barrier. That claim has fuelled a wider discussion about AI speeding up both bug discovery and weaponization — and what that means for how fast organizations need to patch.

4. Unsupported PHP and the “long tail”

The PHP project no longer supports PHP 8.1 and earlier. Because of the severity, its security team released minimal source backports for PHP 7.4, 8.0 and 8.1, but many embedded devices, legacy apps and forgotten servers will never receive them. Security researchers have warned that this long tail of unpatched systems could drive incidents for months, with Kevin Beaumont calling it one of the biggest vulnerabilities in years.

5. Shutting services down vs. staying online

CISA, the UK NCSC and the Dutch government took an unusually firm line: if you can’t patch, consider taking the system offline. Critics point to the disruption this causes; supporters argue that an unauthenticated RCE in the runtime leaves little middle ground.

How to fix PHP2Shell: step-by-step

1. Find every PHP installation. Check servers, containers, staging sites, CI images, and appliances or third-party software that bundle PHP. Run php -v on each host.
2. Update to a fixed version. Move to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or install your distribution’s patched package. Linux distributions and LTS vendors received the fix in advance.
3. Restart every PHP worker. Restart PHP-FPM pools, Apache, LiteSpeed or FrankenPHP so no worker keeps running old code.
4. Rebuild container images. Pull patched base images and redeploy; an old image in the registry is still vulnerable.
5. Handle legacy versions. On PHP 8.1 or older, get a backported fix from your vendor, apply PHP’s source backports for 7.4/8.0/8.1, or upgrade to a supported branch.
6. Switch away from repos that can’t patch yet. PHP advised users of the volunteer-run rpms.remirepo.net repository to use distribution packages or build from source, as that repo would not have updates on release day.
7. Avoid unofficial “fix” plugins. Unverified snippets and plugins can break sites and do not fix a runtime bug.
8. Assume possible exposure. If the server was internet-facing and unpatched, review it for compromise and rotate credentials it held, because the flaws can leak memory contents.

Temporary mitigations if you cannot update today

Only an update fully fixes PHP2Shell. The measures below, listed in PHP’s advisories and summarized by Patchstack, reduce specific attack paths but do not make a server safe.

For CVE-2026-109618 (out-of-memory corruption):

• Set memory_limit=-1 at the server or pool level (for example php_admin_value in the FPM pool) so applications cannot override it.
• Lower post_max_size (around 8M without uploads, 32M with uploads) and keep upload_max_filesize below it.
• Limit request size, field count and multipart part count at the web server or proxy.
• Use container or cgroup memory limits; avoid RLIMIT_AS and RLIMIT_DATA, which can trigger the vulnerable path.

For CVE-2026-109619 (stale global state):

• Set upload_progress.enabled=0 in php.ini or the FPM pool (not ini_set() or .user.ini), then restart all workers.
• On PHP 8.5, set fatal_error_backtraces=0 and restart all workers.
• Remove invalid or deprecated per-request settings that emit diagnostics early; hiding errors does not help.
• Fix attacker-reachable fatal errors and execution timeouts.

Edge protection: Cloudflare has deployed WAF rules for the known exploit vectors to all plans. It describes them as a stopgap, and they only help if your origin server accepts traffic exclusively from Cloudflare.

Signs your server may have been targeted

Because the attack happens below the application, your app logs may show very little. Wiz Research suggests watching for:

• Unusual multipart requests followed by memory-limit errors or bursts of HTTP 500 responses
• Unexpectedly large or malformed PHPSESSID cookies in responses
• Unexplained PHP worker restarts

These are clues, not proof. If you see them, update anyway and treat the server as potentially compromised.

PHP2Shell in context: a tough year for PHP security

PHP2Shell lands after a run of serious PHP issues in 2026:

• May 2026: A use-after-free in the SOAP extension (CVE-2026-6722) could allow remote code execution via crafted SOAP requests, fixed in 8.2.31, 8.3.31, 8.4.21 and 8.5.6.
• June 2026: CISA added a Magento PHP object-injection flaw (CVE-2026-45247, CVSS 9.8) to its Known Exploited Vulnerabilities catalog.
• July 2026: CVE-2026-12184 and CVE-2026-14355 enabled remote denial-of-service against PHP-FPM process pools and the OpenSSL extension.

The pattern is clear: PHP servers need the same fast, automated patching discipline that teams already apply to browsers and operating systems.

Frequently asked questions

What is PHP2Shell?

PHP2Shell is the nickname for CVE-2026-109618 and CVE-2026-109619, two critical memory-corruption flaws in the PHP runtime that can allow unauthenticated remote code execution on web servers. They were disclosed and patched on October 21, 2026.

Which PHP versions are vulnerable to PHP2Shell?

All PHP versions from 5.4 through 8.5.11 are affected by at least one of the two flaws.

Which PHP version fixes PHP2Shell?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix both vulnerabilities. Older branches need a vendor backport or PHP’s source backports for 7.4, 8.0 and 8.1.

Is my WordPress site affected?

Yes, if it runs on a vulnerable PHP version. The bug is in PHP itself, so updating WordPress or its plugins does not fix it. Ask your host which PHP version your site runs and whether it has been patched.

Is PHP2Shell being exploited in the wild?

Early attacks and probing have been reported by Cloudflare and Patchstack’s hosting partners, and Amazon logged an exploitation attempt four days before disclosure. Some vendors, such as Cisco for its products, have not seen malicious use. Treat it as actively targeted.

Does a WAF fully protect me?

No. WAF rules block known exploit patterns only and are a temporary measure. Updating PHP is the only complete fix.

What should I do if I’m on PHP 8.1 or older?

Upgrade to a supported branch, get a backported fix from your Linux distribution or LTS vendor, or build from PHP’s source backports. If none is possible soon, consider taking the site offline, as CISA and the UK NCSC advise.

How do I check my PHP version?

Run php -v on the server, or create a temporary page that calls phpinfo() and delete it immediately afterwards. On shared hosting, check your control panel’s PHP settings.

Bottom line

PHP2Shell is one of the most serious PHP security events in years: two runtime-level bugs, unauthenticated code execution, a leaked embargo, and evidence of attackers moving before the patch existed. The fix is simple and available now. Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, restart every worker, rebuild your images, and assume any server left exposed may need investigation.