A Compensating Control Exit Needs Proof From the Process That Serves Traffic

A compensating control exit is not complete when a vendor-managed WAF rule is enabled, a patch package is installed, or a deployment pipeline reports success. It is complete when the process serving production traffic is shown to be patched and the control is retired against that evidence.

PHP2Shell made the gap concrete. The PHP project disclosed CVE-2026-109618 and CVE-2026-109619 on October 21, 2026. On October 26, CISA added both vulnerabilities to its Known Exploited Vulnerabilities (KEV) catalog. AWS, Vercel and Cloudflare each published WAF protections for them. AWS and Vercel say those protections do not replace patching, and Cloudflare tells customers to keep them enabled while patching. A rule that exists is a control you were handed. What it covers on your traffic, and what lets you remove it, are still yours to record. Confirmed exploitation establishes the threat, not the effectiveness of a particular provider’s mitigation. This post makes no claim about the latter.

What Each Provider Says the Rule Covers

For a Modern Infrastructure & IaC team, a managed rule is one more piece of state that needs an owner and a retirement condition. Record the scope each provider states, with the date of the document, then check your deployment against it.

AWS. AWS Security Bulletin 2026-143-AWS calls patching the only complete fix and separates customers on the default version of the AWS WAF PHP application managed rule group from customers pinned to a version. The AWS Security Blog post, published October 21 and updated October 23, gives the version history. Version 2.2 and earlier have neither PHP2Shell rule. Version 2.3 adds PHP2Shell_BODY, for CVE-2026-109619. Version 2.4 adds PHP2Shell_BODY_Extended, for CVE-2026-109618; before 2.4, AWS’s changelog points to SizeRestrictions_BODY in a different managed group, the Core Rule Set, which blocks bodies over 8 KB. From 2.4 on, AWS says PHP2Shell_BODY also blocks POST requests carrying a PHP session ID and the session upload-progress field, which it describes as helping mitigate CVE-2026-115560 until PHP ships a fix.

Body rules inspect only up to the web ACL’s limit, and they use the Continue oversize option, so AWS recommends pairing them with a size rule that blocks bodies above the threshold instead of passing them uninspected. The sources also date version 2.4 differently: the changelog lists it on October 22, and the blog’s update note is dated October 23. The changelog entries describe the two PHP2Shell CVEs; the 115560 statement is in the blog. Record the version you deployed and the document you read, not a date inferred from either.

Vercel. Vercel’s October 21 bulletin says Vercel’s rules reduce exposure to known exploit patterns and do not replace patching. They apply to PHP functions on Vercel and to requests Vercel rewrites or proxies to external PHP backends. Requests that bypass Vercel’s network, including direct requests to an external PHP backend, are not covered. The bulletin tells operators to verify that the deployment serving web requests is running the patched runtime.

Cloudflare. Cloudflare’s post, published October 21 and modified October 23, tells customers to keep WAF protections enabled while patching. Free customers need to take no action. Professional, Business and Enterprise customers are told to confirm that their Managed Ruleset deployment is in block mode. Cloudflare says it saw attackers mutating payloads to try to bypass its protections. Its October 23 update says the protection for CVE-2026-115560 applies when a site uses PHP’s default upload-progress field name, and that customers who changed session.upload_progress.name are not covered by the rule. “Cloudflare protects us” is not a coverage statement; plan, ruleset, action and application assumptions are.

The Coverage Boundary

The first artifact in a compensating control exit is a path-by-path coverage map of the deployment you run. Each row is tied to a provider statement, and a row with no verifiable source should be removed, not filled with an assumption.

Two different things sit in this table, and they need to stay apart. CVE-2026-109618 and CVE-2026-109619 are PHP runtime flaws with fixed releases: 8.5.12, 8.4.27, 8.3.36 and 8.2.35, per AWS’s bulletin. CVE-2026-115560 is a separate issue. The PHP project’s October 23 advisory describes an uncommon combination: an application sets session.serialize_handler to php_binary or php_serialize, switches it to php at runtime with ini_set() before session_start(), and leaves session upload progress enabled. PHP’s guidance is to set session.upload_progress.enabled=0 until its next regular bugfix release. AWS states that the October 21 releases do not fix it, and the advisory names no fixed version as of this writing. A WAF rule for it mitigates a configuration question under the field-name and request-pattern assumptions above. Patched PHP alone does not close it, and the precondition is uncommon.

The coverage statement for a compensating control exit should be specific enough for another operator to challenge:

Coverage: provider, ruleset and version protect the documented request patterns on the listed public path. Direct-origin access and the listed alternate paths are assessed separately. Source: named provider document, its date, and verified configuration.

Compensating Control Exit Proof Lives on the Serving Process

Installing a patched package is necessary. It is not proof that the process handling production requests is running it. Analysis, mine and not the providers’: a package upgrade does not change code a running process has already loaded, and a version check from the command line says nothing about the web worker.

Use this ladder, in order:

The principle is the one in The Architecture of Premature Closure and DKM ACL Hardening Is Scheduled. The Evidence It Worked Is Not.: a closure signal that fires on execution is not verified state. Here it governs one decision. A successful package operation or a green deployment report is not the test for removing a WAF rule.

When the Window Closes Without Proof

Providers change these rules on their own schedule. Vercel says it will update its rules as new variants appear, Cloudflare says it will update its rules if new techniques emerge, and AWS describes its rule group as continuously updated. None of the documents read for this post states an end date for the protection. The compensating control exit deadline therefore sits on your register line, and you set it.

Before that date, re-run the coverage table against the provider’s current documentation and the rule version you deployed. If the date arrives without serving-process proof, there are three defensible choices:

Doing nothing is a decision to carry an unverified exposure, and the record should not read as remediation. A compensating control exit that arrives without proof is a decision point, not a closed item. The closure deadline itself is a variable of the Emergency Reconciliation Gap, covered in Why Configuration Standards Fail During Emergency Changes and placed in the Governance & Drift stage of the learning path. What an expiring hold releases is in A Paused Rollout Is a Queue. Who may trade a patch for availability, and on what evidence, is in Patch Rollback Risk.

Register the Compensating Control Exit, Not Just the Rule

A register line that survives a handoff records the compensating control exit alongside the control:

The table is not evidence for the compensating control exit. It is the structure that makes missing evidence visible before someone marks the item closed.

Additional Resources

About The Architect

R.M.

Senior Solutions Architect with 25+ years of experience in HCI, cloud strategy, and data resilience. As the lead behind Rack2Cloud, I focus on lab-verified guidance for complex enterprise transitions. View Credentials →