Working: HTTP parameter pollution attacks APIs because WAFs evaluate one parameter value while frameworks execute a different one

When a web application receives multiple values for the same parameter, its behavior depends on the framework used to process the request. For example, in PHP, the WAF might block the request based on the first value, while the Spring Boot controller may execute the request using the last value. This discrepancy allows attackers to exploit the difference between the WAF's inspection and the framework's execution.

The Apache, Django, and Ruby on Rails frameworks read the last value, while ASP.NET, Express.js, Flask, and Java Servlet/ Spring read the first value. This inconsistency in how frameworks handle parameter pollution poses a significant risk to API security. Most WAF vendors do not block all possible HPP scenarios, leaving room for exploitation.

The most sophisticated HPP payload achieved a 70.6% WAF bypass rate in the Ethiack study, while the simplest achieved a 17.6% bypass rate. Several high-severity vulnerabilities have been disclosed due to HTTP Parameter Pollution in APIs, including CVE-2025-7783, CVE-2021-20085, and CVE-2022-25871. These vulnerabilities allowed attackers to gain unauthorized access, perform account takeover, and execute arbitrary code.

The root cause of these issues lies in the separation between the WAF's inspection layer and the framework's execution layer. API teams should be aware of the framework-specific behavior when handling query strings and JSON bodies, as the absence of duplicate-key ambiguity in JSON parsers does not eliminate the risk. Addressing the HPP vulnerability requires upgrading affected libraries and implementing proper input validation and sanitization to prevent unauthorized access and code execution.