Back to all articles

PHP2Shell: PHP patches released for two critical RCE vulnerabilities

Published on 2026-10-21 Written by GLOV Team

Updated 22 October 2026 — PHP security fixes have been available since 21 October. The vulnerabilities CVE-2026-109618 and CVE-2026-109619, collectively known as “PHP2Shell”, are both rated critical (CVSS v4.0: 9.2/10). The PHP project confirms that they can enable unauthenticated remote code execution against exposed installations. Our original 21 October advance warning has therefore been updated with confirmed technical findings and an operational response plan.

Key action: update immediately to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, depending on the branch in use, or install a vendor-maintained patched distribution package. No configuration change or WAF rule is a complete substitute for patching. Prioritise internet-facing environments.

What PHP confirmed on 21 October

In its official 21 October 2026 advisory, the PHP project identifies two separate vulnerabilities, describes their mechanisms and provides four fixed releases:

  • PHP 8.5: 8.5.12 (and subsequently patched releases).
  • PHP 8.4: 8.4.27 (and subsequently patched releases).
  • PHP 8.3: 8.3.36 (and subsequently patched releases).
  • PHP 8.2: 8.2.35 (and subsequently patched releases).

Each issue has an official CVSS v4.0 severity score of 9.2/10. The French national incident response authority, CERT-FR / ANSSI, in advisory CERTFR-2026-AVI-1359, confirms the remote arbitrary code execution risk and lists older, unpatched branches.

The defects affect the PHP runtime itself rather than a particular WordPress, PrestaShop, Dolibarr or other CMS plugin. Updating only an application or its extensions therefore does not remediate a vulnerable PHP runtime.

Two vulnerabilities with different underlying mechanisms

CVE-2026-109618: corruption during out-of-memory handling

GHSA-w8hw-w9fx-j79w describes a defect in out-of-memory (OOM) handling. If request-data initialisation is interrupted, internal structures can remain inconsistent; later request cleanup may trigger memory corruption and code execution.

PHP reports that unauthenticated RCE over HTTP was validated against Apache mod_php, including ordinary multi-worker configurations. Exploit conditions and reliability still depend on the PHP build, extensions, memory allocator and frontend behaviour.

CVE-2026-109619: stale state retained between requests

GHSA-6wmf-4rv5-p3rp covers request-owned internal state surviving after its backing memory is freed. When a later request is handled by the same process, stale-state access can cause a use-after-free, memory disclosure or code execution.

Confirmed paths include session-upload-progress processing. This explains certain temporary mitigations, but it does not establish that an application without uploads is necessarily safe.

Which environments are affected?

The PHP project considers all PHP installations that handle web requests to be at risk, including:

  • PHP-FPM behind Nginx or Apache;
  • Apache with mod_php, considered particularly concerning by the vendor;
  • php-cgi, FrankenPHP and LiteSpeed;
  • containers, application images, appliances and management interfaces embedding PHP.

Researchers have demonstrated attacks involving widely used CMS platforms, but using PHP is not evidence of an actual compromise. Exploitability depends on the affected version, runtime mode and surrounding environment.

PHP 8.1 and older are no longer maintained by the upstream PHP project. Some Linux distributions and long-term-support vendors provide backported fixes. As an exceptional measure, PHP also supplied minimal source backports for PHP 7.4, 8.0 and 8.1, mainly for self-build users. This does not reinstate routine support for those branches. PHP 8.2 reaches end of life on 31 December 2026.

Has exploitation been observed?

watchTowr's tracking page, updated 22 October, reports in-the-wild exploitation activity observed on 21 October by its sensor network. Meanwhile, Huntress said it had not observed exploitation among its own partner systems as of its late-21-October update (US time).

Those reports concern different monitored populations and are not contradictory. They warrant urgent patching, not unsupported claims that widespread compromise has been established. Observed probes, proof-of-concept demonstrations and confirmed intrusions are different evidentiary thresholds.

A practical, low-disruption remediation plan

1. Inventory the PHP runtimes actually serving requests

Record applications, hosts, containers, runtime versions, execution modes and network exposure. The php -v command shows the command-line runtime, which may not match the version used by PHP-FPM or the web server. Include multiple pools, Docker images, scheduled jobs and third-party software bundling PHP.

2. Apply the correct patch

Deploy the fixed release on the maintained branch, or a security-backported package from the distributor. On Debian, Ubuntu or other vendor-supported systems, check the security notice and exact package revision: an older-looking upstream version number does not necessarily mean a vendor backport is absent. For containers, rebuild or update the application image and redeploy. Patching the host does not update PHP binaries bundled in containers.

3. Verify the running service and business functionality

Before changing production, prepare restorable backups of files, databases and configuration. Restart or reload the appropriate PHP processes so they use the fixed binaries. Confirm the runtime version actually serving web traffic, then test authentication, ordering, payments, asynchronous processing, imports, scheduled jobs and error logs as applicable.

4. Address systems that cannot yet be patched

Temporarily reduce exposure through VPN access, network segmentation or access restrictions, based on risk and business needs. Plan migration away from unsupported PHP releases and track appliance or embedded-software vendor advisories.

Temporary mitigations reduce risk; they do not fix PHP2Shell

The official PHP advisory offers guidance for installations that cannot immediately be updated:

  • Disable session.upload_progress.enabled in configuration applied before request parsing, and restart every PHP worker. This blocks confirmed CVE-2026-109619 paths, not every possible variant.
  • On PHP 8.5, disable fatal_error_backtraces and restart workers to reduce exposure through another confirmed path.
  • Review multipart handling, request-size restrictions and memory configuration using the PHP project's detailed caveats. Some mitigations — particularly changes to memory_limit — can affect service availability and need environment-specific validation.

Do not treat a WAF as a guaranteed patch, even where network controls can reduce certain attack attempts. The PHP project identifies updating as the only complete remediation.

If compromise is suspected, preserve evidence

Within an authorised investigation, retain HTTP, reverse-proxy, PHP-FPM, system and security logs, plus useful file timestamps and hashes. Examine unusual child processes launched by the web runtime, unauthorised changes, unexpected outbound connections, persistence mechanisms and potential secret exposure.

These are triage signals, not indicators uniquely attributable to PHP2Shell. Correlate findings with the actual exposed runtime and incident timeline; preserve evidence before reimaging. Where an intrusion is confirmed, coordinate containment, targeted credential rotation and verified recovery.

What this means for GLOV Solutions

For GLOV Consulting, this event illustrates why dependency inventories, vulnerability response procedures and tested recovery plans matter. It differs from our Rank Math PRO incident analysis, which concerned a tampered software distribution.

In blockchain infrastructure operations such as Snow-Fall, the same discipline applies to auxiliary web interfaces and administrative tools: patching must protect security without overlooking operational availability.

Information assessed as of 22 October 2026. The fixed versions and main technical mechanisms are confirmed; exploit reliability for every build/extension combination and the overall extent of actual compromises remain uncertain. No compromise of GLOV systems is alleged.

Official sources and independent technical analysis

Related articles

Back to all articles