Client php-vulnerability-audit — PHP2Shell Audit, Patching and Hardening
Role Solo Security Engineer / DevOps
Period Oct 2026
Stack
PHP 5.4–8.5 mod_php PHP-FPM Apache Nginx Linux Docker WordPress OpenCart Joomla Laravel Cloudflare WAF ModSecurity
php-vulnerability-audit — PHP2Shell Audit, Patching and Hardening preview

php-vulnerability-audit — PHP2Shell Audit, Patching and Hardening

Overview

On 21 October 2026 the PHP project shipped emergency releases for two critical remote-code-execution flaws in the interpreter itself, CVE-2026-109618 and CVE-2026-109619 (“PHP2Shell”, found by Wiz Research). The bug is not in a CMS or a plugin: any site running a vulnerable PHP is exposed, however clean its own code is, and PHP versions as old as 5.4 are affected.

This service finds where a vulnerable PHP is running in your infrastructure, brings it to a fixed version (or to a safe interim state), proves the fix from the web side, and checks whether the server was already hit. For WordPress, OpenCart, Joomla, Laravel and custom PHP sites, on a VPS, a dedicated server, shared hosting or in Docker.

Fixed versions

PHP branch Fixed version (21 Oct 2026)
8.5 8.5.12
8.4 8.4.27
8.3 8.3.36
8.2 8.2.35
8.1 and older No updates from the PHP project. Minimal source backports exist for 7.4, 8.0 and 8.1; some distributions and LTS vendors ship their own fix. Otherwise: migrate to a supported branch

PHP’s own advisory is direct: there are no complete mitigations, updating is the only safe choice.

What is covered

Step What is done
Inventory Every server, VPS, hosting account, Docker image and CI runner that serves PHP, and which web SAPI it uses (mod_php, PHP-FPM, CGI, LiteSpeed, FrankenPHP). The advisory rates mod_php highest, because an exploit can fire before any application code runs
Version check The version the web actually serves, not only php -v in a shell: the CLI and the web SAPI are often different builds. Compared against the fixed versions above
Patch The fixed release; or the vendor’s backport (Ubuntu, Debian, AlmaLinux, CloudLinux, cPanel, Plesk); or a migration to PHP 8.3 / 8.4 with a compatibility pass over the CMS, plugins and custom code on a staging copy first
Interim mitigation Only when the patch cannot go out today, and only the measures from the PHP advisory: session.upload_progress.enabled=0 set in php.ini or the FPM pool (not via ini_set() or .user.ini), fatal_error_backtraces=0 on PHP 8.5, a low post_max_size, memory_limit set where applications cannot override it. Plus a WAF rule or an IP allow-list for a critical site. Documented as temporary
Verification Every PHP worker restarted, the version re-checked from the web side, a smoke test of the site and its checkout or forms
Compromise review Logs checked for the signs published by Wiz: multipart requests followed by memory-limit errors, repeated HTTP 500, unexpectedly large or malformed PHPSESSID cookies, PHP worker churn. File-integrity diff against clean CMS cores. If exposure is likely: database passwords, API keys, tokens and certificates rotated, because one of the flaws can disclose worker memory

Application logs may show little, since the flaws sit below the application layer. A clean log is therefore not treated as proof of a clean server; the review is a set of checks, not a guarantee.

How it goes

PHP2Shell flow: inventory, version check, exposure, patch, interim mitigation, verification, log review and secret rotation

  1. Inventory and version check. A list of every host with the PHP version and SAPI it really serves.
  2. Risk and plan. Hosts ordered by exposure; for each, a route: update, vendor backport or migration.
  3. Patch on staging, then production. For stores and sites with custom code the update is rehearsed on a copy; the switch is done in a quiet window.
  4. Verification and review. Workers restarted, version re-checked from the web, logs reviewed, secrets rotated where needed.
  5. A short report. Hosts, versions before and after, what was changed, what remains (for example an end-of-life PHP that needs a planned migration).

If a site is already compromised, the cleanup follows site-security-cleanup; if the move to a new server or PHP version has to happen without downtime, see zero-downtime-migration.

Sources

Stack

PHP 5.4 – 8.5 · mod_php · PHP-FPM · Apache · Nginx · LiteSpeed · Linux (Ubuntu / Debian / AlmaLinux) · Docker · WordPress · OpenCart · Joomla · Laravel · Cloudflare WAF · ModSecurity · Fail2ban