Smartycode LabsGet build notes
Experiment SC-002

php -v cannot tell you whether you are patched against PHP2Shell

Two throwaway containers, one CVE, opposite version behaviour: Ubuntu patches without changing the version string, Rocky rebases to the fixed release.

Published
Updated
By
Danila Vershinin
Artifacts
Open evidence
Two terminal panels side by side. Ubuntu 24.04 prints PHP 8.3.6 but its package changelog lists CVE-2026-109618 and CVE-2026-109619. Rocky Linux 9 prints PHP 8.3.36 after a rebase.
SC-002 · Real command output from two containers, rendered as a lab specimen.

Disclosure day for PHP2Shell (CVE-2026-109618 and CVE-2026-109619, unauthenticated RCE, exploited in the wild) produced the usual reflex: run php -v, compare against the advisory, panic or relax. We wanted to know how far that reflex can be trusted.

Claim

php -v can tell you whether a server is patched against PHP2Shell.

Method

Upstream fixed the bugs in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. We installed PHP 8.3 from each distribution’s own repositories in clean, throwaway Docker containers on 2026-10-23, then compared three views of the same install: what the binary reports, what the package manager records, and what the package changelog says.

  • Ubuntu 24.04: php8.3-cli from noble, noble-updates and noble-security.
  • Rocky Linux 9: php-cli from the php:8.3 module, after dnf --refresh and a module reset.

Evidence

Check Ubuntu 24.04 Rocky Linux 9
php -v PHP 8.3.6 PHP 8.3.36
Package version 8.3.6-0ubuntu0.24.04.13 8.3.36-1.module+el9.8.0
Changelog Names both CVEs and a backported patch “rebase to 8.3.36”
Upstream fixed release 8.3.36 8.3.36

Same disclosure, opposite behaviour. Ubuntu keeps the old version and patches it, so php -v reads 8.3.6, which is far below the fixed 8.3.36. Rocky rebases the module, so the version string does move to the fixed release. The full output is in the raw transcript.

What failed first

Our first Rocky run reported PHP 8.3.33, a version before the fix, and we nearly published “Rocky has no fix yet”. A refreshed run, after clearing cached metadata, installed 8.3.36. The stale answer came from the image’s cached package metadata, not from the distribution. Our first Ubuntu changelog lookup also failed, because the container had no CA certificates and the changelog service later returned a 404 for this build. The changelog shipped inside the package answered the question anyway.

Note that Rocky’s own changelog does not name the CVEs, and dnf updateinfo printed no advisory rows for them in our run. Neither signal would have confirmed the fix. Only the version number did, and only because Rocky happens to rebase.

Verdict

The claim fails, but verified. Reading php -v against upstream version numbers marks a patched Ubuntu server as vulnerable, and it only works on a distribution whose policy is to rebase. Any check that compares version strings has to know each vendor’s packaging policy.

For a quick answer without reading changelogs, paste your package list into the backport-aware PHP2Shell checker. If it says you are exposed, the fix guide lists the options.

Reproduce it

  1. Run docker run --rm ubuntu:24.04 and install ca-certificates and php8.3-cli.
  2. Compare php -v, dpkg -l php8.3-cli, and the grep on /usr/share/doc/php8.3-cli/changelog.Debian.gz.
  3. Repeat in rockylinux:9 with dnf --refresh module reset php, module enable php:8.3, install php-cli, then rpm -q php-cli.