The PHP Foundation describes its own use of AI for this release like this: "AI helps the team validate reports and group reports sharing the same root cause, but a person makes every call and works on every patch" (PHP Foundation, 21 October 2026). The same rule works on your servers: let the agent read and propose, and keep the changes for yourself to approve.

Disclosure: we run php2shell.fyi, a passive checker for PHP2Shell.

The prompt

Replace https://your-site.example/ with your own site. Give the agent access only to systems you own or run.

You have access to the server or repository behind https://your-site.example/. Check it for PHP2Shell (CVE-2026-109618 and CVE-2026-109619) and help me fix it.

1. Inventory every PHP runtime: CLI, PHP-FPM pools, Apache mod_php, php-cgi, LiteSpeed lsphp, FrankenPHP, cPanel/Plesk/Remi builds under /opt, containers and images, CI jobs. In a repository, read Dockerfiles, compose files, CI configs and composer.json (require.php, config.platform.php).
2. For each one, record the version (php -v, php-fpmX.Y -v) and the package build (dpkg -l, rpm -qa or apk info -v, filtered to php).
3. Compare with the fixed releases: 8.2.35, 8.3.36, 8.4.27 and 8.5.12 or later in the same branch. PHP 8.1 and older get no upstream release. A distribution build can carry the fix under an old number: compare the full package version with the vendor's advisory.
4. Propose the upgrade: exact commands, services to restart, expected downtime. Ask me before you run anything that installs, removes, restarts or edits, and before you create any file in the web root (no phpinfo files).
5. After my approval: take a backup or snapshot, update, restart every PHP worker (and lsphp in LiteSpeed detached mode), rebuild images, then verify the version, the package, that every PHP process started after the update (ps -eo pid,lstart,cmd) and X-Powered-By (curl -sIL).
6. Report a table: runtime, path, version, package, status (fixed, not fixed, unknown) and what is left to do.

Never send exploit probes to any site. Do not paste secrets or environment values (php -i and ps can show them) into your report. If you cannot verify a version, report it as unknown.

The same steps are also a skill file for agents that load skills, such as Claude Code: SKILL.md. It is text only. Read it before you install it.

Why each line is there

• Step 1 lists runtimes, not sites. The command-line php is often not the PHP that serves the site. Panels such as cPanel and Plesk install their own PHP builds next to the system ones.
• Step 3 names the backport trap. Ubuntu 24.04 has the fix in 8.3.6-0ubuntu0.24.04.13 (USN-8948-1), so php -v still says 8.3.6. An agent that compares 8.3.6 with 8.3.36 would "fix" a fixed server.
• Step 4 is the approval gate. The agent stops before any install, restart or edit. It also must not leave a phpinfo() file online: that page shows paths, settings and environment values.
• Step 5 checks the restart. An installed package does not change PHP processes that are already running.
• The last lines keep it defensive. No exploit probes against any site, and no secrets in the report.

Until you can update

If one runtime cannot be updated yet, the PHP project lists measures that reduce specific attack paths, such as session.upload_progress.enabled=0 set in php.ini or the FPM pool, not with ini_set(). On 23 October 2026, php.net also suggested keeping that setting off until the next regular bugfix release, even on the fixed releases (informational advisory, CVE-2026-115560). The full list, with a source for each measure, is on php2shell.fyi/mitigations.

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:

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.

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

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.

Is the server exposed? Maybe not. This article shows how to get a real answer in about five minutes.

Why the number can lie

PHP2Shell (CVE-2026-109618 and CVE-2026-109619, CVSS 9.2) is a pair of flaws in PHP itself, not in WordPress, Laravel or any other app. The PHP project published the fixes on 21 October 2026 (GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp). The research is on php2shell.com.

Linux distributions do not jump to a new upstream release in a stable branch. They take the fix, apply it to the version they already ship, and add a build number to the package version. So the upstream number stays the same, and only the package version changes:

These are the versions published by each vendor as of 22 October 2026. Vendors add and change entries, so confirm on your vendor's security tracker before you decide.

The important part: php -v and the X-Powered-By header both show only 8.3.6. Neither shows the -0ubuntu0.24.04.13 part. To know, you have to read the package.

Step 1: find the PHP that serves your site

php -v answers for the command-line PHP. Your site runs on PHP-FPM, Apache mod_php or php-cgi, and that can be a different install. Find the one that serves requests first.

# PHP-FPM services that are running
systemctl list-units --type=service 'php*'

# Apache with mod_php?
apachectl -M 2>/dev/null | grep -i php

