Brief: scanner noise, how good the php2shell scanners and detection rules are
Status: accepted, research under way. Brief by Dinis Cruz (editor), spoken on 23 October 2026; written up by
researcher@php.newsroom. A research brief: an angle the source watch tracks as evidence, not as risk.
The ask, in the editor's words (summarised from the session)
Track the false positives the tools are creating. It's a cheeky comment, but an important one, and it should be one
of our research angles: how mature the tools are, how detectable the attacks are, how effective the tools are. Find
the sources of data, look for people commenting on it, and see how the noise flows.
What started it
Jeremiah Grossman, chief executive of Root Evidence, posted on LinkedIn on the evening of 22 October (UTC), going by the post's age in the editor's screenshot:
The false-positives for php2shell from makeshift scanners is what's going to be apocalyptic.
The picture is the top of the editor's screenshot, taken on 23 October and used with his go. LinkedIn gives the
watch a sign-in page, so this is the record of the post. The editor replied under it, pointing to this site: as of
the night before, there was no public record of companies being hit.
The questions
1. Method. How does each scanner decide that a host is vulnerable? Does it read the advertised version, or does
it try to produce the fault? A version check can't see a distribution backport.
2. False positives. Who reports a tool flagging a patched system as vulnerable, or ordinary traffic as an attack?
Which tool was it, and what did it see?
3. False negatives. Which rules and scanners miss what they are meant to catch, and who says so?
4. Volume. How much noise is there: bulk notifications, issues, tickets? Is it growing?
5. Maturity. Which tools are maintained and answer their bug reports, and which are one-off scripts?
What the watch holds already (23 October, 12:40 UTC)
Every row below is a captured page in the source watch (vault 7r83qic5, index/angles/scanner-noise.json), with
its snapshot and hash. Every quote was checked against the snapshot when the file was written.
| Kind | Who, where | What it shows |
|---|---|---|
| Scanner method | Searchlight Cyber, quoted by Help Net Security | "most rely on version checks, or do not accurately depict vulnerable conditions for both mod_php and php-fpm". Its own scanner tries to produce the fault first and reads the version only as a last resort. |
| False positive | An issue on a community check script, php2shell-check, on GitHub | The script reports Ubuntu's patched PHP (package 8.5.4-0ubuntu1.5) as vulnerable, because the version string is older than the fixed upstream release. |
| False negative | A community detection guide (a GitHub gist) | It withdraws its own earlier ModSecurity rule: "ModSecurity leaves REQUEST_BODY empty for multipart requests, so that rule never fires." |
| Claim to test | The same guide | It says its replacement rule "has zero false positives by construction". |
| Bulk notification | A templated GitHub issue, "Heads up: this repo pins a PHP version affected by PHP2Shell" | 53 issues at 12:38 UTC, opened by one account. The repositories include training repositories and an intentionally vulnerable challenge set. The template says it may itself be a false positive, or that the image may already carry a distro backport. |
| Volume | GitHub issue search for php2shell "false positive" | 62 results at 12:38 UTC, the templated notification among them. |
| Detection limits | Cloudflare | The request alone doesn't always separate an exploit from legitimate traffic. The origin's response "adds context, helping identify whether an exploit succeeded while reducing the risk of false positives". |
| Detection limits | Equixly, citing Huntress | Host detections need a baseline first, "because both can produce false positives". |
| Coverage | The OWASP Core Rule Set | An open request for more PHP2Shell signatures. |
| Scanner templates | nuclei-templates | 10 issues naming php2shell. Two merged pull requests are tracked in the watch's series. |
| Scanner releases | Help Net Security; Digital Today (Korea) | Searchlight Cyber's open-source scanner, and a free check service from Stealien. |
What it already shows, without going further: at least one scanner maker says most of the scanners in circulation
read the version string. One user has reported exactly the error that predicts. And one person's bulk notifications
reach dozens of repositories that the notifications themselves say may not be affected.
What the watch measures, every pass
- GitHub issue search:
php2shell "false positive"(62 at first capture) - GitHub issue search for the templated notification (53)
- nuclei-templates issues naming php2shell (10), and the merged pull requests already in the series
- Hacker News comments matching
php2shell scanner(the Algolia API) - the issue trackers of the community detection repositories it already captures
Each count is what the search page showed at the time of capture, with the capture's hash. A count moving is a
change in the watch's analysis, like any other series.
Where the watch can't see, and who looks instead
Reddit search, X, Bluesky and LinkedIn give the watch a sign-in page or a bot challenge. Since this brief, the watch
classes the Bluesky and LinkedIn pages as a login wall, not open. Community spaces are where people complain about
their scanners, so this angle depends on an external collector. Perplexity's brief, written the same day, carries
the scanner question as its first one (job 03 in the watch vault).
What it cannot do
- A false-positive report is one person's account. It's recorded as what they said, quoted and linked, not as a
verdict on the tool. A tool's maker answering the report is the next piece of evidence.
- Counts from search pages are rough. GitHub's search counts move as its index updates. They are tracked as
what the page showed, not as an exact number of events.
- No private people are named. Repositories and tools are named as places; the people who opened the issues
are not.
- This maps evidence, not risk. The angle doesn't say whether scanners make the internet safer or less safe. It
records what the tools do and what people report about them.
Deliverables
- Done (vault
oq9gflln): index/angles/scanner-noise.json(12 rows)- 7 new watched pages: four issue and search pages tracked hourly, the Hacker News search, and the two issues
above
- the login-wall fix
false-positive,false-negativeandpractitioner-reportadded to the kinds a collector can report- Next:
- a section of the cyber desk's analysis on scanner method, once there are more reports than the ones above
- a table on the site once the counts have moved for a day
Decided by the editor (23 October)
1. The post is recorded from the editor's screenshot, cropped to the post itself, with its link.
2. Testing the scanners in a lab is a task for later, not for now. It's on the board, owned by the cyber desk: run the
public scanners against a distribution-patched PHP (for example Ubuntu's 8.5.4-0ubuntu1.5) and an unpatched
one, in an isolated lab, and record which ones get each right. It tests the tools, never anyone's systems, and it
starts only on the editor's go.