DEV Community: Norminal Solutions

Why your scanner or AI agent can call a fixed PHP server vulnerable

Norminal Solutions — Fri, 23 Oct 2026 22:48:02 +0000

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.

AI agent skills for PHP2Shell: what each one checks

Norminal Solutions — Fri, 23 Oct 2026 18:34:04 +0000

PHP2Shell (CVE-2026-109618 and CVE-2026-109619) is a pair of flaws in PHP itself. The PHP project fixed them on 21 October 2026 in PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12 (php.net advisory).

Within two days, several teams published skills for coding and operations agents (Claude Code, Codex, Devin and others) that look for affected PHP and help update it. We read the skill files of the ones below. This post lists what each one inspects, how it decides whether a build has the fix, and whether it waits for your approval before it changes anything.

Disclosure: we run php2shell.fyi, a passive checker for PHP2Shell. None of the tools below is ours.

The question that matters most

Some Linux distributions ship the fix under the old version number. Ubuntu 24.04 has the fix in php8.3 8.3.6-0ubuntu0.24.04.13 (USN-8948-1). RHEL 9 has it in php-8.0.30-8.el9_8.1 (RHSA-2026:87151). Chainguard has it in 8.4.26-r4.

A tool that compares only the upstream number (8.3.6 is lower than 8.3.36) reports these fixed servers as vulnerable. An agent that trusts that answer may try to "fix" a server that is already fixed. So the first column we checked is: does the tool compare the full package version?

The skills

Skill	Publisher	What it inspects	Full package version?	Changes
`phpcheck-server`	OpenAI	The PHP binary or Apache module that serves the site, its package, the OS, containers	Yes	Check only
`phpcheck-url`	OpenAI	The `Server` and `X-Powered-By` headers of one URL	No, and it says so	Check only
`fix-php-vuln`	Cognition	Repositories: Dockerfiles, CI, Helm, Terraform, Ansible, Chef, Puppet	Yes	Only after you pick the repos; then one pull request per repo
`php2shell`	Chainguard	Chainguard and Wolfi images, SBOMs, Kubernetes workloads	Yes (apk revisions)	Each change needs approval
`php2shell-response`	Iurii Rogulia (community)	Hosts, images, hosting accounts, repositories	Yes	Read-only unless you say otherwise

What the skill files say, in their own words:

OpenAI phpcheck-server: "Compare the full package revision against vendor guidance covering both CVEs. An older upstream version alone does not prove vulnerability." It also asks whether the web workers restarted after the update, and says: "Do not run exploit probes."
OpenAI phpcheck-url: "HTTP headers cannot tell whether the version contains a backported fix." Use it for a first look, not for a verdict.
Cognition fix-php-vuln: "Never compare php -v with upstream numbers to decide this." Discovery ends with: "Stop. Show the table and ask which repos to patch."
Chainguard php2shell: "Every change needs the user's explicit approval first". It also warns: "Never compare version strings as text (-r10 is newer than -r4)".
php2shell-response: "A distribution package may carry the fix under an older version number: check the vendor changelog or advisory, never compare version strings alone." Its mode: "Read-only unless the user says otherwise."

Tools that compare only the upstream number

These are useful, but read their "vulnerable" answer as a question, not a verdict, on Ubuntu, RHEL and Chainguard:

The ProjectDiscovery Nuclei template for CVE-2026-109618. Its version fallback marks a patch number below the fixed one as vulnerable, so 8.3.6-0ubuntu0.24.04.13 counts as vulnerable. It also marks every version below 8.2 as end of life.
The Assetnote scanner. When it sees no crash signal, it falls back to the X-Powered-By number with the same comparison.
Some community skills compare versions with sort -V on the upstream number only.

Before you let an agent change a server

Give it read access first, and ask for a table: runtime, path, version, package, status.
Check that it reads the PHP that serves the site (PHP-FPM, the Apache module, LiteSpeed), not only php -v on the command line.
Ask it to show the restart step. Old PHP processes keep the old code until they stop. ps -eo pid,lstart,cmd | grep -i '[p]hp' shows when each one started.
Do not let it fetch or run public proof-of-concept code. Most public PHP2Shell "PoC" repositories are attack tools, and their code is not reviewed.

We keep a read-first prompt, our own SKILL.md and this comparison up to date on php2shell.fyi/ai-agents. The fixed releases, the distribution builds and the mitigations are on php2shell.fyi, with a source for each fact.