PHP2Shell explained: the two critical PHP flaws and how to fix them

What is PHP2Shell?

PHP2Shell is the name researchers gave to two critical vulnerabilities in the core of PHP — the language runtime itself, not any particular framework or CMS. The PHP project announced a security release on 20 October 2026, and fixed versions shipped on 21 October.

• CVE-2026-109618 — when PHP runs out of memory during a vulnerable operation, request data can be left partially initialised. Cleanup code later processes that broken state, which can lead to remote code execution.
• CVE-2026-109619 — references to request data can outlive the memory they point to. A later request handled by the same PHP worker can reach that stale data, which can also lead to remote code execution.

Both are rated 9.2 on CVSS v4.0. Both can be triggered by an unauthenticated request — an attacker doesn’t need an account on your site. Researchers also demonstrated that the flaws can be used to read live PHP worker memory, which can expose database passwords, API keys and session tokens belonging to other visitors’ requests.

Which PHP versions are affected?

Practically every PHP version that serves web traffic, from PHP 5.4 up to the cut-offs below:

Branch	Vulnerable up to	Fixed in
8.5	8.5.11	8.5.12
8.4	8.4.26	8.4.27
8.3	8.3.35	8.3.36
8.2	8.2.34	8.2.35
8.1 and older	all	no official release

PHP 8.1 and older are past end of life. The PHP security team published minimal source-only backports for 7.4, 8.0 and 8.1 for people who build PHP themselves or rely on an LTS vendor — but there are no official binary releases for those branches. See vulnerable and fixed versions for the details.

Version numbers can mislead. Linux distributions often backport security fixes into an older-looking version (Ubuntu’s PHP 8.3.6, for example). Always check your vendor’s advisory or package changelog for the CVE IDs. How to check.

Who is at risk?

According to the PHP project, any installation that serves web requests is at risk. That includes:

• Apache with mod_php — the highest priority, because the vulnerable code runs before your application does.
• PHP-FPM behind Nginx, Apache or Caddy — still needs patching, even though its startup behaviour blocks one specific out-of-memory path.
• php-cgi, FrankenPHP and LiteSpeed (lsphp).
• Long-running workers (PHP-FPM pools, Laravel Octane, RoadRunner and similar) deserve extra attention for CVE-2026-109619, because it involves state carried from one request to the next on the same worker.

Exploitability varies by configuration and application behaviour, but no common web setup is safe to leave unpatched.

Updating your application does not help. WordPress, Drupal, Laravel, Symfony and Magento sites are all exposed if the PHP underneath them is vulnerable. The fix has to happen at the PHP level — on your server, in your container image, or at your host.

Is PHP2Shell being exploited?

Yes. Amazon’s threat-intelligence honeypots recorded a PHP2Shell exploitation attempt on 17 October 2026 — four days before public disclosure. Since then watchTowr and Cloudflare have reported attack traffic, Cloudflare has seen attempts to evade its protections, and Patchstack has received exploitation reports from hosting partners. The UK’s NCSC has advised taking offline any system that can’t be patched promptly.

Treat this like Log4Shell for PHP: assume scanning for vulnerable servers is already happening at internet scale.

How do I fix it?

1. Find the PHP that actually serves your site. php -v on the command line can report a different installation from the one behind your web server. How to check your PHP version.
2. Upgrade to a fixed release. Install PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 — or your distribution’s patched package. Pick your platform: Ubuntu & Debian, RHEL, AlmaLinux & Rocky, Docker, cPanel & WHM, WordPress or Laravel.
3. Restart PHP. Old PHP-FPM, Apache or LiteSpeed workers keep running the vulnerable code until they are restarted.
4. Verify. Confirm the running version is patched — for example with npx php2shell-checker@latest --local on the server, or the checker on our home page.
5. Check for compromise. Because attacks began before disclosure, review your logs and rotate secrets. Compromise checklist.

On managed platforms, follow your provider’s guidance. Google Cloud, for instance, patches App Engine standard (PHP 8.2+) automatically, but custom containers and GKE workloads must be rebuilt and redeployed.

What if I can’t patch today?

The PHP developers are clear that patching is the only complete fix. If you need a few hours or days, interim measures — disabling session.upload_progress, enforcing request-size limits, turning on WAF rules, or restricting public access — can reduce exposure. They are stopgaps, not solutions. See interim mitigations for the details and their limits.

What about end-of-life PHP?

If you run PHP 8.1, 8.0, 7.4 or older, PHP2Shell is a hard deadline to upgrade. Your options, from best to worst:

1. Upgrade to a supported branch — 8.4 or 8.5 ideally, or 8.3 (security fixes until December 2027). PHP 8.2 receives security fixes only until 31 December 2026.
2. Use a vendor LTS package that includes the backported fix (some enterprise distributions and commercial LTS vendors provide these).
3. Build from source with the official backport — only if you already maintain your own PHP builds.

Frequently asked questions

Why is it called PHP2Shell?

Because successful exploitation can give an attacker a shell — command execution — on the web server, starting from nothing but a crafted HTTP request to PHP.

Is my site vulnerable if it hides the PHP version?

Hiding the version (expose_php = Off) doesn’t fix anything; it only makes the version harder to see from outside. Check on the server itself.

Do I need to patch if I use a CDN or WAF?

Yes. Cloudflare and other providers have shipped rules for known attack patterns, but they only cover known vectors. Treat a WAF as a temporary shield, not a fix.

How do I stay ahead of the next one?

Subscribe to our free PHP security alerts — we email you when a critical PHP vulnerability or fix lands, with copy-paste remediation steps.