On 21 October 2026 the PHP project shipped emergency updates for two critical remote‑code‑execution flaws, collectively named PHP2Shell, and AWS responded with a set of AWS WAF mitigation rules that can be deployed while the PHP runtime is being upgraded. Practitioners need to understand both the nature of the vulnerabilities and the exact protection surface offered by the firewall, because the rules are a stop‑gap, not a replacement for patching.
What Changed in the PHP Core
The two CVEs (CVE‑2026‑109618 and CVE‑2026‑109619) both score 9.2 (Critical) under CVSS v4.0. They exploit how PHP processes multipart/form-data bodies before application code runs. CVE‑2026‑109618 triggers a memory‑corruption condition when the interpreter runs out of memory mid‑request. CVE‑2026‑109619 leaves stale global state that a subsequent request on the same worker can reuse. The official fix is to upgrade to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35. The PHP advisory explicitly states that upgrading is the only complete mitigation.
How AWS WAF Can Reduce Exposure
AWS WAF operates at the edge and inspects HTTP requests, but it does not parse the internal structure of multipart bodies nor does it see PHP worker memory. The rule set focuses on three observable request elements:
PHP_SESSION_UPLOAD_PROGRESS– the form field that enables PHP’s upload‑tracking feature. A rule can block any request that contains this field.multipart/form-data– the content type used for file uploads and the entry point for both vulnerabilities. If an application does not accept legitimate multipart uploads, a blanket block of this content type removes the primary attack vector.- Request body size – limiting the maximum size reduces the chance of triggering the out‑of‑memory condition.
The AWS security bulletin confirms coverage for the session‑upload field and for multipart traffic when no legitimate uploads exist. It also notes that one of the two vulnerabilities is largely outside the reach of any web‑application firewall, because the exploit relies on internal PHP memory handling that WAF cannot observe.
Operational Considerations for Deploying WAF Rules
Implementing the recommended rules should follow a staged approach:
- Inventory all services fronted by AWS WAF and identify which, if any, accept legitimate multipart uploads. For services that do, consider a more selective rule that blocks only the
PHP_SESSION_UPLOAD_PROGRESSfield. - Deploy the rule set in a test or canary stage, monitor for false positives, and adjust the rule scope or exception list as needed.
- Document the rule lifecycle: the rules are intended only until the PHP runtime is upgraded to a patched version. After patching, remove or disable the rules to avoid unnecessary request filtering.
- Track the AWS security bulletin (2026‑143‑AWS) for any updates to the rule set or additional guidance.
Because WAF does not inspect the multipart body contents, it cannot block the specific payload patterns that trigger the out‑of‑memory corruption. Practitioners should therefore treat the WAF controls as risk reduction, not as a guarantee of safety.
Related CloudNinjas coverage: AWS.
What This Means For Practitioners
Engineers responsible for PHP‑based services should prioritize upgrading to the patched PHP releases. In parallel, they can apply the AWS WAF mitigation rules to block the session‑upload field and, where feasible, block multipart/form-data entirely. This approach buys time during maintenance windows without requiring code changes. However, teams must remain aware that the firewall cannot stop the memory‑corruption path, so the window of exposure persists until the runtime is patched. Continuous monitoring of WAF logs for blocked requests and rapid removal of the rules after patching will keep the security posture tight without introducing unnecessary traffic friction.
