PHP2Shell Vulnerabilities Require Urgent PHP Runtime Patching

Cloudflare reported observing attack traffic after vulnerability details leaked ahead of the coordinated public release. Organizations operating internet-facing PHP applications should treat PHP2Shell as an urgent runtime-patching incident, not an application or CMS update. Updating WordPress, Drupal, Joomla, plugins, or custom PHP code does not replace a vulnerable PHP interpreter.

PHP2Shell affects PHP runtimes that process web requests, including:

• PHP-FPM
• Apache HTTP Server with `mod_php`
• `php-cgi`
• FrankenPHP
• LiteSpeed PHP deployments

Apache `mod_php` is the highest-risk deployment model identified in the PHP advisories because a demonstrated exploitation path can be triggered by an unauthenticated HTTP request before application code runs. Other SAPIs may require different preconditions, application behavior, or exploit paths.

The first fixed upstream releases are:

• PHP 8.5 - fixed in 8.5.12
• PHP 8.4 - fixed in 8.4.27
• PHP 8.3 - fixed in 8.3.36
• PHP 8.2 - fixed in 8.2.35

PHP 8.1 and earlier no longer receive normal upstream releases. The PHP security team published minimal source backports for PHP 7.4, 8.0, and 8.1. Administrators using unsupported branches should obtain a supported downstream-vendor backport where available or migrate to a maintained PHP release, as noted in the PHP security release.

CVE-2026-109618, also tracked as GHSA-w8hw-w9fx-j79w, is an out-of-memory error-handling flaw.

PHP uses `longjmp()` to exit certain out-of-memory conditions. In affected contexts, this can interrupt processing while request memory is only partly initialized. During request shutdown, PHP may then process invalid state as though it were valid. The advisory describes multiple methods by which a crafted request can induce memory exhaustion and states that the condition can lead to RCE.

The PHP project confirmed unauthenticated HTTP-based RCE against Apache `mod_php`. PHP-FPM is considered susceptible after normal request startup, but the advisory does not report a complete exploit demonstration for PHP-FPM for this specific out-of-memory corruption path. FrankenPHP is considered likely susceptible to application-independent attacks based on its shutdown behavior, while LSAPI has application-specific risk that was not fully validated.

CVE-2026-109619, also tracked as GHSA-6wmf-4rv5-p3rp, is a stale-global-state vulnerability affecting persistent PHP workers.

PHP workers can retain global state that points to memory owned by a prior request. If that state is not reset before request memory is released, an early operation in a subsequent request can consume the stale reference before normal initialization replaces it. A crafted heap layout can produce a use-after-free condition, memory disclosure, or RCE.

Successful exploitation requires a request that leaves vulnerable state behind and a subsequent request handled by the same worker that consumes it. The PHP advisory confirms RCE against `mod_php` through a fatal-error-backtrace path and validates session-lifecycle RCE paths against both `mod_php` and PHP-FPM.

Cloudflare reported observing attack traffic targeting customers after vulnerability details leaked before the coordinated public release. It also observed attackers mutating payloads in apparent attempts to bypass protections. Cloudflare deployed managed WAF protections approximately nine hours before public disclosure.

This confirms attempted exploitation, but does not by itself establish successful compromise, a victim count, or attribution to a specific threat actor.

Public repositories and tools claiming to exploit PHP2Shell are available. Security teams should treat third-party proof-of-concept code as untrusted and should not run it on production systems or systems with access to sensitive networks.

Inventory internet-facing systems for PHP binaries, operating-system packages, containers, application images, appliances, and embedded products. Do not rely solely on application inventories or externally exposed version headers.

A host may be patched while an application container, vendor appliance, immutable image, or separately installed PHP-FPM pool remains vulnerable. Check each deployed runtime independently.

Upgrade to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35, or deploy the applicable vendor backport. Restart Apache, PHP-FPM, LiteSpeed PHP workers, and other long-running PHP processes after updating.

Updating is the only complete remediation. Configuration changes may reduce exposure to particular known paths, but they do not address every affected state transition or extension path.

PHP provides risk-reduction measures for specific paths, but these measures do not make a vulnerable deployment safe:

• For CVE-2026-109618, set `memory_limit=-1` administratively and ensure that pool, directory, or application settings cannot restore a finite per-request PHP memory limit.
• Constrain decoded request sizes, multipart part counts, headers per part, input variables, and nesting depth at the frontend. Controls must also account for requests without a usable `Content-Length`.
• Do not substitute `RLIMIT_AS` or `RLIMIT_DATA` for PHP memory limits, because these can trigger the vulnerable allocation-failure path.
• For CVE-2026-109619, set `session.upload_progress.enabled=0` administratively and restart all workers. This blocks demonstrated session-upload-progress paths, but not all variants.
• On PHP 8.5, set `fatal_error_backtraces=0` and restart workers. This removes the producer used in a confirmed exploitation path, but is not a complete mitigation.
• Remove invalid or deprecated per-request settings that generate diagnostics before normal PHP request initialization, and address attacker-reachable fatal-error and execution-timeout paths.

These controls, described in GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp, can reduce exposure to documented techniques but are not substitutes for replacing the vulnerable runtime.

Because PHP2Shell targets the interpreter rather than a specific framework or plugin, investigations should prioritize web-facing PHP infrastructure and application behavior that may expose reachable fatal-error, timeout, multipart-processing, or diagnostic paths.

Review the following telemetry and system activity:

• Multipart POST activity where file-upload functionality is not expected.
• Web-server and PHP worker logs for repeated malformed requests, unusual warnings, deprecations, fatal errors, timeouts, worker crashes, or restarts.
• Requests that trigger PHP errors before expected application execution.
• New or anomalous child processes spawned by web-server or PHP service accounts.
• Unexpected outbound connections from PHP application hosts.
• Changes to web roots, application directories, cron jobs, service definitions, SSH authorized keys, or PHP configuration files.
• Endpoint telemetry showing shells, download utilities, interpreters, or persistence mechanisms launched by Apache, PHP-FPM, LiteSpeed, or related service accounts.

The absence of relevant errors in historical logs is not evidence that a system was not vulnerable or targeted. Relevant conditions may not have been logged, may have occurred before logging was available, or may depend on application and worker state.

A WAF can reduce exposure while upgrades are underway, but it is defense in depth rather than remediation. Cloudflare's observation that attackers were varying payloads reinforces the need to patch every exposed PHP runtime.

The immediate concern is continued spread and refinement of exploit attempts against exposed PHP infrastructure. Monitor operating-system, hosting-provider, container-image, appliance, and application-vendor advisories for downstream package updates; verify patched versions in every runtime location; and review updated detection content as researchers validate additional trigger paths.

Teams that cannot quickly determine whether internet-facing PHP assets were exposed or targeted should prioritize focused vulnerability assessment, web-log review, endpoint investigation, and security monitoring. PHP2Shell is remediated by replacing or backporting the vulnerable PHP runtime, not by updating the application that runs on it.

For a structured approach to vulnerability management, patching, and security monitoring, see our guide to Managed Cybersecurity for GCC SMBs.