php2shell-checker is a small JavaScript CLI from openai/php2shell-checker that compares a website's exposed PHP version, or a local php -v string, against embedded patch cutoffs for authorized vulnerability assessment.
| Tool | openai/php2shell-checker — JavaScript CLI that checks a remote site or local PHP binary against embedded php2shell patch cutoffs |
| Primary Use | Triaging whether a PHP deployment is at or below a known patch cutoff, using X-Powered-By/Server headers or php -v, with JSON output and exit codes for pipeline integration |
| Primary Use | Quick authorized exposure triage of PHP versions during asset inventories, patch audits, and lab validation |
| Safe Use | Intended for defenders and authorized security teams assessing systems they own or have written permission to test; it performs passive version checks only |
| Telemetry Note | The URL mode sends only HEAD requests (with a GET fallback on 405/501), so its footprint is a single lightweight request visible in standard HTTP access logs; it sends no payloads |
openai/php2shell-checker is a compact JavaScript utility published under the Apache-2.0 license that answers a narrow but operationally useful question: is the PHP version running on a given site, or installed locally, at or below the patch cutoffs associated with the php2shell vulnerability class? Rather than performing any exploitation or even active fingerprinting beyond simple HTTP semantics, it treats version disclosure itself as the signal. The repository currently sits at 693 stars on main, which is notable traction for such a focused single-purpose checker, and the code ships with its own test suite, a clear sign the author intended it for pipeline use rather than as a throwaway script.
The tool ships in two consumption models, and the README is explicit about both. The first is skill-based integration for Codex: a $skill-installer install both skills from https://github.com/openai/php2shell-checker invocation registers two skills, phpcheck-server and phpcheck-url, which map to whether you have shell access to the host or only a URL. The second is direct execution via node phpcheck.js, which is the path most operators writing their own automation will take. This dual packaging is interesting architecturally: the same core logic is exposed both as an interactive assistant skill and as a conventional CLI, meaning the version-comparison engine is cleanly separated from the interface layer.
Operationally the tool supports two targets. Running node phpcheck.js "https://example.com" checks a remote site, while node phpcheck.js --local inspects the local CLI PHP by invoking php -v. The remote path is deliberately conservative in its HTTP behavior: it sends a HEAD request and reads the X-Powered-By and Server response headers, falling back to GET only when the server answers HEAD with 405 or 501. It does not follow redirects and never inspects response bodies. This makes it one of the least intrusive reconnaissance-adjacent tools you will encounter — a single request, no content parsing, no payload delivery — which is exactly what you want when scanning assets you are authorized to assess but do not control at the network level.
The result model is a textbook example of exit-code-driven design for CI/CD and scripting. OK exits 0 and means the detected stable patch version sits above the embedded cutoff for its major/minor branch. VULNERABLE exits 1 when the version is at or below that branch cutoff. UNKNOWN exits 3 and covers the realistic failure modes: no PHP version disclosed in headers, no response at all, an unrecognized version or branch, or a prerelease build newer than the embedded table. Invalid arguments exit 2, keeping the argument-error channel distinct from the assessment channel. Adding --json switches to machine-readable output where patch_status takes the values ok, vulnerable, or unknown, which drops cleanly into a report aggregator or a scheduled audit job.
The embedded cutoff table is the heart of the design and also its main epistemic weakness, which the README addresses with unusual candor. The OK verdict is a pure version comparison that assumes subsequent stable patches within each listed branch contain the fix; the tool does not independently verify that a security fix is present. The README explicitly warns that headers can be hidden or spoofed, and — critically for anyone running this against enterprise Linux — that distribution backports may patch the vulnerability without bumping the upstream version string. In other words, a VULNERABLE result on a Debian or RHEL-managed PHP is a lead to investigate, not a verdict, and the author tells you so directly.
Equally important is the README's blunt clarification that UNKNOWN does not mean the target is patched. This is the correct framing for any version-header-based screener. Hardened deployments routinely strip X-Powered-By and minimize Server tokens precisely to defeat this class of tool, so a UNKNOWN result against a well-configured target is expected noise, not a clean bill of health. For an authorized assessor, the practical workflow is to treat the tool as a fast first pass across an inventory, then reconcile any VULNERABLE or UNKNOWN results against the official PHP security release notes and configuration management data before drawing conclusions.
The testing story reinforces the quality bar. node --test phpcheck.test.js runs the CLI against local HTTP servers and a fake PHP executable, with no PHP installation and no external website required. That detail matters for two reasons. First, it means the test suite exercises the real HTTP decision path — the HEAD-then-GET fallback logic and header parsing — rather than mocking at the function level. Second, a fake PHP executable standing in for php -v output shows the local path is tested against arbitrary version strings, including presumably the edge cases that produce UNKNOWN. For a tool whose entire value is correct version comparison, this is the right test strategy.
Where does this fit in an authorized workflow? The obvious home is asset inventory and patch-gap auditing: point it at hosts you own, collect --json output centrally, and use the exit codes to drive ticketing. The --local mode is a natural fit for golden-image validation in a build pipeline — verifying that the PHP baked into a container or VM template is above cutoff before deployment. In an engagement context with proper scope authorization, the URL mode offers a low-impact way to triage PHP exposure across an in-scope web estate, generating a ranked list of candidates for deeper, properly scoped review. What it is not, and does not pretend to be, is an exploit or a scanner that verifies compromise.
Two governance notes from the README round out the picture. OpenAI is not accepting external code contributions to the project, limiting bug reports and non-code feedback to GitHub issues — relevant if you are evaluating supply-chain and maintenance expectations. And the Apache-2.0 license permits internal modification, so teams that need to extend the embedded cutoff table or add redirect handling can fork it cleanly. As a defensive instrument, php2shell-checker embodies a good pattern: minimal network footprint, honest semantics, machine-readable output, and documented limitations that tell the operator exactly where the tool's knowledge ends.
openai/php2shell-checker.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.