PHP2Shell Mitigation: Cloudflare WAF for Legacy PHP

If a legacy application prevents a PHP upgrade, start by controlling who can reach the runtime and which protections every request crosses. PHP2Shell mitigation can reduce exposure while you obtain a compatible fix for CVE-2026-109618 and CVE-2026-109619. It does not turn an unchanged, vulnerable interpreter into a patched one.

Choose a route based on your operational constraint:

Use our PHP2Shell patch guide for fixed-version tables and update commands. This guide concentrates on the period when those updates cannot yet be applied.

Cloudflare PHP2Shell WAF protection: what to verify

Cloudflare’s PHP2Shell protection announcement distinguishes these deployments:

The announcement lists seven request rules per ruleset under “Generic Rules - Anomalous Execution.” Use its current rule IDs when investigating events; the Free and paid IDs differ. A managed rule exception or skip can change the protection that actually reaches your application.

In Security → Security Analytics → Events, inspect matching rule IDs, action, hostname, and path. Check ordinary page loads, login, APIs, and required uploads for false positives. Investigate an individual exception before disabling a whole ruleset. An empty event list proves neither that attacks occurred nor that every path is covered.

Close routes that bypass the WAF

Inventory the main hostname, alternate hostnames, IPv4 and IPv6 origins, and exposed web ports. A DNS-only record or direct-origin route can let traffic reach PHP outside the intended proxy path.

Cloudflare’s origin protection guidance describes firewall restrictions, Authenticated Origin Pulls, and Tunnel. Choose controls that fit your deployment and confirm legitimate health checks and integrations still work. Merely hiding an origin IP is insufficient. The shared Origin Pull certificate establishes Cloudflare-network origin; stronger binding requires an appropriate custom certificate or authenticated channel.

Apply staff-only authentication at the gateway or web server before PHP executes. An application’s own login page still requires the vulnerable interpreter to process the request. For a public legacy site, a practical containment option is serving a static maintenance page at the frontend while denying the old PHP backend public traffic.

Full transaction detection: what response blocking means

Cloudflare’s full transaction detection combines request and response signals. Its managed response rules can stop a matching origin response before it reaches the visitor. The PHP2Shell announcement lists an all-plan response rule, afffe22785674c80a31875c848d2242a, for high-confidence signatures.

Review the response-phase controls under Security → Security Rules, alongside request protections. As announced on October 21, managed and custom response rules are available across plans; some advanced detection fields are still rolling out. Verify the controls exposed in your account before designing a custom policy.

A response block cannot undo code execution or another action already performed at the origin. Treat it as an additional containment layer, and inspect origin logs when an event suggests successful exploitation. It does not establish that the server remained uncompromised.

PHP-FPM and php.ini workarounds for legacy PHP

Have the server owner review these changes against the two PHP maintainer advisories. Apply settings at startup through php.ini, the FPM pool, or the relevant server configuration, then restart every affected worker. Application-level ini_set() runs too late for request-startup paths.

Reduce stale-state paths

The stale-state advisory recommends disabling upload-progress handling for the demonstrated session paths:

; In the PHP startup configuration used by the web runtime
session.upload_progress.enabled = 0

This removes that feature’s confirmed paths. Other lifecycle variants remain. On PHP 8.5, the advisory separately discusses fatal_error_backtraces=0; do not copy a directive for a different PHP branch into an older installation.

Where throughput permits, the same advisory suggests limiting FPM worker reuse:

; In the relevant PHP-FPM pool configuration
pm.max_requests = 1

This introduces worker-creation overhead and can affect capacity. It targets cross-request reuse, while the OOM issue remains. Test representative load and startup behavior before applying it broadly. Fix reachable fatal errors and obsolete startup directives; suppressing their messages does not remove the underlying condition. Use startup or pool settings rather than relying on FPM .user.ini overrides for these protections.

Reduce controllable out-of-memory paths

The OOM advisory describes administratively enforcing memory_limit=-1 as a partial mitigation. This removes PHP’s controllable per-request memory-limit failure and removes its memory cap. Evaluate it together with container or cgroup boundaries and independent frontend request limits. Underlying allocation failure remains a risk. A group-wide OOM kill may also terminate the master and all workers; assess that availability impact.

Limit decoded request size, field count, nesting, multipart parts, and headers. Reject multipart traffic at the frontend where the application does not need it. A check based only on declared Content-Length is inadequate. The advisory specifically warns against replacing PHP’s memory limit with RLIMIT_AS or RLIMIT_DATA, which can trigger the vulnerable allocation-failure path.

For request-size starting points, PHP’s operational advisory suggests post_max_size=8M without required uploads or 32M where uploads are necessary, with upload_max_filesize lower. Adapt these limits to legitimate traffic and enforce frontend limits too. If you cannot establish suitable resource boundaries, prioritize isolation over applying an unlimited-memory setting blindly.

PHP 7.4 security: ask for a verified backport

“Cannot migrate the application today” and “cannot change the runtime at all” lead to different decisions. A backport can change vulnerable runtime code while preserving the branch your application expects.

PHP provided minimal source backports for 7.4, 8.0, and 8.1 for this incident. They require a maintained build and deployment process; their availability does not restore upstream support. Ask your distribution, hosting provider, or LTS supplier for its exact package, coverage of both CVEs, delivery channel, support terms, and any additional cost. Verify coverage before buying a service or switching repositories. PHP’s backport notice.

Keep WAF and containment measures in place while validating the supplied build. Wiz’s research and coordinated mitigation account describes work with infrastructure vendors to help organizations that cannot update immediately; it does not establish the protection status of your particular host.

Validate the mitigation and define its end date

Record an owner and review date for each legacy service. Use checks tied to the selected controls:

• Confirm the intended hostname crosses the proxy and applicable rules.
• Confirm unauthorized direct-origin and staff-only access is rejected before PHP.
• Verify startup settings in the web runtime, every FPM pool, and each replica after restart.
• Test required uploads, login, APIs, callbacks, and background jobs with ordinary traffic.
• Review PHP crashes, worker restarts, WAF events, and resource pressure together. Quiet logs do not prove safety.
• Track the vendor-fixed build or migration milestone that ends reliance on temporary measures.

Use controlled access tests rather than running public exploit scripts on production. When a compatible fixed build becomes available, follow the patch and deployment verification guide. For a planned move from PHP 8.4, use the separate PHP 8.5 upgrade checklist; older starting branches also need the intervening migration guides.

Reviewed on October 22, 2026. These are mitigation options and acceptance checks, not a claim that your environment has been protected or tested. Follow current PHP and provider notices as coverage changes.