A WAF rule for PHP2Shell is worth deploying this week, and the ticket it belongs to should stay open until the hosts are patched.
AWS published firewall rules for CVE-2026-109618 and CVE-2026-109619 on Oct. 22, one day after the PHP project shipped fixes. The rules are useful. My argument concerns the status they will tempt teams to set: “mitigated.”
The AWS post lists what a firewall can and cannot do here. A rule can block requests that carry the session upload progress field. A body-size cap can limit an oversized request, but the post says it does not catch header amplification, where many small part headers cost far more memory inside PHP than their size on the wire. Two other attack elements sit outside any edge control: a PHP 8.5 setting that stores crash-trace state across a request, and a diagnostic path that runs server-side and never crosses client HTTP. The post’s own summary is that one of the two flaws is largely outside the reach of any web application firewall.
Amazon’s threat-intelligence post is just as direct. “Upgrading is the only complete remediation for both CVE-2026-109618 and CVE-2026-109619,” wrote CJ Moses, CISO of Amazon Integrated Security. A rule that leaves some exposure by design should not close a ticket that says the vulnerability is handled.
The strongest case against my position is practical. A WAF rule ships in an afternoon. A PHP upgrade across a fleet needs an inventory, test windows and maintenance slots, and AWS says as much about patching taking time. Amazon also reports that exploitation was broad within hours of the fix. A team that cannot patch before the first scanning wave has one control available, and withholding it to keep the paperwork clean would be the worse choice.
The label decides where attention goes next. Vulnerability trackers and audit sheets carry one status per finding. Once PHP2Shell reads “mitigated,” the hosts behind the rule drop out of the queue that gets weekly review, and the multipart-upload applications that AWS says the firewall cannot fully cover go with them. Our report on Amazon’s honeypot data shows an attempt on Oct. 17, four days before the fix, so attackers had a head start on anyone who waited for the advisory. A team that believes it is covered has less reason to read those hosts’ logs for earlier activity, and Amazon recommends starting that review from the earliest known exploitation, which for PHP2Shell is at least Oct. 17.
I agree with all of that, and it is why I say to deploy the rule today. Start it in count mode, as AWS advises, confirm it leaves legitimate traffic alone, then switch it to block. My disagreement is with the label. Three habits keep the label honest.
First, record the rule as a temporary exception with an expiry date, owned by a named person. An exception that expires forces a patch decision, where a mitigation with no end date gets forgotten. AWS says to remove the rules or keep them as supporting controls once hosts are patched, so the exception should end with a decision to do one or the other.
Second, report one number to leadership: the share of PHP hosts running 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or later. The share of hosts behind a rule says how much work is left to do, and it should not be mistaken for the share that is done.
Third, sort the hosts that depend on multipart uploads into their own group. AWS says that where an application uses multipart uploads, the firewall reduces risk but does not close the vulnerability. Those applications have the weakest edge protection and should be first in the patch queue. A report that gives the three counts side by side tells leadership more than a single word, and it gives the engineer who owns the hardest group a reason to ask for a change window.
A team can split its PHP hosts into three groups this week: patched, rule-only and neither. The third group needs attention before anything else. The second needs dates. This site has argued that the patch clock starts on release day, and PHP2Shell shows why: our report on the advance notice of the flaws gave a 14:00 UTC fix time, and Amazon’s honeypot data shows exploit attempts before and after it.
