After the PHP2Shell release (CVE-2026-109618 and CVE-2026-109619, php.net advisory of 21 October 2026), many people ran a scanner or asked an AI agent whether their servers are fixed. On some systems, the answer comes back wrong in both directions.
Disclosure: we run php2shell.fyi, a passive checker for PHP2Shell.
Wrong answer 1: a fixed server shows as vulnerable
The PHP project fixed the flaws in PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Some distributions put the fix into the version they already ship and keep the old upstream number:
| System | Fixed build |
php -v shows |
|---|---|---|
| Ubuntu 24.04 |
php8.3 8.3.6-0ubuntu0.24.04.13 (USN-8948-1) |
8.3.6 |
| Ubuntu 22.04 |
php8.1 8.1.2-1ubuntu2.28 (USN-8948-1) |
8.1.2 |
| RHEL 9 |
php-8.0.30-8.el9_8.1 (RHSA-2026:87151) |
8.0.30 |
| Chainguard |
php-8.4 8.4.26-r4
|
8.4.26 |
A tool that reads only 8.3.6 and compares it with 8.3.36 says "vulnerable". The ProjectDiscovery Nuclei template for CVE-2026-109618 does this in its version fallback, and so does the Assetnote scanner when it sees no crash signal. Some community agent skills do the same with sort -V.
Not every distribution does this. Debian, Alpine, the RHEL modules and RHEL 10 ship the new upstream numbers, for example Debian 13 8.4.27-1~deb13u1.
Wrong answer 2: an old branch shows as not affected
The CVE record for CVE-2026-109618 lists only the 8.2, 8.3, 8.4 and 8.5 branches as affected, and marks every other version as unaffected (cve.org, checked 23 October 2026). A scanner that reads the record literally can call PHP 8.1 and older "not affected".
They are affected. The PHP security team published source fixes for 7.4, 8.0 and 8.1, and the researchers found affected releases back to PHP 5.4 (php2shell.com).
How to check the real build
Read the package version of the PHP that serves the site, not only php -v:
# Debian and Ubuntu
dpkg -l 'php*' | grep '^ii'
# RHEL, AlmaLinux, Rocky
rpm -qa 'php*'
# Alpine and Wolfi
apk info -v | grep '^php'
Compare the full version with the fixed build in your vendor's notice. On Debian and Ubuntu, dpkg --compare-versions does this correctly; on RPM systems, compare within the same release and stream.
Then check that PHP restarted. An installed package does not change PHP processes that are already running:
ps -eo pid,lstart,cmd | grep -i '[p]hp'
A PHP-FPM, Apache or LiteSpeed process that started before the update still runs the old code.
If you use an AI agent
Tell it which comparison to use. For example: "Compare the full package version with the vendor's fixed build. Do not compare php -v with upstream numbers. If you cannot verify a version, report it as unknown." The agent skills from OpenAI (phpcheck-server), Cognition (fix-php-vuln) and Chainguard already work this way.
The fixed builds for Ubuntu, Debian, RHEL and Alpine, with the vendor links, are on php2shell.fyi/linux.
Top comments (0)