Online php2shell vulnerability check for your site
Is your website exposed to php2shell (CVE-2026-109618 / CVE-2026-109619)? Enter your address for an instant, passive, non-destructive verdict based on the PHP version your server reports — no attack traffic, one site at a time.
High-precision php2shell scanner — check your site
i What is php2shell? A flaw in how PHP parses multipart (file-upload) requests: deeply nested array keys can corrupt memory and, on affected builds, lead to remote code execution — turning a PHP app into a shell. Fixed in PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12; older branches (7.x / 8.0 / 8.1) get no fix.Passive and non-destructive — we only read the PHP version your server reports. One site at a time.
This is a passive check based on the version your server advertises in its HTTP headers — not an exploit attempt, and version banners can be hidden or backported. Always confirm against your actual PHP build.
What is php2shell?
php2shell is a memory-corruption flaw in PHP's multipart (file-upload)
request parser. A request whose form fields use deeply nested array keys can exhaust or
corrupt PHP's memory; on affected builds this can be driven to remote code
execution — turning a PHP app into an attacker shell. It is tracked as
CVE-2026-109618 and CVE-2026-109619 and was originally disclosed
by the Calif research team.
Which PHP versions are affected?
8.5.12Affected8.4.27Affected8.3.36Affected8.2.35AffectedIs this check safe?
Yes — it is passive. PALANIT makes a single ordinary HTTP request to your
site and reads the PHP version from the Server / X-Powered-By
headers, exactly like a browser or a link-preview. It does not send the
original scanner's ~29 MiB memory-exhaustion probes, so it can't crash your PHP-FPM
workers. Because of that, the verdict is a likelihood from the reported version — confirm
against your real PHP build before and after patching.
FAQ
What is the php2shell vulnerability (CVE-2026-109618 / CVE-2026-109619)?
php2shell is a flaw in how PHP parses multipart (file-upload) requests. A request with deeply nested array keys can corrupt PHP's memory; on affected builds this can escalate to remote code execution — effectively turning a PHP application into a shell. It was originally disclosed by the Calif team and tracked as CVE-2026-109618 and CVE-2026-109619.
Which PHP versions are affected?
The fix shipped in PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Any release below the fix on each branch is affected, and the end-of-life 7.x, 8.0 and 8.1 branches receive no fix at all. Update to the patched release (or newer) for your branch.
Is this online check safe to run on my site?
Yes. Our check is passive: it makes one ordinary HTTP request and reads the PHP version your server advertises in its Server / X-Powered-By headers. It never sends the destructive memory-exhaustion probes the original scanner uses, so it cannot crash your workers. The verdict is a likelihood from the reported version — not an exploit confirmation.
The check says ‘can’t determine’ — why?
Many hardened servers hide the PHP version (expose_php = Off) or strip it from the Server header. That is good hygiene, but it means an outside check can't read your exact build. Confirm locally that you run PHP 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 or newer.
How do I fix php2shell?
Upgrade PHP to the patched release for your branch (8.2.35, 8.3.36, 8.4.27 or 8.5.12 and up), or migrate off an end-of-life branch to a supported one. Rebuild containers and restart PHP-FPM / your web server so the new binary is actually in use.