PHP vulnerability scanners compared
Last updated 22 October 2026. Written by PHP Patch Assurance — we make one of the tools below (phpatchscan) and the patch service in the last row, so check our work: every entry links to its own project, and every claim below is taken from that project's documentation.
Within a day of the php2shell disclosure (CVE-2026-109618 / CVE-2026-109619, 21 October 2026), dozens of scanners appeared. They are not interchangeable. They differ in the one way that matters most — how they decide you are vulnerable — and in what happens after the verdict. This page compares the ones people actually ask about, on the criteria that separate them.
The criteria that actually differ
- Detection method. A version fingerprint reads the PHP version a site discloses and compares it with the fixed releases. A behavioral probe tries to reproduce the fault — for php2shell, that means forcing PHP to run out of memory — and watches how the host reacts. A local behavior check runs the same idea against the PHP binary on the host itself.
- Exploit triggers. Does the tool send requests designed to trigger the vulnerability, yes or no? On a production site this is the difference between "sent you ordinary traffic" and "tried to crash your PHP workers on purpose".
- After the verdict. Every scanner stops at detection. Remediation — applying the fixed release, verifying it, and proving it — is a separate step, and it is where most incidents stall.
- SSRF safety. A scanner that fetches arbitrary URLs can be pointed at internal networks and cloud metadata endpoints unless it is built to refuse. That matters most for hosted scanners, but it is a fair question for any of them.
- License and dependencies. What you may legally run, and what you have to install to run it.
The comparison
| Tool | Detection method | Sends exploit triggers? | After a ‘vulnerable’ verdict | SSRF hardening | Runs on | License |
|---|---|---|---|---|---|---|
| OpenAI php2shell-checker github.com/openai/php2shell-checker |
Version fingerprint — reads the X-Powered-By and
Server headers (HEAD, GET fallback), or
php -v locally |
No — reads headers only; does not follow redirects or inspect response bodies | Detection only | Not documented | Node.js; also packaged as a Codex skill | Apache-2.0 |
| Searchlight Cyber php2shell-scanner (Assetnote) github.com/assetnote/php2shell-scanner |
Behavioral first — crafted multipart probes force PHP out of memory and watch for the crash signature (memory-exhaustion error, empty HTTP 500, dead FPM worker); version check as a last resort | Yes — deliberately triggers the out-of-memory condition; up to ~29 MB of probes per tested path | Detection only | Not documented | Python 3.9+ plus pip packages (h11, tqdm) | No LICENSE file in the repo |
| SamJUK php2shell-check github.com/SamJUK/php2shell-check-cve-2026-109618 |
Behavioral, on the host — runs the PHP CLI binary under an 8 MiB memory limit and observes how it terminates (patched builds hard-exit; unpatched builds run shutdown code on stale state) | Only against a throwaway local CLI process — it sends no network requests at all | Detection only | N/A — nothing is fetched over the network | Shell script plus the PHP binary under test; run it inside every container you deploy | MIT |
| squiblyza php_vuln_scan github.com/squiblyza/CVE-2026-109618-CVE-2026-109619 |
Version fingerprint from response headers and page markup; an optional mode makes ~15 further ordinary GETs hunting for the version in exposed phpinfo or debug pages and composer files; optional historical banners from Shodan | No — ordinary GET requests only; it never attempts to trigger either vulnerability | Detection only | Not documented | Python 3.8+, standard library only | MIT |
| JoasASantos php2shell-scanner github.com/JoasASantos/php2shell-scanner |
Version fingerprint (headers, exposed phpinfo, PHP easter-egg URLs, version-leak files) plus subdomain reconnaissance; can also scan the origin server directly, bypassing a CDN/WAF | Optional — an opt-in probe sends large multipart requests to observe worker instability; its README warns it may cause a denial of service | Detection only | Not documented | Python, standard library only (optional subfinder for recon) | README states MIT; no LICENSE file in the repo |
| phpatchscan (ours) github.com/PHPatch/phpatchscan |
Version fingerprint from what the site discloses (headers, generator tags, an exposed phpinfo page), judged against a maintained advisory database; when the version is hidden it says so — indeterminate — instead of guessing | No — never. Nothing in the tool attempts to trigger a vulnerability | Detection only — and it is the front end of the patch service below | Yes — refuses loopback, private and link-local addresses (including cloud metadata endpoints), pins the validated IP, re-validates every redirect; the refusals are exercised by its test suite on every push | Python 3.11+, standard library only; also hosted free at phpatch.com | MIT |
| PHP Patch Assurance (service) phpatch.com |
The same passive scan; then, only after you prove ownership and approve a written plan, a read-only on-server inventory of every PHP runtime on the host | No — the fix is a normal upgrade to the fixed release, never an exploit test | Remediation — restore-tested snapshot, patch, verify-before-swap, automatic revert on failure, one-click rollback, and an evidence report with a SHA-256 integrity hash. $49 per runtime, $99 with the rollback tier; yearly care plans ($299/$399) launch soon | The hosted scanner has the same SSRF refusals, plus rate limits and an operator opt-out | Hosted — nothing to install; free scan, no signup | Service; the scanner is MIT open source |
A fairness note. Behavioral detection answers a question
version checks cannot: is the fault actually reachable on this
host? It also handles distribution backports — a vendor may
ship the fix without changing the version string, and a version
check then cries wolf while SamJUK's local check, which tests the
binary's behavior rather than its banner, does not. Behavioral
checking has the opposite failure mode: the crash signal is not
proof. Searchlight's own documentation records false positives on
patched PHP (8.4.27 at low memory_limit values, 8.3.36
at higher ones), because a safe post-patch out-of-memory error can
look identical to the vulnerable one. And no external check, of
either kind, can prove a negative about a server that hides its
version. Read any verdict — including ours — with those limits in
mind.
How to choose
- You need to know your exposure, safely, right now — use a passive scanner: the hosted scan or phpatchscan locally. Ordinary requests, an honest verdict, nothing triggered.
- You run servers and want ground truth on a binary, backports included — SamJUK's local behavior check, inside each container.
- You do authorized security assessments and can accept crashed workers — the behavioral scanners, in a maintenance window, on assets you are permitted to test.
- You need the problem gone, with proof — a scanner is the diagnosis, not the treatment. That is the row at the bottom of the table.
Frequently asked questions
How do I check if my PHP site is vulnerable to php2shell?
Compare the PHP version serving your site with the fixed
releases: 8.2.35, 8.3.36, 8.4.27, 8.5.12. Anything lower on
its branch is affected; anything on PHP 8.1 or older is
end-of-life with no upstream fix. The fastest check is a passive
scanner — run phpatchscan locally
(git clone https://github.com/PHPatch/phpatchscan.git)
or the free hosted scan — which reads the
version your site discloses. If your site hides its version, a
common hardening step, no external tool can judge it: check
php -v on the server itself, or use an on-server
inventory such as our read-only deep check, which runs after you
prove ownership.
Which PHP versions are affected by CVE-2026-109618?
CVE-2026-109618 (remote code execution via out-of-memory corruption) and its sibling CVE-2026-109619 (RCE via stale global state) affect PHP below the security releases of 21 October 2026: below 8.2.35 on the 8.2 branch, below 8.3.36 on 8.3, below 8.4.27 on 8.4, and below 8.5.12 on 8.5. Both are rated CVSS 9.2. PHP 8.1 and older receive no upstream fix. Sources: the PHP announcement of 21 October 2026 and advisories GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp.
Is it safe to run a php2shell scanner against my site?
It depends on the method. Passive scanners — version fingerprinting — send ordinary requests, the same traffic your site already serves, and are safe to run; with any scanner, only scan sites you own or are authorized to test. Behavioral scanners are different: they deliberately force PHP to run out of memory, which is the vulnerable condition itself. On an unpatched host that can kill PHP workers mid-request, and the same crash signature occurs on some patched configurations, so a behavioral result can disrupt as well as mislead. If you want a behavioral answer, prefer the local kind, which stresses a disposable CLI process on your own host, or run remote probes in a maintenance window.
What do I do if my PHP is end-of-life (below 8.2)?
There is no upstream patch, so the honest options are: (1) upgrade the branch — for example 8.1 to 8.2.35 — after a compatibility pass (removed functions, deprecations, extension rebuilds); (2) check whether your operating-system or panel vendor ships a backport of the fix — distribution packages sometimes patch without changing the version string, and your vendor's security tracker is the source of truth; (3) apply the configuration stopgaps from the PHP advisory to shrink the exposure while you migrate — they reduce risk, they do not fix the bug; or (4) take the runtime offline until it can be upgraded. Our patch service performs option (1) for Docker runtimes as a snapshot-first branch upgrade with verified rollback.
php2shell scanner vs patch service — what's the difference?
A scanner gives you a verdict: exposed or not, at one moment in time. A patch service changes the server — it snapshots the runtime, restore-tests the snapshot, applies the fixed release, verifies the result before the change takes traffic, reverts automatically if post-change checks fail, and hands you an evidence report of what was done. Most of the risk in an incident like php2shell sits between those two steps: knowing, and fixing. The scanner is free and open source; the patch is the paid step ($49 per runtime, $99 with the rollback tier).
My scan says ‘version hidden’ — does that mean I am safe?
No. It means your site does not disclose its PHP version, so
no external tool can judge the patch level. Hiding the version is
good hardening and a non-answer at the same time. The definitive
check runs where the version is known: php -v on the
host, or a read-only server inventory — ours runs over SSH after
you prove you own the site, and reports every PHP runtime it
finds, per SAPI and per container.
Sources
- PHP announcement, 21 October 2026 — php.net; advisories GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp.
- Each tool's own repository, linked in the table, read on 22 October 2026.
- Searchlight Cyber / Assetnote scanner coverage — Help Net Security, 22 October 2026.
Superstar Telecom LLC · phpatch.com ·
Free scan · Security &
disclosure
Not affiliated with the PHP Group. PHP
is a trademark of the PHP Group.