aancw/php2shell-scanner

A focused detector for two PHP core RCEs, useful if you run PHP and need a quick exposure answer. It is not a general vulnerability scanner, and the repository's own lab is the only published verification.

The problem

After the PHP2Shell advisories were published on 2026-10-21, an operator wants to know which of their PHP hosts are exposed before an attacker finds out. Normally that means checking PHP versions and a handful of ini settings by hand on every host, and guessing whether a blackbox target's headers reveal enough. This scanner changes that: you point it at a URL, at the local machine, or at hosts over SSH, and it returns per-target findings with severities, including version, SAPI and the session.upload_progress and related ini values that decide exploitability. Unreachable targets get a SCAN_FAILED finding rather than stopping the whole run.

What's different

The three modes map to three levels of access. url needs no shell access and tries to infer the PHP version from headers, body, or an exposed phpinfo page; local and ssh inspect interpreters, ini files, FPM pools and web server configuration on disk. The author's distinction between CLI and web ini, and the claim that session.upload_progress.enabled=0 in a .user.ini is too late, is the kind of detail that makes a host-mode result more than a version comparison. The tool sends a benign session.upload_progress arming probe and contains no PHP code unless --canary is passed, so it is explicitly framed as a detector, not an exploit.

The trade-off is scope and evidence. It checks only these two CVEs and the configuration factors the README lists; it is not a substitute for a patch-management or broader vulnerability workflow. Verification is reported against the author's linked offline lab and a php:8.3.35-apache container, which is useful but not an independent field test. Blackbox results depend on what a target exposes, so a clean URL scan is not proof that the host is not exposed.

Who should try it

Good fit: a PHP operator or sysadmin with shell or SSH access to a small fleet who wants to triage these specific advisories quickly, and who can run the binary against hosts they own or are authorized to test. A CI or scheduled check using --json and --fail-on is a plausible secondary use if the environment already has the required access. Poor fit: someone looking for ongoing, general PHP vulnerability management, or anyone who cannot get shell/SSH access, since the blackbox mode is necessarily shallower. The local mode is also a poor fit for containerized targets unless you copy the binary into the container, as the README describes.

Requirements and limitations

The README offers prebuilt statically linked binaries for Linux (amd64, arm64, armv6), macOS (Intel and Apple Silicon) and Windows x86_64, so most users do not need a Go toolchain; building from source is documented for container use. The scanner needs network access to targets for url mode and SSH credentials, keys or an agent for ssh mode; the same credentials are used for every host in a run, which matters if your fleet has per-host accounts. Binaries are distributed with a SHA256SUMS file, and the README links disclaimer and responsibility and limits use to systems you own or have written permission to test. A young project with a narrow CVE list means you should re-check the fix-version table against PHP's own advisories rather than treating the scanner's table as authoritative.

HotRepo's take

The repository was created on 2026-10-22, and on the 2026-10-25 NEW-REPOSITORY board (not the overall Trending board) it was recorded at #12 with 69 total stars. That is two dated snapshots, not a daily growth series, so persistence cannot be judged. The practical question is whether you need this specific check now; if you do, verify the fix-version table and the target-access assumptions against your own fleet before relying on a scan result.