On Debian and Ubuntu, each branch has its own FPM binary:

php-fpm8.3 -v

On RHEL, AlmaLinux and Rocky it is php-fpm -v. If you are still not sure, put a phpinfo() page on the site, read the Server API line, and delete the page right after.

More than one branch on the box is common, for example 8.1 for an old site and 8.3 for the rest. Every branch that serves a site counts.

Step 2: read the package version

Debian and Ubuntu:

dpkg-query -W -f='${Package} ${Version}\n' 'php*-fpm' 'php*-common' 'libapache2-mod-php*' 2>/dev/null

RHEL, AlmaLinux and Rocky:

rpm -q php-common php-fpm
dnf module list php   # the enabled stream is marked [e]

Alpine:

apk info -v | grep '^php'

Step 3: compare it with the fixed build

Do not compare by eye. Let the package manager do it. On Debian and Ubuntu:

installed=$(dpkg-query -W -f='${Version}' php8.3-fpm)
dpkg --compare-versions "$installed" ge "8.3.6-0ubuntu0.24.04.13" \
  && echo "at or above the fixed build" \
  || echo "older than the fixed build: update"

Put your own package name and your release's fixed version in the command. On RPM systems, rpmdev-vercmp (from rpmdevtools) does the same job.

Two traps:

• AlmaLinux and Rocky have their own build strings. AlmaLinux builds end in .alma.1, and Rocky module builds have their own suffix. Compare with your distribution's string, not with Red Hat's.
• Ubuntu 20.04 and older get the fix through Ubuntu Pro (ESM). Without Pro, apt upgrade does not install it.

Step 4: update, then restart

If the package is older than the fixed build, update it:

# Debian / Ubuntu
sudo apt update && sudo apt upgrade

# RHEL / AlmaLinux / Rocky
sudo dnf upgrade 'php*'

# Alpine
apk update && apk upgrade

Then restart. This is the step people forget. Running PHP processes keep the old code in memory until they stop, so a new package on disk changes nothing yet.

sudo systemctl restart php8.3-fpm   # use your branch
sudo systemctl restart apache2      # or httpd on RHEL

Restart queue workers, Laravel Octane, Symfony Messenger consumers and any other long-running PHP process too. Then repeat Step 1 and Step 2 to confirm what is running now.

Containers

docker restart keeps the old PHP, because the PHP is in the image. Pull the updated base image, rebuild your image and recreate the container. Official php images use upstream releases, so look for 8.2.35, 8.3.36, 8.4.27 or 8.5.12 there. Images built on a distribution's own PHP packages follow the distribution table above.

PHP 7.4, 8.0 and 8.1

The PHP project ships no new release for these branches. Its security team published source patches for 7.4, 8.0 and 8.1, for people who build PHP themselves. Everyone else needs a fixed build from a distribution, host or LTS vendor (for example Ubuntu 22.04's 8.1.2-1ubuntu2.28, or RHEL 8's php:7.4 stream), or a move to 8.2 or newer. Note that 8.2 itself reaches end of life on 31 December 2026.

What the outside view can and cannot tell

From outside, the only version hint is the X-Powered-By header, which PHP adds when expose_php is on:

X-Powered-By: PHP/8.3.6

That one line is useful. PHP/8.3.12 on branch 8.3 is clearly below 8.3.36, and no distribution ships that number as a fixed build. But PHP/8.3.6 can be either the old Ubuntu build or the fixed one, because the header never shows the package suffix. And a missing header tells you nothing at all. Hiding it with expose_php = Off is fine hardening, and it does not fix PHP2Shell.

A header is a hint, not proof. Use it as a quick first look at your own sites, then confirm on the server with the steps above. Our team built a free checker that reads the header and knows these distribution builds. It answers "not fixed", "fixed release", "check the package" or "cannot tell": php2shell.fyi.

Checklist

1. Find every PHP that serves a site (FPM pools, mod_php, containers).
2. Read the full package version, not php -v.
3. Compare it with your vendor's fixed build using the package manager.
4. Update, then restart PHP-FPM, Apache and long-running workers.
5. On 7.4, 8.0 or 8.1, get a vendor build or plan the move.
6. After the update, rotate the secrets PHP could read on hosts that ran an affected version. The flaws can leak server memory.

This article was drafted with AI assistance and checked by the php2shell.fyi team. php2shell.fyi is unofficial and not affiliated with PHP or php2shell.com. Package versions are as published by each vendor on 22 October 2026.