V3: Coraza: Silent argument drop at ArgumentLimit allows bypass of ARGS-targeted rules via parameter flooding (CVE-2026-41510)

Coraza WAF v3 enforces a per-collection argument limit (default 1000) by silently dropping additional GET, POST, or PATH request arguments once the limit is reached, without setting error flags or logging. Due to Go's randomized map iteration order, which arguments are dropped is non-deterministic, allowing attackers to flood requests with filler parameters to probabilistically evade ARGS-targeted SecRules. The POST urlencoded body processor does not enforce this limit at all, allowing unbounded ARGS_POST growth and bypass. This silent argument drop enables evasion of OWASP CRS rules for SQLi, XSS, RCE, and LFI. The vulnerability is also present in ModSecurity v3 but is partially mitigated by default recommended configurations. The issue affects Coraza versions >=3.0.0 and <3.8.1.

Attackers can bypass any security rule inspecting ARGS, ARGS_GET, ARGS_NAMES, ARGS_GET_NAMES, or ARGS_PATH by sending requests with more arguments than the configured limit (default 1000). The probability of bypass increases with the number of extra arguments, reaching up to 94% bypass rate with 10,000 arguments. This results in evasion of critical detection rules for SQL injection, cross-site scripting, remote code execution, and local file inclusion. Additionally, the POST urlencoded processor bypasses the argument limit entirely, creating a potential memory denial-of-service vector. The silent nature of the drop means no audit logs or flags indicate the bypass, complicating detection and response.

A patch is available for Coraza WAF v3 to address this issue. Operators should upgrade to a fixed version >=3.8.1. Until patched, monitoring for unusually large numbers of request arguments and applying external rate limiting or request size limits may help mitigate exploitation risk. The vendor advisory confirms a fix is available. No other vendor advisory content contradicts this. The POST urlencoded processor's bypass should also be addressed in the patch. Operators should review and apply the patch promptly to prevent evasion and potential memory DoS.