Share on social
October 22, 2026
Lorem ipsum
Whenever a new earth shattering vulnerability like php2shell is released on the internet, our research teams are always rushing to determine the best way we can notify our Assetnote customers about their exposure to it. We’ve had experience with this, both in vulnerabilities discovered by us (wp2shell), but also novel issues such as react2shell, late last year.
You can obtain our scanner on our GitHub here: http://github.com/assetnote/php2shell-scanner
When assessing other scanners released in the wild, we noted that most rely on version checks, or do not accurately depict vulnerable conditions for both mod_php and php-fpm. We decided to release our scanner logic that we implemented first in Searchlight's exposure platform for our customers, so that both our customers and the public can determine their exposure confidently.
Every time that we’ve worked through these issues, the fundamental problem of a reliable detection is the same. We want to maximise for coverage while minimising false positives and false negatives. As time goes on, these vulnerabilities are becoming more complex, and so are the detection mechanisms for them.
While our research team was working through understanding the vulnerabilities, we had difficult decisions to make around the detection logic for this issue. The initial information for the vulnerability, the onslaught of vibe-coded slop PoCs that came soon after, and finally the high quality writeup from Calif that ended a lot of the uncertainty.
The reliability for a check at Assetnote comes with high standards. We chose to build our detection mechanism to follow a progressive nature that first attempts to produce a PHP memory-exhaustion error, then attempts to observe a differential empty HTTP 500 (a PHP-FPM worker failure) and finally falls back to whether or not the target advertises a known unpatched PHP version.
Given that this vulnerability requires triggering an OOM condition, it is fundamentally risky in nature, but there is no reliable way to detect this without triggering this condition. The scanner that we are releasing chooses to trigger this condition where possible to accurately determine whether or not the host is patched. In the majority of PHP installations, a worker crash is quickly recovered from and should not lead to disruption, but care and caution should still be taken when using our scanner.