🛡️ Patched PHP2Shell but php -v Still Says 8.3.6? Here's How to Actually Check

I patched a test box for PHP2Shell, ran php -v, and got... PHP 8.3.6. Same as before. 😅

Turns out that's expected — and if you're judging "are we safe?" by the version number, you can get it wrong in both directions. Here's what I found on Ubuntu 24.04, plus the three checks I now use instead.

TL;DR

• PHP fixed CVE-2026-109618 and CVE-2026-109619 ("PHP2Shell", CVSS v4.0 9.2, unauthenticated RCE) in 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35.
• On Ubuntu/Debian, the patched package keeps the old upstream version (e.g. 8.3.6). Check the package version and the changelog, not php -v.
• Installing the update isn't enough: restart Apache / PHP-FPM, or the old code keeps running.

Quick context: what is PHP2Shell?

Two memory-safety bugs in the PHP runtime itself, disclosed on Oct 21, 2026:

• CVE-2026-109618 – "RCE via OOM corruption": an out-of-memory bailout can leave half-initialized request data that cleanup then treats as valid.
• CVE-2026-109619 – "RCE via stale global state": request state survives after its memory is freed, and the next request on the same worker uses it.

According to the PHP advisory, every PHP install serving web requests is affected (PHP-FPM, mod_php, php-cgi, FrankenPHP, LiteSpeed), with mod_php at highest risk because an attack can land before your app code even runs. watchTowr reported seeing active exploitation attempts against both.

💡 WordPress folks: this is not a WordPress bug. WordPress.org says no WordPress update is required or planned. You need to update PHP. Security plugins won't help here.

Step 1: Record the "before" state

php -v | head -1
dpkg-query -W -f='${Package} ${Version}\n' php8.3-common

PHP 8.3.6 (cli) (built: Oct  7 2026 18:06:38) (NTS)
php8.3-common 8.3.6-0ubuntu0.24.04.12

Step 2: Install the fix

sudo apt-get update
sudo apt-get install --only-upgrade 'php8.3-*'

Ubuntu's announcement lists 8.3.6-0ubuntu0.24.04.13 as the fixed version for 24.04 (and 8.1.2-1ubuntu2.28 for 22.04).

Step 3: The gotcha 🪤

PHP 8.3.6 (cli) (built: Oct 19 2026 15:16:58) (NTS)
php8.3-common 8.3.6-0ubuntu0.24.04.13

The version string didn't move. Only the build date changed (Oct 7 → Oct 19).

Ubuntu backports security fixes without bumping the upstream number. So:

• ❌ "8.3.6 < 8.3.36, we're vulnerable!" → wrong, this box is patched.
• ❌ "We ran apt upgrade, we're fine!" → also wrong if nothing was restarted.

The most convincing evidence is the changelog:

zcat /usr/share/doc/php8.3-common/changelog.Debian.gz | grep -c 'CVE-2026-109618'
# -> 2 on my patched box

The top entry literally references CVE-2026-109618_109619.patch. That one line is what I'd paste into a status update.

Step 4: Restart, or it didn't happen

sudo systemctl restart apache2      # mod_php
sudo systemctl restart php8.3-fpm   # PHP-FPM

Ubuntu's post calls out restarting apache2 for mod_php, and the PHP advisory says to restart every worker. Even if unattended-upgrades installed the fix overnight, the running processes are still the old ones until you restart.

💡 Pro Tip: php -i on the CLI reads /etc/php/8.3/cli/php.ini, not your web SAPI's config. On my box the CLI showed memory_limit => -1. Don't verify web-side mitigations from the CLI.

What about mitigations if you can't patch today?

The PHP advisory lists partial measures: memory_limit=-1 (set so apps can't override it), a lower post_max_size, session.upload_progress.enabled=0 in php.ini or the FPM pool (not via ini_set() or .user.ini), and fatal_error_backtraces=0 on 8.5. It's explicit that these reduce specific attack paths but do not make an installation safe. watchTowr goes further and says .ini-based mitigations should be considered ineffective.

If you're on PHP 8.1 or older, there's no official fixed release. Check your distro or LTS vendor for backports, or upgrade to 8.2+. WordPress.org even suggests taking self-managed old-PHP servers offline until you can update. (And note: 8.2 itself reaches end of life on Dec 31, 2026.)

Results

On my Ubuntu 24.04.5 test box:

Wrapping up

If someone asks "are we safe from PHP2Shell?", answer with three things, not a version number:

1. Package version + changelog line (the fix is installed)
2. Restart time of Apache / PHP-FPM (the fix is running)
3. Logs since Oct 20 reviewed (nobody got in before you patched)

I also wrote a small Python script that compares mixed lists of upstream and Debian/Ubuntu version strings using dpkg's ordering rules (verified against dpkg --compare-versions on 306 pairs). Grab it here: GitHub link

How are you handling version checks across your fleet? Have you hit this backport confusion before? Let me know in the comments! 👇

📝 Japanese versions: Qiita (for non-engineer web managers) / Zenn (engineer deep-dive)
🐦 Follow me on X: @geneLab_999

Sources

• PHP security advisory (php.net)
• Ubuntu: php2shell fixes available
• Debian Security Tracker: CVE-2026-109618
• WordPress.org: Critical PHP Security Release
• watchTowr: PHP2Shell