Protect against Brotli CVE-2026-111497 with Azure Web Application Firewall (WAF)
Google Brotli versions 1.0.3 through 1.2.0 contain a buffer overflow vulnerability in the Brotli decoder, according to the recently published CVE-2026-111497. A remote, unauthenticated attacker can send a crafted Brotli-compressed stream to corrupt decoder memory, expose sensitive memory contents, cause a denial of service, or potentially run arbitrary code. Any application that decompresses untrusted Brotli data may be affected. This includes Node.js and Python applications that bundle the vulnerable decoder, and services that accept request bodies with the Content-Encoding: br header. We strongly recommend upgrading Brotli to a patched version: 1.0.10, 1.1.1 or 1.2.1 (Brotli releases). If you use Node.js, upgrade to 22.23.4, 24.22.1 or 26.12.1 (Node.js security release). If you can't patch your applications right away, Azure WAF on Application Gateway and Azure Front Door can help mitigate the inbound attack vector, which is Brotli-compressed request bodies sent to your application. Note: Azure WAF inspects only inbound requests to your application. It can't protect applications that fetch and decompress Brotli-encoded responses from external servers. Those applications must be patched. Built-in protection enabled by default If you use Azure WAF with DRS 2.2, on Application Gateway or Azure Front Door Premium, you're protected by default against the crafted requests we analyzed. Rule 920450 (Paranoia Level 1, enabled by default) checks requests against a list of restricted headers, and DRS 2.2 adds Content-Encoding to that list. The rule has a critical anomaly score, so a single match blocks the request when the WAF policy is in Prevention mode. Earlier rule set versions don't restrict this header. If you're still on DRS 2.1, CRS 3.2 or earlier, we recommend upgrading to DRS 2.2 to get the latest protection. To learn how, see Upgrade CRS or DRS ruleset version. Custom rule to mitigate CVE-2026-111497 We recommend the custom rule below for: WAF policies still on DRS 2.1 or earlier, while you plan the upgrade. WAF policies where rule 920450 is disabled or overridden. Azure Front Door Standard, which supports custom rules only. Managed rule sets require Azure Front Door Premium. The custom rule blocks any request whose Content-Encoding header includes the br (Brotli) coding, which this attack uses. This rule may also block legitimate clients sending Brotli-compressed request bodies. If you aren't sure whether your application accepts them, set the action to 'Log traffic only' first, and review your WAF logs before switching to 'Deny traffic'. You can remove the rule once your applications are patched, or your policy is using DRS 2.2 to mitigate this attack. Azure WAF on Application Gateway Apply this rule on Azure WAF policy using CRS 3.2, DRS 2.1 or DRS 2.2 only. If you are using CRS 3.0 or CRS 3.1, upgrade your ruleset version to a later version first, then apply the custom rule. { "name": "CVE2026111497", "priority": 100, "ruleType": "MatchRule", "action": "Block", "matchConditions": [ { "matchVariables": [ { "variableName": "RequestHeaders", "selector": "Content-Encoding" } ], "operator": "Regex", "matchValues": [ "(?:^|,)[ \\t]*br[ \\t]*(?:,|$)" ], "transforms": [ "Lowercase" ] } ] } Azure WAF on Azure Front Door { "name": "CVE2026111497", "priority": 120, "enabledState": "Enabled", "ruleType": "MatchRule", "action": "Block", "matchConditions": [ { "matchVariable": "RequestHeader", "selector": "Content-Encoding", "operator": "RegEx", "negateCondition": false, "transforms": [ "Lowercase" ], "matchValue": [ "(?:^|,)[ \\t]*br[ \\t]*(?:,|$)" ] } ] } Restrict request size The proof-of-concept payloads analyzed so far are about 23 MB each. Attackers may be able to craft smaller payloads, so treat size limits as an extra layer of protection, not a mitigation on their own. Whatever rule set version you use, we recommend the following: Azure WAF on Application Gateway and Application Gateway for Containers The proof-of-concept payloads are well above the default maximum request body size of 128 KB on Application Gateway. We recommend setting the maximum request body size in your WAF policy to the smallest value your application needs. Learn more. Azure WAF on Azure Front Door To limit request body size, create a custom rule with a size constraint. For request body checks, the size is measured on the decoded body. Set the limit to the smallest value your application needs and make sure request body inspection is enabled in your WAF policy settings. The following example blocks request bodies larger than 40 KB. This rule supports limits of up to 128 KB. { "name": "BlockLargeRequestBody", "priority": 130, "enabledState": "Enabled", "ruleType": "MatchRule", "action": "Block", "matchConditions": [ { "matchVariable": "RequestBody", "operator": "GreaterThan", "negateCondition": false, "matchValue": [ "40960" ] } ] } You can find more information about custom rules on Azure WAF for Application Gateway or for Azure Front Door.
Addressing PHP2Shell CVE-2026-109618 and CVE-2026-109619: upgrade guidance and Azure WAF mitigations
Written in collaboration with yuvalpery and Gunjan Jain Introduction Today, two critical remote code execution (RCE) vulnerabilities were disclosed in PHP. We strongly recommend that customers upgrade to a patched version of PHP as soon as possible. Upgrading is the only way to fully remediate these vulnerabilities. Read more on the PHP official website. Microsoft has been part of the coordinated industry response to these vulnerabilities, working alongside the PHP Foundation, Wiz, security researchers, and other industry partners to help protect customers. Azure Web Application Firewall (WAF) has developed mitigations against known exploitation patterns to provide an additional layer of protection while customers apply the PHP security updates. These protections are intended to complement patching and are not a replacement for it. About the vulnerabilities: CVE-2026-109618 - RCE via OOM corruption CVE-2026-109619- RCE via stale global state Both vulnerabilities can be exploited over the network without privileges or user interaction, with a high potential impact on confidentiality, integrity, and availability. The vulnerabilities relate to PHP handling of memory when a request terminates abnormally, for example due to memory exhaustion or a fatal error. Under certain conditions, improper memory handling could allow an attacker to achieve remote code execution. Fixed versions: 8.5.12, 8.4.27, 8.3.36, 8.2.35. Refer to vendor guidancefor patching of different versions of PHP. Recommended action: upgrade PHP We recommend that customers: Upgrade all PHP deployments to a patched version, including virtual machines, containers, base images, and platform runtimes. We suggest prioritizing internet-facing workloads. Rebuild and redeploy container images that include their own PHP runtime, since updating the host does not update PHP inside an image. Migrate to a supported PHP branch if the branch currently in use no longer receives security fixes. Treat the Azure WAF mitigations below as a temporary, supplementary measure. They address a specific technique and do not remediate the underlying vulnerabilities. Azure WAF protection If you are unable to upgrade PHP to a patched version immediately, apply the following mitigations in the interim - Azure Front Door WAF: Apply the mitigation using custom rules for request-side mitigation and enable the managed rule for response-side mitigation. Application Gateway WAF: Apply the mitigation using custom rules for request-side mitigation and enable the rewrite rule for response-side mitigation. Application Gateway for Container WAF: Apply the mitigation using custom rules for request-side mitigation. See below sections for details. Mitigation using custom rules These custom rules can help reduce exposure to selected request patterns associated with exploitation techniques for these vulnerabilities. Depending on application traffic, the rules may result in false positives and affect legitimate requests. They are intended as temporary mitigations and do not replace the need to upgrade PHP. Learn more: Azure WAF custom rules for PHP2Shell mitigation. Request-side signals alone may not be sufficient to reliably identify certain exploitation attempts. Signals in the server response can provide additional evidence that malicious activity has occurred, enabling more targeted mitigation with higher confidence and lower false positives. For this vulnerability, Azure WAF identifies known malicious patterns in the session and removes the potentially malicious elements from the response before it reaches the client. This provides an additional layer of protection for supported exploitation scenarios, while patching PHP remains necessary to fully address the underlying vulnerability. Azure Front Door WAF: managed rule A managed rule to handle potential attack vector in response is currently rolling out for Azure Front Door WAF, expected to complete October 28. Once the rule is available, its details are as follows: Rule group: MS-ThreatIntel-Response-CVEs Rule ID: 99006001 Default state: disabled. Customers need to enable the rule. Supported rulesets: DRS 2.0, 2.1 and 2.2. Unlike other WAF rules, this rule does not block or challenge any traffic. When the rule identifies malicious signals in the session that provides strong evidence of exploitation, it removes the potentially malicious elements from the response while leaving the remainder of the response unchanged. Mitigation for this rule takes effect only when the rule action is set to Block on anamoly. Please note that the response side mitigation does not generate WAF log entries or hit counts. Application Gateway WAF: rewrite rule Customers can apply an interim mitigation now using the HTTP header rewrite capability of Application Gateway, which is available on v2 SKUs. A WAF managed rule for Application Gateway is expected to roll out at a later date. Until then, we recommend the following rewrite rule: 1. Create a rewrite rule in a rewrite set associated with your routing rule(s). 2. Add a condition that evaluates the Set-Cookie response header against the following regular expression: ^PHPSESSID=(?:[a-zA-Z0-9-]|%2[Cc])*(?:[^a-zA-Z0-9;%-]|%(?!2[Cc]))+[a-zA-Z0-9-]*[^;]+; 3. Set the action to delete the matching Set-Cookie response header. Alternatively, the header can be set to a replacement value of your choice. Please note that setting a value overwrites the entire header, including attributes such as Path=/;. Additional considerations: The rule applies only to a Set-Cookie header that matches the pattern. Other Set-Cookie headers in the same response are not affected. We recommend validating the rule on a non-production gateway before broader deployment. For further information, see Rewrite HTTP headers and URL with Azure Application Gateway. Application Gateway for Containers (AGC): A WAF managed rule for Application Gateway for Containers is expected to roll out at a later date. In the interim, customers can apply the custom rules. Application Gateway for Containers does not support regex-based rewrite rules on HTTP response. Summary Service Available protection Recommended action Azure Front Door WAF Custom rules, managed rule 99006001 rolling out, expected to complete by 28 October 2026; mitigation using high confidence signals without blocking traffic. Upgrade PHP to a patched version. If you are unable to patch, apply custom rules in the interim. Application Gateway WAF Custom rules, header rewrite mitigation available now; managed rule expected to roll out later. Upgrade PHP to a patched version. If you are unable to patch, apply custom and rewrite rule in the interim. Application Gateway for Containers Custom rules, managed rule expected to roll out later. Upgrade PHP to a patched version. If you are unable to patch, apply custom rules. Conclusion Following PHP security guidance and upgrading to a patched version is the recommended and complete remediation. Azure WAF mitigations can help reduce exposure during the upgrade period, and we encourage customers to upgrades at the earliest opportunity. Changelog 10/21/2026 9:00 PM PST – Updated with additional guidance around custom rules 10/22/2026 9:00 AM PST – Updated rule rewrite regular expressionAzure WAF custom rules for PHP2Shell mitigation
Written in collaboration with Gunjan Jain and yuvalpery As described in our earlier blog, Addressing PHP2Shell CVE-2026-109618 and CVE-2026-109619: upgrade guidance and Azure WAF mitigations, we strongly recommend upgrading to a patched version of PHP as soon as possible. Upgrading PHP remains the recommended and complete remediation for these vulnerabilities. For customers who are unable to upgrade immediately, this guidance provides WAF custom rules that can help reduce exposure to selected request patterns associated with exploitation techniques for these vulnerabilities. WAF custom rules The following three custom rules can be considered based on your application configuration and traffic patterns. Because custom rules can affect legitimate application traffic, review the potential application impact and validate the rules before enabling enforcement. Restrict PHP session upload progress PHP supports session upload progress for tracking file uploads. For applications that do not depend on this functionality, customers can use a custom rule to restrict multipart form requests containing PHP_SESSION_UPLOAD_PROGRESS. The rule checks for multipart/form-data requests whose inspected request body contains the PHP session upload progress token. Custom rule definitions: Azure Front Door WAF { "name": "BlockPhpSessionUploadProgress", "priority": 100, "enabledState": "Enabled", "ruleType": "MatchRule", "action": "Block", "matchConditions": [ { "matchVariable": "RequestHeader", "selector": "Content-Type", "operator": "Contains", "negateCondition": false, "transforms": ["Lowercase"], "matchValue": ["multipart/form-data"] }, { "matchVariable": "RequestBody", "operator": "Contains", "negateCondition": false, "matchValue": ["php_session_upload_progress"], "transforms": ["Lowercase"] } ] } Application Gateway and Application Gateway for Container (AGC) WAF { "name": "BlockPhpSessionUploadProgress", "priority": 90, "ruleType": "MatchRule", "action": "Block", "state": "Enabled", "matchConditions": [ { "matchVariables": [ { "variableName": "RequestHeaders", "selector": "Content-Type" } ], "operator": "Contains", "negationConditon": false, "matchValues": [ "multipart/form-data" ], "transforms": [ "Lowercase" ] }, { "matchVariables": [ { "variableName": "PostArgs" } ], "operator": "Contains", "negationConditon": false, "matchValues": [ "php_session_upload_progress" ], "transforms": [ "Lowercase" ] } ] } This rule reduces exposure through the PHP session-upload-progress path but does not address all exploitation paths associated with the vulnerabilities. Potential application impact: Applications that legitimately use PHP session upload progress will also match this rule. A substring match may also detect the token when it appears as harmless text or in uploaded content exposed to inspection. Limit deeply nested form parameters Customers can use a custom rule to identify unusually deep parameter nesting in application/x-www-form-urlencoded requests. The proposed rule detects request field names containing 20 or more levels of bracket nesting after URL decoding. Because the 20-level threshold is an application policy choice rather than a vulnerability-defined boundary, legitimate applications using deeply nested parameters may also match this rule. Custom rule definitions: Azure Front Door WAF: { "name": "PhpFormNesting20", "priority": 110, "enabledState": "Enabled", "ruleType": "MatchRule", "action": "Log", "matchConditions": [ { "matchVariable": "RequestHeader", "selector": "Content-Type", "operator": "BeginsWith", "negateCondition": false, "transforms": [ "Trim", "Lowercase" ], "matchValue": [ "application/x-www-form-urlencoded" ] }, { "matchVariable": "RequestBody", "operator": "RegEx", "negateCondition": false, "transforms": [ "UrlDecode" ], "matchValue": [ "(?:^|&)[^&=\\[]+(?:\\[[^&=\\]]*\\]){20}" ] } ] } Application Gateway and Application Gateway for Container (AGC) WAF { "name": "PhpFormNesting20", "priority": 91, "ruleType": "MatchRule", "action": "Log", "state": "Enabled", "matchConditions": [ { "matchVariables": [ { "variableName": "RequestHeaders", "selector": "Content-Type" } ], "operator": "BeginsWith", "negationConditon": false, "matchValues": [ "application/x-www-form-urlencoded" ], "transforms": [ "Trim", "Lowercase" ] }, { "matchVariables": [ { "variableName": "RequestBody" } ], "operator": "Regex", "negationConditon": false, "matchValues": [ "(?:^|&)[^&=\\[]+(?:\\[[^&=\\]]*\\]){20}" ], "transforms": [ "UrlDecode" ] } ] } Recommended deployment: Start with the rule in Log mode and review matches against legitimate application traffic. Consider moving the rule to Block only after validating application compatibility. Limit deeply nested multipart parameters Customers can apply a similar control to multipart/form-data requests by detecting deeply nested field names. The proposed rule detects multipart field names containing 20 or more levels of nesting where the relevant request content is available to WAF inspection. As with deeply nested URL-encoded parameters, legitimate applications may use complex multipart field structures. Custom rule definitions: Azure Front Door WAF { "name": "PhpMultipartNesting20", "priority": 111, "enabledState": "Enabled", "ruleType": "MatchRule", "action": "Log", "matchConditions": [ { "matchVariable": "RequestHeader", "selector": "Content-Type", "operator": "BeginsWith", "negateCondition": false, "transforms": [ "Trim", "Lowercase" ], "matchValue": [ "multipart/form-data" ] }, { "matchVariable": "RequestBody", "operator": "RegEx", "negateCondition": false, "matchValue": [ "(?i)(?:^|\\r?\\n)content-disposition:[ \\t]*form-data[^\\r\\n]*;[ \\t]*name[ \\t]*=[ \\t]*(?:\"(?:\\\\[\"\\\\]|[^\"\\r\\n\\[])+(?:\\[(?:\\\\[\"\\\\]|[^\"\\r\\n\\]])*\\]){20}|[^ \\t\\r\\n;\"\\[]+(?:\\[[^ \\t\\r\\n;\"\\]]*\\]){20})" ] } ] } Application Gateway and Application Gateway for Container (AGC) WAF { "name": "PhpMultipartNesting20", "priority": 92, "ruleType": "MatchRule", "action": "Log", "state": "Enabled", "matchConditions": [ { "matchVariables": [ { "variableName": "RequestHeaders", "selector": "Content-Type" } ], "operator": "BeginsWith", "negationConditon": false, "matchValues": [ "multipart/form-data" ], "transforms": [ "Trim", "Lowercase" ] }, { "matchVariables": [ { "variableName": "PostArgs" } ], "operator": "Regex", "negationConditon": false, "matchValues": [ "^[^\\[\\]]+(?:\\[[^\\]]*\\]){20}" ], "transforms": [] } ] } This rule targets deeply nested multipart field names. It does not restrict every multipart upload or provide complete mitigation for the underlying vulnerabilities. Recommended deployment: Start in Log mode, review matching traffic, and consider moving to Block only after validating the impact on your application. Deployment and validation considerations We recommend applying these custom rules only to affected PHP application domains and routes, including extensionless routes handled by PHP, rather than broadly applying them to unrelated applications. Before enabling enforcement: Review the potential impact on legitimate application traffic. Test each custom rule independently before deploying the rules together. Start applicable rules in Log mode and review legitimate matches. Verify the WAF policy scope and custom-rule precedence. After changing a rule to Block, validate both application behavior and the corresponding WAF events. Continue to prioritize upgrading PHP even when these controls are deployed. Custom rules may produce false positives, and WAF request-body inspection boundaries can affect coverage. An earlier terminal Allow rule in the WAF policy can also bypass subsequent custom-rule checks. The custom rules described above target selected request patterns associated with exploitation techniques for CVE-2026-109618 and CVE-2026-109619. They reduce selected attack surfaces but do not provide complete protection against either vulnerability. You can find more information about Custom Rules on Azure WAF for Application Gateway here or for Azure Front Door here. Upgrading to a patched version of PHP remains the recommended and complete remediation.
Designing Cloud Landing Zones by Traffic Flow: A Defence‑in‑Depth, DMZ‑First Architecture
As enterprises adopt Microsoft Azure for large‑scale and regulated workloads, security architecture must be driven by traffic trust boundaries and inspection intent, not connectivity alone. Regulatory frameworks consistently require a clear separation between Internet‑untrusted and private enterprise traffic, enforced through defence‑in‑depth controls aligned to the OSI model. This drives the adoption of a DMZ‑first landing zone architecture, where volumetric protection, application‑layer inspection, and perimeter controls are enforced at well‑defined trust boundaries. Security enforcement is prioritised before access, rather than being an afterthought of connectivity. A distributed hub architecture enables this model at scale, delivering consistent controls while improving resiliency, fault isolation, and operational clarity. Traffic Classification in an Enterprise Landing Zone Enterprise traffic flows are classified based on origin, destination, and trust level, which directly dictates inspection requirements: Internet Inbound (North–South): Traffic from the public Internet to Azure‑hosted applications Internet Outbound (South–North): Egress traffic from private workloads to the Internet East–West: Traffic between virtual networks within or across regions Hybrid Connectivity: Traffic between Azure, on‑premises, and multi‑cloud environments Each flow presents a distinct risk profile, making a uniform connectivity and inspection model unsuitable for enterprise and regulated environments. Hub‑and‑Spoke as the Foundation for Centralised Security Enterprises commonly adopt a Hub‑and‑Spoke topology using VNET peering or Azure Virtual WAN, extending hybrid connectivity via Site‑to‑Site VPN or ExpressRoute. The hub provides a centralised, datapath‑centric layer for shared networking and security services, while spoke VNETs host application workloads and remain private, typically without public IPs. Ingress and egress are handled through shared, centrally managed endpoints. This model consolidates critical controls—Azure Firewall, Azure WAF, and DDoS protection—at controlled entry and exit points, significantly reducing the attack surface. Integration with Microsoft Sentinel enables cross‑layer visibility, threat hunting, and detection of risks such as unauthorised access and data exfiltration. Why a Single Hub Is Not Sufficient Using a single hub to process all traffic types introduces operational and security challenges at scale by forcing Internet‑untrusted and private traffic through the same inspection tier. Key limitations include: Coupled Internet and private security policies Rapid firewall rule sprawl and management overhead A single blast radius across all traffic types Throughput and SNAT scalability constraints Increased difficulty meeting regulatory separation requirements These issues become more pronounced as environments scale across regions and workloads. Multi‑Hub as an Enterprise‑Grade Evolution A multi‑hub architecture resolves these challenges by separating inspection responsibilities across dedicated hubs: DMZ Hub VNET: Internet‑facing traffic and perimeter security enforcement Core Hub VNET: Outbound Internet access, East‑West, and hybrid traffic inspection This separation aligns security controls with traffic intent, reduces policy complexity, limits blast radius, and simplifies operations. In the next section, we explore multi‑hub architecture patterns and examine how each traffic flow is inspected and governed in practice. Scenario 1 – Third‑Party Firewall–Centric Multi‑Hub Design In this scenario, third‑party firewalls provide inspection for all traffic flows—Internet inbound, Internet outbound, East‑West, and hybrid connectivity—while Azure WAF and Azure DDoS Protection are used to defend against volumetric attacks, application‑layer threats, and malicious bot traffic. Architecture Overview The design uses two dedicated hub virtual networks, with spoke VNets peered to both hubs to maintain traffic separation based on trust and inspection requirements: DMZ Hub VNET (Internet Ingress Hub) Core Hub VNET (Egress, East‑West, and Hybrid Hub) DMZ Hub VNET – Internet Inbound (North–South) Traffic The DMZ hub establishes a dedicated perimeter for Internet‑facing applications. Internet traffic lands on a public Application Gateway with Azure WAF, protected by an Azure DDoS Protection Plan applied to the public frontend IP. Third‑party firewalls are deployed behind the Application Gateway to perform deep packet inspection. Firewalls operate in active‑active mode as standalone appliances, using three dedicated network interfaces (Untrust, Trust, and Management), each placed in separate subnets. Application Gateway provides load balancing and health probing, ensuring firewall availability and resiliency. Core Hub VNET – Egress, East‑West, and Hybrid Traffic The core hub handles all non‑Internet‑inbound traffic flows, including private inter‑VNET communication and hybrid connectivity. Third‑party firewalls are deployed behind an internal Azure Load Balancer, which maintains high availability using health probes. Firewalls follow the same active‑active, three‑NIC design for consistent policy enforcement and operational symmetry. Azure NAT Gateway is associated with the firewall Untrust subnet to scale outbound SNAT and simplify Internet egress with deterministic public IP. Site‑to‑site VPN or ExpressRoute terminate in this hub for on‑premises and multi‑cloud connectivity, ensuring private and regulated traffic bypasses Internet‑facing controls. Architecture Patterns - Traffic Flow 1.1 North–South (Internet Inbound) Traffic Flow This flow applies when applications hosted on Azure (VMs, VM Scale Sets, or services behind Internal Load Balancer / Internal Application Gateway) are published to the Internet. As shown in the diagram, Internet-bound client requests enter Azure through a dedicated DMZ Hub, where perimeter security controls are enforced before traffic reaches private application spokes. Inbound Request Flow (Blue Path) Client → Application Gateway (WAF) A client request (for example, app1.example.com) is resolved via DNS and lands on the public endpoint of Azure Application Gateway. Azure WAF performs Layer‑7 inspection, bot protection, and rule evaluation. Application Gateway → Firewall (DMZ Hub) Based on hostname and routing rules, Application Gateway forwards traffic to the firewalls while preserving the client’s real IP using the X‑Forwarded‑For (XFF) header. Firewall → Application (Spoke VNET) The firewall performs DNAT to the internal destination (Internal Application Gateway or Internal Load Balancer) and SNAT to its trust‑interface IP to ensure symmetric return traffic. Traffic is then routed over VNET peering to the private application workload. Response Flow (Green Path) Application → Firewall The application responds using its private IP, with the firewall trust interface as the destination. Firewall → Application Gateway The firewall forwards the response based on its session state. Application Gateway → Client Application Gateway returns the response to the Internet client. DDoS Protection Azure DDoS Protection continuously monitors the Application Gateway public IP and mitigates volumetric attacks before they reach the application stack. Key Design Considerations Application Gateway routing - Use a multi‑site listener with hostname‑based rules to steer traffic to the appropriate firewall backend. Firewall backend mapping - Register firewall VMs in a single backend pool and differentiate applications using distinct backend settings (same protocol, different ports). Application steering at firewall - Firewalls perform port‑based DNAT (or private FQDN‑based DNAT where supported) to forward traffic to the correct application private IP in spoke VNets. Traffic symmetry - Source NAT is applied on the firewall trust interface to maintain symmetric return paths. Protocol support - The same pattern applies to TCP/UDP workloads, using an External Azure Load Balancer instead of Application Gateway where WAF is not required. Client IP visibility Application Gateway enables WAF inspection using the real client IP, preserved downstream via X‑Forwarded‑For. With Azure Load Balancer, client IP is retained up to the firewall for IP‑based enforcement, with Azure DDoS Protection safeguarding the public frontend. 1.2 Hybrid Connectivity Traffic Flow Hybrid connectivity represents communication between Azure workloads and on‑premises environments using Site‑to‑Site VPN or ExpressRoute. Traffic Flow Request (Blue: 1–4): Traffic originates from applications in spoke VNETs and is forwarded via UDRs to the Internal Load Balancer, through active‑active firewalls, and then to on‑premises via VPN or ExpressRoute. Response (Green: 5–8): Return traffic follows the same path in reverse. Key Design Considerations Source and destination IP addresses remain unchanged end‑to‑end, despite firewalls operating behind an Internal Load Balancer. UDRs steer both outbound and inbound hybrid traffic to the Internal Load Balancer as the next hop. Spoke VNET subnets should be associated with custom route tables with Propagate Gateway Routes set to No, preventing gateway-learned routes from bypassing the intended security inspection path configured via UDR. However, VPN Gateway Subnet Route table should have route table with Propagate Gateway Routes set to Yes. Azure Virtual Network Manager can be used to manage and scale UDR deployment centrally across Hub and spoke networks. 1.3 East-West Traffic flow This traffic flow represents the connectivity between resources across VNETs through Firewall. Considerations remain same as “Hybrid Connectivity Traffic flow” mentioned above. 1.4 Egress/Outbound Connectivity Traffic flow This traffic flow represents the connectivity from the resources hosted inside VNETs to Internet through Firewalls deployed behind Internal Load Balancer in Core Hub VNET. Egress/Outbound Connectivity Traffic flow Key Considerations: A default route (0.0.0.0/0) UDR directs Internet-bound traffic to the Internal Load Balancer for firewall inspection. Firewall performs SNAT to its untrusted interface, after which Azure NAT Gateway translates traffic to a fixed public IP. Alternatively, a public IP can be assigned to the firewall untrusted interface to perform SNAT directly, removing the need for NAT Gateway and reducing cost. Spoke VNET subnets should be associated with custom route tables with Propagate Gateway Routes set to No, preventing gateway-learned routes from bypassing the intended security inspection path configured via UDR. However, VPN Gateway Subnet Route table should have route table with Propagate Gateway Routes set to Yes. However, with horizontal firewall scaling, outbound public IPs become non-deterministic. Scenario 2: Third‑Party Firewalls for Ingress, Azure Firewall for Private Flows In this scenario, third‑party firewalls secure Internet‑facing traffic, while Azure Firewall handles Egress, East–West, and Hybrid flows. This separation enables organisations to retain existing perimeter security investments while adopting a fully managed, cloud‑native control and data plane for internal traffic flows. As private traffic patterns scale, particularly for chatty East–West communication, Azure Firewall helps simplify operations and improves scalability by offloading traffic inspection to a managed service. This approach reduces operational overhead and provides consistent policy enforcement across internal and hybrid flows. Setup DMZ Hub design remains unchanged from Scenario 1. Core Hub VNET use Azure Firewall for better scalability, built‑in resilience, and simplified operations. Azure Firewall eliminates the need for load balancers and reduces complexity for chatty east‑west traffic. It requires a single subnet (unless force tunnelling is enabled), optimising IP consumption. Outbound traffic is SNATed by Azure Firewall and further translated via Azure NAT Gateway. Firewall‑based SNAT to public IP can be used to avoid NAT Gateway costs when deterministic egress IPs or higher SNAT scale are not required. Traffic Flow North–South (Internet Inbound) Traffic Flow represented with Numbers. Request flow represented with Blue: 1–3 Response flow represented with Brown: 4–6 Egress/Outbound Connectivity Traffic flow represented with alphabets. Request flow represented with Green: A–C Response flow represented with Blue: D–F Hybrid flow represented with purple Architecture Diagram: Third‑Party Firewalls for Ingress, Azure Firewall for Private Flows Further if you want to use Azure Firewall for the Internet Ingress flow, you can use it as well. Below is the architecture diagram explaining the same pattern. Azure Firewalls for Ingress and Private Flows Key Considerations: Application Gateway behaviour remains the same as Scenario 1; however, backend pools use IP‑based targets. Internal applications should be exposed via internal Application Gateway or internal load balancer to provide stable backend IPs. To optimise traffic flow and avoid unnecessary network address translation, the private IP address of the Application Gateway or internal Load Balancer should be configured in the backend pool of External Load Balancer in DMZ Hub VNET. This design does not need Azure Firewall to perform both source NAT (SNAT) and destination NAT (DNAT) operations. Further, implementing User Defined Routes (UDRs) in the Application Gateway subnet—specifically for spoke VNet CIDR ranges steers traffic routing through the Firewall. For non-web (TCP/UDP) workloads, applications can be directly exposed through the firewall public IP, with Azure DDoS Protection applied to mitigate volumetric attacks. Spoke VNET subnets should be associated with custom route tables with Propagate Gateway Routes set to No, preventing gateway-learned routes from bypassing the intended security inspection path configured via UDR. However, VPN Gateway Subnet Route table should have route table with Propagate Gateway Routes set to Yes. Scenario 3 - Overcoming Peering Complexity at Scale with Azure Virtual WAN In environments where each application is hosted in its own dedicated VNET for isolation and stronger security, a traditional hub‑and‑spoke model quickly becomes complex. With a single hub, "N" spoke VNETs require "N" peering's; introducing multiple hubs increases this to "2N", significantly amplifying operational overhead—especially across multiple regions. Azure Virtual WAN addresses this challenge by eliminating the need for extensive VNET peering. As a global, managed service, it simplifies large‑scale and multi‑region architectures while providing built‑in scalability and operational consistency. Setup DMZ Hub design and components remain unchanged from Scenario 1 keeping defense in depth principles intact for Internet Inbound or North-South traffic. Core Hub VNET is replaced with Azure Virtual WAN Secure Hub which has Azure Firewall inside the managed Secure Hub VNETs. This further eliminates the need for creating Azure Firewall Subnet, Azure NAT Gateway resources for East-West, Egress and Hybrid connectivity and provides same level of security protection as mentioned in Scenario 2. Secure Hub design using Virtual WAN removes the routing and inspection complexity which was unless required in Scenario 2 by removing UDR configurations in Spoke VNETs, Gateway Subnet and Azure Firewall Subnet. This provides simplified design and operations with built-in resiliency by leveraging the managed platform. Azure Firewall eliminates the need for load balancers and reduces complexity for chatty east‑west traffic. East-West, Egress, and Hybrid connectivity happens via VPN Gateway and Express Route Gateway present in Virtual Hub. All private and Internet Egress traffic is inspected by Azure Firewall present in secure Hub. Outbound traffic is SNATed to Public IP by Azure Firewall thus avoiding the need of Azure NAT Gateway. Firewall‑based SNAT to public IP can be used to avoid NAT Gateway costs when deterministic egress IPs or higher SNAT scale are not required. Traffic Flow North–South (Internet Inbound) Traffic Flow represented with Numbers. Request flow represented with Blue: 1–5 Response flow represented with Green: 6–10 Egress/Outbound Connectivity Traffic flow represented with Red Hybrid flow represented with Green East-West connectivity flow represented with black Architecture Diagram: Key Considerations Virtual WAN has additional cost Refer to architecture diagram above for different traffic flows. The DMZ VNET components consideration remains same as per scenario 1 You can use your own managed public IP on Azure Firewall for applying standard IP/Network DDoS protection plan. Benefits of multi-Hub approach over single Hub You can use this table as decision matrix to choose the best option for your application requirements. Dimensions Multi-Hub Design Resiliency · Independent scaling of DMZ and Core firewalls · Failure in Internet inspection does not impact East‑West traffic · Easier multi‑region active‑active designs Security & Compliance Clear trust boundaries Auditable inspection points Easier alignment with Zero Trust & regulatory frameworks Operational Simplicity Smaller, purpose‑built firewall policies Clear ownership (Perimeter vs Core team) Faster troubleshooting due to deterministic flows Cost Optimisation Avoids over‑inspection of East‑West traffic by DMZ firewalls Smaller firewall SKUs per hub Better scale‑unit consumption Performance Efficiency Reduced latency for private traffic No unnecessary hair‑pinning Optimised SNAT and connection tracking Key Takeaways Security‑first landing zones should not be designed as one‑size‑fits‑all networks. By designing hubs based on traffic trust level and inspection intent, rather than convenience, organisations gain: o Stronger security boundaries and better fault isolation o Predictable operations at scale o Lower long‑term cost and complexity o Design for traffic flows, not just connectivity o Use DMZ hubs exclusively for Internet‑untrusted traffic o Use Core hubs for East‑West, outbound, and hybrid connectivity o Map security controls to OSI layers o Avoid single‑hub designs for large, regulated, or multi‑region environments This distributed hub‑and‑DMZ landing zone provides a clean, scalable, and secure foundation for enterprise workloads in any Hyperscaler. For regulated, internet‑exposed, or multi‑region environments, a distributed hub with a dedicated DMZ is no longer optional — it is a foundational architecture decision.How Azure network security can help you meet NIS2 compliance
With the adoption of the NIS2 Directive EU 2022 2555, cybersecurity obligations for both public and private sector organizations have become more strict and far reaching. NIS2 aims to establish a higher common level of cybersecurity across the European Union by enforcing stronger requirements on risk management, incident reporting, supply chain protection, and governance. If your organization runs on Microsoft Azure, you already have powerful services to support your NIS2 journey. In particular Azure network security products such as Azure Firewall, Azure Web Application Firewall WAF, and Azure DDoS Protection provide foundational controls. The key is to configure and operate them in a way that aligns with the directive’s expectations. Important note This article is a technical guide based on the NIS2 Directive EU 2022 2555 and Microsoft product documentation. It is not legal advice. For formal interpretations, consult your legal or regulatory experts. What is NIS2? NIS2 replaces the original NIS Directive 2016 and entered into force on 16 January 2023. Member states must transpose it into national law by 17 October 2024. Its goals are to: Expand the scope of covered entities essential and important entities Harmonize cybersecurity standards across member states Introduce stricter supervisory and enforcement measures Strengthen supply chain security and reporting obligations Key provisions include: Article 20 management responsibility and governance Article 21 cybersecurity risk management measures Article 23 incident notification obligations These articles require organizations to implement technical, operational, and organizational measures to manage risks, respond to incidents, and ensure leadership accountability. Where Azure network security fits The table below maps common NIS2 focus areas to Azure network security capabilities and how they support compliance outcomes. NIS2 focus area Azure services and capabilities How this supports compliance Incident handling and detection Azure Firewall Premium IDPS and TLS inspection, Threat Intelligence mode, Azure WAF managed rule sets and custom rules, Azure DDoS Protection, Azure Bastion diagnostic logs Detect, block, and log threats across layers three to seven. Provide telemetry for triage and enable response workflows that are auditable. Business continuity and resilience Azure Firewall availability zones and autoscale, Azure Front Door or Application Gateway WAF with zone redundant deployments, Azure Monitor with Log Analytics, Traffic Manager or Front Door for failover Improve service availability and provide data for resilience reviews and disaster recovery scenarios. Access control and segmentation Azure Firewall policy with DNAT, network, and application rules, NSGs and ASGs, Azure Bastion for browser based RDP SSH without public IPs, Private Link Enforce segmentation and isolation of critical assets. Support Zero Trust and least privilege for inbound and egress. Vulnerability and misconfiguration defense Azure WAF Microsoft managed rule set based on OWASP CRS. Azure Firewall Premium IDPS signatures Reduce exposure to common web exploits and misconfigurations for public facing apps and APIs. Encryption and secure communications TLS policy: Application Gateway SSL policy; Front Door TLS policy; App Service/PaaS minimum TLS. Inspection: Azure Firewall Premium TLS inspection Inspect and enforce encrypted communication policies and block traffic that violates TLS requirements. Inspect decrypted traffic for threats. Incident reporting and evidence Azure Network Security diagnostics, Log Analytics, Microsoft Sentinel incidents, workbooks, and playbooks Capture and retain telemetry. Correlate events, create incident timelines, and export reports to meet regulator timelines. NIS2 articles in practice Article 21 cybersecurity risk management measures Azure network controls contribute to several required measures: Prevention and detection. Azure Firewall blocks unauthorized access and inspects traffic with IDPS. Azure DDoS Protection mitigates volumetric and protocol attacks. Azure WAF prevents common web exploits based on OWASP guidance. Logging and monitoring. Azure Firewall, WAF, DDoS, and Bastion resources produce detailed resource logs and metrics in Azure Monitor. Ingest these into Microsoft Sentinel for correlation, analytics rules, and automation. Control of encrypted communications. Azure Firewall Premium provides TLS inspection to reveal malicious payloads inside encrypted sessions. Supply chain and service provider management. Use Azure Policy and Defender for Cloud to continuously assess configuration and require approved network security baselines across subscriptions and landing zones. Article 23 incident notification Build an evidence friendly workflow with Sentinel: Early warning within twenty four hours. Use Sentinel analytics rules on Firewall, WAF, DDoS, and Bastion logs to generate incidents and trigger playbooks that assemble an initial advisory. Incident notification within seventy two hours. Enrich the incident with additional context such as mitigation actions from DDoS, Firewall and WAF. Final report within one month. Produce a summary that includes root cause, impact, and corrective actions. Use Workbooks to export charts and tables that back up your narrative. Article 20 governance and accountability Management accountability. Track policy compliance with Azure Policy initiatives for Firewall, DDoS and WAF. Use exemptions rarely and record justification. Centralized visibility. Defender for Cloud’s network security posture views and recommendations give executives and owners a quick view of exposure and misconfigurations. Change control and drift prevention. Manage Firewall, WAF, and DDoS through Network Security Hub and Infrastructure as Code with Bicep or Terraform. Require pull requests and approvals to enforce four eyes on changes. Network security baseline Use this blueprint as a starting point. Adapt to your landing zone architecture and regulator guidance. Topology and control plane Hub and spoke architecture with a centralized Azure Firewall Premium in the hub. Enable availability zones. Deploy Azure Bastion Premium in the hub or a dedicated management VNet; peer to spokes. Remove public IPs from management NICs and disable public RDP SSH on VMs. Use Network Security Hub for at-scale management. Require Infrastructure as Code for all network security resources. Web application protection Protect public apps with Azure Front Door Premium WAF where edge inspection is required. Use Application Gateway WAF v2 for regional scenarios. Enable the Microsoft managed rule set and the latest version. Add custom rules for geo based allow or deny and bot management. enable rate limiting when appropriate. DDoS strategy Enable DDoS Network Protection on virtual networks that contain internet facing resources. Use IP Protection for single public IP scenarios. Configure DDoS diagnostics and alerts. Stream to Sentinel. Define runbooks for escalation and service team engagement. Firewall policy Enable IDPS in alert and then in alert and deny for high confidence signatures. Enable TLS inspection for outbound and inbound where supported. Enforce FQDN and URL filtering for egress. Require explicit allow lists for critical segments. Deny inbound RDP SSH from the internet. Allow management traffic only from Bastion subnets or approved management jump segments. Logging, retention, and access Turn on diagnostic settings for Firewall, WAF, DDoS, and Application Gateway or Front Door. Send to Log Analytics and an archive storage account for long term retention. Set retention per national law and internal policy. Azure Monitor Log Analytics supports table-level retention and archive for up to 12 years, many teams keep a shorter interactive window and multi-year archive for audits. Restrict access with Azure RBAC and Customer Managed Keys where applicable. Automation and playbooks Build Sentinel playbooks for regulator notifications, ticket creation, and evidence collection. Maintain dry run versions for exercises. Add analytics for Bastion session starts to sensitive VMs, excessive failed connection attempts, and out of hours access. Conclusion Azure network security services provide the technical controls most organizations need in order to align with NIS2. When combined with policy enforcement, centralized logging, and automated detection and response, they create a defensible and auditable posture. Focus on layered protection, secure connectivity, and real time response so that you can reduce exposure to evolving threats, accelerate incident response, and meet NIS2 obligations with confidence. References NIS2 primary source Directive (EU) 2022/2555 (NIS2). https://eur-lex.europa.eu/eli/dir/2022/2555/oj/eng Azure Firewall Premium features (TLS inspection, IDPS, URL filtering). https://learn.microsoft.com/en-us/azure/firewall/premium-features Deploy & configure Azure Firewall Premium. https://learn.microsoft.com/en-us/azure/firewall/premium-deploy IDPS signature categories reference. https://learn.microsoft.com/en-us/azure/firewall/idps-signature-categories Monitoring & diagnostic logs reference. https://learn.microsoft.com/en-us/azure/firewall/monitor-firewall-reference Web Application Firewall WAF on Azure Front Door overview & features. https://learn.microsoft.com/en-us/azure/frontdoor/web-application-firewall WAF on Application Gateway overview. https://learn.microsoft.com/en-us/azure/web-application-firewall/overview Examine WAF logs with Log Analytics. https://learn.microsoft.com/en-us/azure/application-gateway/log-analytics Rate limiting with Front Door WAF. https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/waf-front-door-rate-limit Azure DDoS Protection Service overview & SKUs (Network Protection, IP Protection). https://learn.microsoft.com/en-us/azure/ddos-protection/ddos-protection-overview Quickstart: Enable DDoS IP Protection. https://learn.microsoft.com/en-us/azure/ddos-protection/manage-ddos-ip-protection-portal View DDoS diagnostic logs (Notifications, Mitigation Reports/Flows). https://learn.microsoft.com/en-us/azure/ddos-protection/ddos-view-diagnostic-logs Azure Bastion Azure Bastion overview and SKUs. https://learn.microsoft.com/en-us/azure/bastion/bastion-overview Deploy and configure Azure Bastion. https://learn.microsoft.com/en-us/azure/bastion/tutorial-create-host-portal Disable public RDP and SSH on Azure VMs. https://learn.microsoft.com/en-us/azure/virtual-machines/security-baseline Azure Bastion diagnostic logs and metrics. https://learn.microsoft.com/en-us/azure/bastion/bastion-diagnostic-logs Microsoft Sentinel Sentinel documentation (onboard, analytics, automation). https://learn.microsoft.com/en-us/azure/sentinel/ Azure Firewall solution for Microsoft Sentinel. https://learn.microsoft.com/en-us/azure/firewall/firewall-sentinel-overview Use Microsoft Sentinel with Azure WAF. https://learn.microsoft.com/en-us/azure/web-application-firewall/waf-sentinel Architecture & routing Hub‑spoke network topology (reference). https://learn.microsoft.com/en-us/azure/architecture/networking/architecture/hub-spoke Azure Firewall Manager & secured virtual hub. https://learn.microsoft.com/en-us/azure/firewall-manager/secured-virtual-hubAzure WAF Tuning for Web Applications
False positives occur when a Web Application Firewall (WAF) erroneously detects legitimate web traffic as malicious and subsequently denies access. For instance, an HTTP request that poses no threat may trigger WAF to classify it as an SQL injection attack due to how characters are passed through the request body, thereby causing the request to be rejected and denying access to the user. Find out in this post some examples to help reduce false positives in your Azure WAF environment.General availability of Default Ruleset (DRS) 2.2 for Web Application Firewall
Introduction As attackers continue to evolve their techniques, organizations require web application security that keeps pace with emerging threats without disrupting legitimate traffic. Azure Web Application Firewall (WAF) continues to evolve to meet these demands and now supports Default Rule Set (DRS) 2.2 across both Azure Front Door and Azure Application Gateway. The latest recommended Azure WAF ruleset, based on OWASP Core Rule Set (CRS) 3.3.4., DRS 2.2 combines OWASP CRS protections with Microsoft-authored rules developed with the Microsoft Threat Intelligence team, delivering broader coverage, updated signatures, reduced false positives, and a more modern security baseline for your internet-facing applications. What is new in DRS 2.2? DRS 2.2 builds on earlier rule sets with improvements focused on three areas: breadth of coverage, quality of detections, and false positive reductions. Broader security coverage DRS 2.2 is based on the OWASP Core Rule Set 3.3.4, delivering improvements in rule accuracy and new protections for common web vulnerabilities. DRS 2.2 contains 18 rule groups, organizing protections across SQL injections, XSS, protocol violations, remote code execution, and more, making it easier to understand and manage the scope of coverage. Notable improvements include: Detection of mismatched content types, where the declared content-type header does not match the actual payload format. This is a common tactic in evasion and obfuscation attacks. Improved Remote Code Execution (RCE) detections to catch increasingly sophisticated payloads used by threat actors. Microsoft Threat Intelligence rules In addition to the OWASP improvements, DRS 2.2 introduces new Microsoft Threat Intelligence rules. These rules expand coverage for: SQL Injection. Cross-Site Scripting (XSS). Advanced application security attack patterns. Improved false positive reduction with paranoia levels One of the standout features of DRS 2.2 is its paranoia level (PL) configuration, which allows you to balance security and usability. Paranoia levels (PL) determine how aggressively rules in the OWASP Core Rule Set (CRS) detect and block potential threats in a Web Application Firewall (WAF). OWASP CRS defines four paranoia levels (PL1–PL4), each offering progressively stricter security controls: PL1 (Default): Offers baseline protection against common web attacks, minimizes false positives, and is appropriate for most applications. PL2: Adds additional rules targeting more sophisticated threats, which may result in more false positives. PL3: Strict detection rules aimed at high-security environments. PL4: Implements the most aggressive security rules, suitable for highly secure environments, requiring extensive management and tuning efforts. Azure WAF currently does not support rules from paranoia levels 3 and 4. For more information on Azure WAF paranoia levels refer to Paranoia Levels. DRS 2.2 ships with paranoia level 1 (PL1) enabled by default. This gives customers the strongest baseline protection with minimal tuning overhead. DRS 2.2 rules configured in paranoia level 2 are disabled by default. Customers can leave PL2 disabled or selectively enable individual PL2 rules based on their threat model and application behavior. Enabling and upgrading to DRS 2.2 Upgrading to DRS 2.2 is straightforward, but there is an important planning consideration: when you assign a new managed ruleset version through the Azure portal, previous managed-ruleset customizations such as rule state overrides, rule action overrides, and rule-level exclusions are reset to the new defaults. Due to this, it is recommended to use PowerShell, CLI, REST API, or templates when you want to preserve overrides and exclusions, and validating changes in a test environment before production rollout. Please refer to Upgrade CRS or DRS Ruleset Version - Azure Web Application Firewall. To use DRS 2.2: Open your WAF policy (associated with your Azure Front Door or Application Gateway). Navigate to Managed Rules. Select “Assign”. Choose DRS 2.2 from the ruleset dropdown. Review enabled rule groups and optionally configure the rule actions. After upgrading, monitor your logs and metrics to understand traffic behavior and fine-tune as required. Figure 1: Enabling DRS 2.2 in Azure Front Door WAF Figure 2: Enabling DRS 2.2 in Azure Front Door WAF Conclusion Default Rule Set 2.2 marks a significant advancement for Azure Web Application Firewall, providing stronger security coverage, improved detection accuracy, and better control over false positives. By bringing the same modern ruleset experience to both Azure Front Door WAF and Application Gateway WAF, customers can apply a consistent web security baseline across global, regional, and internal application architectures. For customers already using Azure WAF, upgrading to DRS 2.2 is the simplest way to benefit from the latest protections while maintaining operational flexibility. References Web Application Firewall (WAF) on Azure Front Door | Microsoft Learn Web Application Firewall on Azure Application Gateway | Microsoft Learn Azure Front Door WAF - DRS and CRS rule groups and rules | Microsoft Learn Azure Application Gateway WAF - DRS and CRS rule groups and rules Azure Front Door WAF - Default Ruleset 2.2 | Microsoft Learn Application Gateway WAF – Default Ruleset 2.2 | Microsoft Learn Upgrade CRS or DRS Ruleset Version - Azure Web Application Firewall | Microsoft Learn
WAF custom rule for bock others cookie and permit only a specific cookie name and value
Hello all, I need to create a custom WAF rule that only allows traffic for a specific request URI (/example-path) if it contains a particular cookie, Cookie=abc123, and blocks all other requests. Additionally, could someone clarify the difference between configuring the policy this way: RequestHeaders['Cookie'], Operator=DoesNotEqual, Values="Cookie=abc123" RequestCookie, Values="CookieName", Operator=Equal, valueOfTheCookie="abc123" I hope I explained myself clearly. Thanks in advance for your responses!Protect against React RSC CVE-2025-55182 with Azure Web Application Firewall (WAF)
Please subscribe to this blog as we will be updating the suggested rules as new attack permutations are found. On December 3, 2025, the React team disclosed a critical remote code execution (RCE) vulnerability in React Server Components (RSC), tracked as CVE-2025-55182. The vulnerability allows an unauthenticated attacker to send a specially crafted request to an RSC “Server Function” endpoint and potentially execute arbitrary code on the server. This vulnerability affects applications using React RSC in the following versions: 19.0.0 19.1.0 19.1.1 19.2.0 Patched versions are available, and all customers are strongly encouraged to update immediately. About CVE-2025-55182 According to the React security advisory, the issue stems from unsafe deserialization within React Server Components, where server function payloads were not adequately validated. When exploited, an attacker can execute arbitrary code on the server without authentication. The NVD entry classifies this vulnerability as Critical, with a CVSS score of 10.0, due to its ease of exploitation and the potential impact on server-side execution. All organizations using React Server Components — or frameworks that embed RSC capabilities such as Next.js, React Router (RSC mode), Waku, @parcel/rsc, @vitejs/plugin-rsc, or rwsdk — should consider themselves potentially exposed until the relevant patches are applied. Azure WAF Mitigation to CVE-2025-55182 The primary and most effective mitigation for this vulnerability is to upgrade any unpatched React versions to the latest security-patched releases. Mitigation on WAF on Application Gateway or Application Gateway for Containers If you are using the latest and recommended Default Rule Set (DRS) 2.1, or the previous Core Rule Set (CRS) 3.2, a new CVE-specific managed rule is available in Azure Web Application Firewall (WAF) for Application Gateway and Application Gateway for Containers. Please ensure this rule is enabled and retains its default Anomaly Score–based action: Rule ID: 99001018 (DRS 2.1) or 800115 (CRS 3.2) Rule description: Attempted React2Shell remote code execution exploitation (CVE-2025-55182) This CVE-specific rule has also been added to CRS 3.1. However, for enhanced and more comprehensive protection specifically against CVE-2025-55182, we strongly recommend upgrading to DRS 2.1, which includes additional detection coverage and tuning for this vulnerability. If you are using CRS 3.0, there is no built-in CVE-specific protection for CVE-2025-55182, and upgrading to DRS 2.1 is strongly advised. If upgrading is not currently possible, you may implement custom WAF rules to detect this exploit pattern using a Block action. Any custom rules should be validated in a test or staging environment before being enforced in production. Custom rules definition for WAF on Application Gateway and Application Gateway for Containers: "customRules": [ { "name": "cve202555182", "priority": 1, "ruleType": "MatchRule", "action": "Block", "matchConditions": [ { "matchVariables": [ { "variableName": "PostArgs" } ], "operator": "Contains", "negationConditon": false, "matchValues": [ "constructor", "__proto__", "prototype", "_response" ], "transforms": [ "Lowercase", "UrlDecode", "RemoveNulls" ] }, { "matchVariables": [ { "variableName": "RequestHeaders", "selector": "next-action" } ], "operator": "Any", "negationConditon": false, "matchValues": [], "transforms": [] } ], "skippedManagedRuleSets": [], "state": "Enabled" }, { "name": "cve202555182ver2", "priority": 100, "ruleType": "MatchRule", "action": "Block", "matchConditions": [ { "matchVariables": [ { "variableName": "PostArgs" } ], "operator": "Contains", "negationConditon": false, "matchValues": [ "constructor", "__proto__", "prototype", "_response" ], "transforms": [ "Lowercase", "UrlDecode", "RemoveNulls" ] }, { "matchVariables": [ { "variableName": "RequestHeaders", "selector": "rsc-action-id" } ], "operator": "Any", "negationConditon": false, "matchValues": [], "transforms": [] } ], "skippedManagedRuleSets": [], "state": "Enabled" } ], Adding these custom rules may fail if your WAF runs on the old WAF engine. In this case, we strongly recommend upgrading your WAF policy to the next-generation WAF engine by moving to a newer ruleset: either to the latest DRS 2.1 which includes the built-in managed rule (preferred) or to the previous CRS 3.2, then apply the custom rules described above. If upgrading your ruleset version is not an option, and your WAF remains on the old WAF engine, you can instead use the following alternative rules: "CustomRules": [ { "Name": "cve202555182", "Priority": 1, "RuleType": "MatchRule", "MatchConditions": [ { "MatchVariables": [ { "VariableName": "PostArgs" } ], "Operator": "Contains", "MatchValues": [ "constructor", "__proto__", "prototype", "_response" ], "Transforms": [ "Lowercase", "UrlDecode", "RemoveNulls" ] }, { "MatchVariables": [ { "VariableName": "RequestHeaders", "Selector": "next-action" } ], "Operator": "Regex", "MatchValues": [ "." ], "Transforms": [] } ], "Action": "Block" }, { "Name": "cve202555182ver2", "Priority": 2, "RuleType": "MatchRule", "MatchConditions": [ { "MatchVariables": [ { "VariableName": "PostArgs" } ], "Operator": "Contains", "MatchValues": [ "constructor", "__proto__", "prototype", "_response" ], "ATransforms": [ "Lowercase", "UrlDecode", "RemoveNulls" ] }, { "MatchVariables": [ { "VariableName": "RequestHeaders", "Selector": "rsc-action-id" } ], "Operator": "Regex", "MatchValues": [ "." ], "Transforms": [] } ], "Action": "Block" } ] Mitigation for WAF on Azure Front Door: If you are using WAF on Azure Front Door, you can create custom WAF rules to detect this exploit pattern. These custom rules are configured with a Block action. We recommend validating them in a test or staging environment before enforcing them in production. "customRules": [ { "name": "cve202555182", "enabledState": "Enabled", "priority": 1, "ruleType": "MatchRule", "rateLimitDurationInMinutes": 1, "rateLimitThreshold": 100, "matchConditions": [ { "matchVariable": "RequestHeader", "selector": "next-action", "operator": "Any", "negateCondition": false, "matchValue": [], "transforms": [] }, { "matchVariable": "RequestHeader", "selector": "content-type", "operator": "Contains", "negateCondition": false, "matchValue": [ "multipart/form-data", "application/x-www-form-urlencoded" ], "transforms": [ "Lowercase" ] }, { "matchVariable": "RequestBody", "operator": "Contains", "negateCondition": false, "matchValue": [ "constructor", "__proto__", "prototype", "_response" ], "transforms": [ "Lowercase", "UrlDecode", "RemoveNulls" ] } ], "action": "Block", "groupBy": [] }, { "name": "cve202555182ver2", "enabledState": "Enabled", "priority": 2, "ruleType": "MatchRule", "rateLimitDurationInMinutes": 1, "rateLimitThreshold": 100, "matchConditions": [ { "matchVariable": "RequestHeader", "selector": "rsc-action-id", "operator": "Any", "negateCondition": false, "matchValue": [], "transforms": [] }, { "matchVariable": "RequestHeader", "selector": "content-type", "operator": "Contains", "negateCondition": false, "matchValue": [ "multipart/form-data", "application/x-www-form-urlencoded" ], "transforms": [ "Lowercase" ] }, { "matchVariable": "RequestBody", "operator": "Contains", "negateCondition": false, "matchValue": [ "constructor", "__proto__", "prototype", "_response" ], "transforms": [ "Lowercase", "UrlDecode", "RemoveNulls" ] } ], "action": "Block", "groupBy": [] } ] You can find more information about Custom Rules on Azure WAF for Application Gateway here or for Azure Front Door here. Changelog 1/19/2026 5:00 PST - Updated built-in managed rule for CRS 3.2 and CRS 3.1 on WAF for Application Gateway 12/20/2025 11:00 PST - Updated built-in managed rule on WAF for Application Gateway and Application Gateway for Containers 12/7/2025 23:30 PST - Updated custom rules to detect additional attack permutation 12/5/2025 17:45 PST - Updated custom rules to include additional transform "RemoveNulls".
