Microsoft published Azure WAF guidance on October 21, 2026 for PHP2Shell, CVE-2026-109618 and CVE-2026-109619. Its central recommendation is clear: upgrade PHP. WAF controls reduce exposure to selected exploitation patterns; they do not repair the vulnerable runtime. Microsoft's response guidance.
For Azure teams, this needs two separate work records: completing the runtime update and verifying any temporary edge protection. A green WAF policy status should not close the patch task.
Start with the Runtime, Including Images
The PHP project's October 21 advisory identifies 8.5.12, 8.4.27, 8.3.36, and 8.2.35 as fixed releases for the respective branches. It urges immediate updates and directs users of distribution or LTS packages to their vendors for patched packages.
My response record would identify the web-facing application, observed runtime, package or image supplier, update owner, and evidence required to confirm the running workload is patched. Include less obvious PHP-handled routes, not just addresses ending in a PHP extension.
Microsoft specifically calls out rebuilding and redeploying images containing their own PHP runtime: updating the host does not update the PHP inside those images. Runtime and container guidance.
For a managed runtime, confirm the applicable platform or vendor update path and the version actually serving requests. Do not assume that a generic host patch record establishes the application runtime's state.
Check the Exact Azure WAF Product
As of October 22, Microsoft's guidance says the Azure Front Door response-side managed rule 99006001 is rolling out, with completion expected by October 28. It is disabled by default and requires customer enablement once available. Its response mitigation does not generate WAF log entries or hit counts. Current rollout details.
That is not a statement that every existing policy is automatically protected. Confirm availability, ruleset compatibility, and the documented action requirements for your actual policy before recording it as an applied control.
Microsoft describes different interim mechanisms for Front Door, Application Gateway, and Application Gateway for Containers. Follow the product-specific guidance rather than copying a configuration between them. Service-specific mitigation paths.
Custom Rules Need Application Evidence
The separate custom-rule article covers session-upload-progress and deeply nested form-parameter patterns. Its nesting examples use 20 levels as an application-policy threshold, not a vulnerability-defined safe boundary.
Microsoft warns about legitimate traffic matches, request-body inspection limits, and earlier terminal Allow rules bypassing later checks. It recommends testing rules independently and starting applicable nesting rules in Log mode before considering enforcement. These controls are incomplete mitigation, even when correctly deployed. Validation considerations.
My implementation review would require a validated deployment procedure for the selected WAF engine, match variables, policy scope, and rule order. Resolve any mismatch between a published example and the available editor or API before treating the control as effective.
Do not use a copied rule definition as its own acceptance evidence.
Keep Emergency Changes Reviewable
For a bounded validation, I would retain the prior configuration, use harmless application requests, and check legitimate forms, uploads, and session behavior. Record expected outcomes separately for request-side logging and response-side mitigation.
Avoid testing exploit payloads against production to prove protection. Use an authorized security test process and a controlled environment for any deeper validation.
Give each temporary control an owner and review date. Keep the patch work moving in parallel, with an explicit escalation when the runtime cannot be updated promptly.
If suspicious activity is identified, follow the organization's incident-response process; applying a mitigation should not be treated as evidence that an affected workload was never compromised.
Practical Cloud Engineer Takeaway
Prioritize patched PHP runtimes and rebuilt application images.
Confirm the protection available on the actual Azure WAF product.
Do not mistake a rolling-out, disabled rule for enabled coverage.
Validate custom-rule behavior and legitimate traffic impact.
Keep temporary mitigation separate from completed remediation.
Who Should Care?
Teams operating PHP web workloads behind Azure Front Door or Application Gateway, including application owners, container maintainers, and security responders.
Bottom Line
Use Azure WAF guidance as supplementary protection while patching. Close the remediation task only when the running PHP workload's update is verified, not when a policy change has merely been saved.
No WAF policy, runtime, image, request test, or security setting was executed or changed for this post. Consult the linked advisories for current updates.
Sources
Stay radical, stay curious, and keep pushing the boundaries of what is possible in the cloud.
Chriz
Beyond Cloud with Chriz
Comments