Using AWS WAF to apply mitigations for PHP2Shell RCE vulnerabilities (CVE-2026-109618 and CVE-2026-109619)

What it is

AWS Security Blog guidance (published after the PHP project's 21 October 2026 emergency release) on using AWS WAFv2 to reduce exposure to PHP2Shell, two unauthenticated RCE flaws in the PHP core runtime: CVE-2026-109618 and CVE-2026-109619, both CVSS v4.0 9.2. Fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP advisories: GHSA-w8hw-w9fx-j79w (109618) and GHSA-6wmf-4rv5-p3rp (109619).

How it works

Both bugs sit in multipart/form-data handling, before application code runs. CVE-2026-109618 corrupts memory when PHP runs out of memory mid-request. CVE-2026-109619 lets one request leave stale data that a later request on the same worker reuses. The page names two confirmed triggers: the PHP_SESSION_UPLOAD_PROGRESS form field and fatal_error_backtraces on PHP 8.5.

Preconditions / Affected

PHP 8.2 to 8.5 before the fixed releases. PHP 8.1 and earlier are unsupported upstream, so ask your distribution or LTS vendor for a backport or move to a supported branch. The multipart rule matters most for apps that accept no file uploads.

What to do

WAF rules (start each in Count mode, check sampled requests and CloudWatch metrics, then switch to Block):

1. Session upload progress rule: blocks only when all three hold: method is POST, PHPSESSID is a cookie key or appears in the body, and the body contains PHP_SESSION_UPLOAD_PROGRESS. This targets both CVEs.
2. Block multipart/form-data by matching the Content-Type header, which is inspected in full. Use only if the app has no uploads.
3. Cap body size with OversizeHandling: MATCH and a size constraint. The web ACL body inspection limit must be at least the cap. Scope it away from upload paths.
4. Rate-based rule on POST requests.

Order priorities so the session-upload and multipart rules run before the size and rate rules. Test with a benign multipart POST, an oversized body and a request carrying PHP_SESSION_UPLOAD_PROGRESS; expect a 403 and the rule metric.

Inspection limits: Application Load Balancer and AWS AppSync are fixed at 8 KB. CloudFront and API Gateway default to 16 KB and can be raised to 32, 48 or 64 KB in the web ACL AssociationConfig. If you already run AWSManagedRulesCommonRuleSet, SizeRestrictions_BODY blocks bodies over 8 KB by default. Override that single rule to Count if it breaks traffic.

Server settings:

• memory_limit=-1, post_max_size at 8M (no uploads) or 32M (uploads). Enforce memory bounds through container or cgroup limits, never RLIMIT_AS or RLIMIT_DATA, which trigger the vulnerable out-of-memory path.
• fatal_error_backtraces=0 on PHP 8.5.
• session.upload_progress.enabled=0.
• pm.max_requests=1 if performance allows, to break the link between the planting and reusing requests.
• Restart every worker after changes. Prefer php.ini or FPM pool config over per-request overrides (.htaccess, php_value, PHP_VALUE).
• Enable log_errors=On, a working error_log and error_reporting=E_ALL, and watch for repeated warnings, fatals and timeouts on attacker-reachable routes.

Caveats

• Patching is the only complete fix. The page says WAF only reduces exposure.
• WAF cannot parse headers inside multipart parts, so header amplification stays under size limits. Apps that accept uploads get limited protection.
• CVE-2026-109619 is largely outside WAF reach, so the server-side settings carry that risk.
• A size constraint cannot cap numeric Content-Length, because it measures the header string length.
• The absence of logged errors is not proof of safety.