CVE-2026-13763

Think of AWS WAF as a security guard that checks incoming requests for harmful content. With this issue, the “guard’s inspection” can get tricked when traffic comes in using HTTP/2 and the request content arrives in pieces, so the guard may only check part of what’s actually coming. That creates a pathway for harmful content to get through the usual checks and reach your application.

This matters if you run AWS Application Load Balancer with AWS WAF enabled and your traffic to the ALB uses HTTP/2, since the flaw is in the HTTP/2 request parsing and its impact on WAF body inspection. It’s a remote issue that does not require a login or user interaction. Whether it’s reachable depends on your ALB configuration and whether the affected HTTP/2 inspection paths are actually used in your setup (the findings don’t confirm default reachability).

Treat this as urgent to address in the near term because it targets WAF body inspection and is triggered remotely with no authentication. There is no public exploit code on record and this issue is not listed in CISA KEV, so it is not confirmed as widely exploited; however, the impact potential (malicious payloads reaching your application) is high enough to warrant immediate configuration review.

1. Scope your exposure

   • Check your AWS Application Load Balancer configuration:
     • Is AWS WAF enabled on the ALB?
     • Is HTTP/2 being used for requests to the ALB?
   • Confirm your ALB target groups that receive HTTP/2 traffic (the finding notes this issue impacts HTTP/2 ALB target groups).

2. Apply AWS’s remediation setting

   • In each relevant ALB target group (associated to the ALB load balancer), enable the target group configuration: “Inspect after sufficient data”.
   • This is the direct remediation called out in the provided AWS guidance.

3. Validate

   • Generate/observe normal application traffic through the ALB and ensure WAF still blocks what it should (and logs show full inspection behavior rather than partial-body behavior).
   • Review AWS WAF logs for changes in inspected request characteristics (for example, confirm that requests are evaluated after sufficient data is present).

4. If you can’t change settings immediately

   • Reduce risk by limiting exposure of the ALB endpoints that accept HTTP/2 requests to only the necessary networks/clients.
   • Increase monitoring on WAF and ALB access patterns for suspicious payload characteristics and anomalies, and prioritize enabling “Inspect after sufficient data.”

5. Track updates

   • Since the findings state no traditional patch/version fix information is available, monitor AWS documentation and advisories for any additional mitigations or service-side changes.

Severity and type: The reported CVSS is 9.8, and the weakness is CWE-444 (inconsistent interpretation). Mechanism: AWS Application Load Balancer’s HTTP/2 stream parser can be confused by specially crafted HTTP/2 requests that fragment the request body across multiple HTTP/2 frames; as a result, AWS WAF may inspect only a partial body instead of the full request payload. Attack prerequisites from findings: AWS Application Load Balancer with AWS WAF enabled, using HTTP/2; the attack is remote and does not require authentication or user interaction. Exploit status: no public exploit code is listed in the findings, and the issue is not present in CISA KEV; therefore, exploitation is not confirmed via these findings. Remediation guidance: use the “Inspect after sufficient data” target group setting for the affected ALB HTTP/2 target groups so WAF performs body inspection after sufficient request data is available.