How do I fix PHP2Shell?

Upgrade to 8.2.35, 8.3.36, 8.4.27 or 8.5.12. On 8.1 or older there is no release: move to a supported branch, or take the host off the internet until you can. Restart PHP-FPM, Apache, LiteSpeed or whichever worker holds the old binary. A package update alone leaves the running process unpatched. Verify the version the live site reports, not the one the CLI prints. They differ more often than you would think. Run this check again. If you cannot patch today, put the host behind a login or an allowlist. WAF rules on nested multipart names slow the known exploit but do not close the bug.

Intelsieve/ check intelsieve.com →

php2shell · oct 2026

Is your domain affected by PHP2Shell?

Enter a domain. We check every host we find on it and tell you which are still running affected PHP.

hosts

php

affected

fixed

unknown

host	status	version	evidence	fix

unknown does not mean safe. A host that hides its version could still be vulnerable — only php -v on the box confirms it. Distribution builds that backport the fix keep an old version string and will read as affected here.

Keep watching

Free weekly rescans of every subdomain we find. Just a work email to start.

Monitor free

What it is

Two bugs in the part of PHP that reads form uploads

Every PHP request that carries a form body goes through the multipart parser before any application code runs. A crafted body with deeply nested field names makes that parser run out of memory (CVE-2026-109618), and the way PHP recovers from that failure leaves stale state behind that a second request can turn into code execution (CVE-2026-109619).

No login, no plugin, no bug in your application is needed. If a host runs an affected PHP and accepts a POST, it is reachable. With mod_php the exploit lands before the application ever sees the request, so WordPress, Drupal, Magento or Laravel being up to date does not help. Only the PHP runtime matters.

WordPressDrupalJoomlaMagentoLaravelSymfonyMediaWikiphpBBWHMCSanything else on PHP

Timeline

Days from leak to exploitation

20 Oct 2026Details leak ahead of the coordinated release. Working proof-of-concept code circulates the same day.

21 Oct 2026PHP publishes fixed releases for 8.2, 8.3, 8.4 and 8.5. Distributions begin backporting.

21–22 OctExploitation in the wild reported by several vendors. Government advisories follow.

What to do

Patch the runtime, restart the workers, verify from outside

Upgrade to 8.2.35, 8.3.36, 8.4.27 or 8.5.12. On 8.1 or older there is no release: move to a supported branch, or take the host off the internet until you can.
Restart PHP-FPM, Apache, LiteSpeed or whichever worker holds the old binary. A package update alone leaves the running process unpatched.
Verify the version the live site reports, not the one the CLI prints. They differ more often than you would think. Run this check again.
If you cannot patch today, put the host behind a login or an allowlist. WAF rules on nested multipart names slow the known exploit but do not close the bug.

How this check works

What we send and what we don't

We look up hostnames for your domain, check what PHP version each one reports, and flag the ones running affected builds. No exploit code, no request body.

There are limits to what a passive check can tell. A host that hides its version reads as unknown, and a distribution build that backports the fix without changing the version string reads as affected. A host behind a CDN or reverse proxy that strips server headers may show as 'not php' even when PHP is running behind it. All three need a look from inside. Results are kept for 24 hours so a repeat check is free, and are not indexed.

References

Upstream is the source of truth

PHP releases watchTowr: exploitation in the wild watchTowr: fixes and FAQ Imperva: technical analysis Recorded Future: two flaws explained Ubuntu: fixes available CSA Singapore alert

Initial discovery is credited to the researcher LCFR in the PHP advisories.