OWASP Coraza WAF silently drops arguments, enabling rule bypass and memory exhaustion

OWASP Coraza WAF is a golang modsecurity compatible web application firewall library. From 3.0.0 until 3.8.1, Coraza silently drops arguments after SecArgumentsLimit in internal/corazawaf/transaction.go, while internal/bodyprocessors/urlencoded.go writes ARGS_POST without enforcing the cap. The flaw is triggered when an unauthenticated attacker sends more arguments than SecArgumentsLimit or supplies bodies that expand beyond the configured argument and flattening budgets. An unauthenticated attacker can flood requests with arguments so excess values are silently omitted from ARGS, ARGS_GET, ARGS_NAMES, ARGS_GET_NAMES, ARGS_POST, or ARGS_PATH before security rules inspect them; affected urlencoded and JSON processing can also consume excessive memory. The omission can bypass WAF rules protecting the downstream application, and unbounded or amplified argument processing can cause memory consumption and service degradation. This issue is fixed in version 3.8.1.

• Package github.com/corazawaf/coraza/v3 is affected at >= 3.0.0, < 3.8.1. • The affected scope includes deployments using Coraza to process query arguments, urlencoded request bodies, or JSON bodies that can expand into many arguments. • 3.8.1 is the confirmed patched release. The advisory states that 3.8.0 remains affected because the earlier fix did not fully cover JSON array-length writes and the flattening byte budget. • The record does not establish that other branches or wrappers outside this range are automatically unaffected.

OWASP Coraza WAF stores request arguments in collections such as ARGS, ARGS_GET, ARGS_POST, and ARGS_PATH. In internal/corazawaf/transaction.go, argument-addition paths can silently return after reaching SecArgumentsLimit without setting an error or a transaction signal that security rules can use to detect the drop. For GET arguments, the remaining values can also be non-deterministic because the vulnerable extraction path iterates parsed map data, so the omitted value is not necessarily the tail of the request. In internal/bodyprocessors/urlencoded.go, data can be written directly into ARGS_POST without enforcing the cap, while JSON flattening can create many entries and consume memory beyond the configured budget. The attacker needs network reachability to a Coraza-protected endpoint and control over query or request-body input; authentication is not required. Whether the bypass produces an application-level security impact depends on the downstream application and on rules that rely on these collections, while the specific deployment integration is not established by the record.

The flaw is remotely reachable through requests containing more arguments than the configured limit or bodies that expand into excessive arguments or flattened data. No authentication or user interaction is required, and the attack complexity is low because an attacker can add excess arguments or body content to trigger the affected paths. Argument omission in the GET path can vary depending on which values survive processing, while the urlencoded and JSON body processors expose separate limit-enforcement gaps. The vendor advisory documents testing and a proof of concept, but the supplied record does not establish observed exploitation, a named campaign, or a separate public exploit.

Attacker-controlled arguments can be removed from a collection before security rules inspect them, causing a rule protecting the downstream application to miss part of the input. This weakens inspection integrity, but it is not itself a direct mechanism for reading confidential data. If the downstream application processes the request and relies on the omitted parameters for sensitive behavior, the bypass may enable an application-level integrity impact or defeat one protection layer. The urlencoded and JSON paths can also consume excessive memory and reduce service availability; the record does not establish that every deployment will crash.

• Security controls that depend on ARGS may evaluate an incomplete request, reducing their ability to detect or block a payload before it reaches the downstream application. • The protected application may receive parameters that the corresponding rule did not inspect; the practical effect depends on the application's logic and deployed rules. • Unbounded or amplified argument processing can increase heap usage, reduce throughput, and degrade service when multiple requests are sent. • The record describes inspection bypass and resource consumption, not direct data disclosure.

1. Upgrade github.com/corazawaf/coraza/v3 to 3.8.1. This is the confirmed fixed release; do not treat 3.8.0 as safe because it remains within the affected range.
2. If an immediate upgrade is not possible, apply and validate the vendor's compensating-rule guidance to reject requests when argument parsing is truncated. Treat this as temporary protection because the advisory identifies separate urlencoded and JSON paths that require the code fix.
3. Redeploy every application, binary, and integration that contains Coraza directly or transitively. Verify the resolved dependency in build artifacts and runtime inventory rather than assuming a wrapper or reverse proxy is fixed without checking its embedded Coraza library.
4. After upgrading, test rules targeting ARGS, ARGS_GET, ARGS_NAMES, ARGS_GET_NAMES, ARGS_POST, and ARGS_PATH with over-limit requests in a controlled environment.
5. Review WAF memory limits, alerting, and capacity controls so excessive body processing or JSON flattening is detected during the migration.

1. Inventory binaries, modules, and dependencies using github.com/corazawaf/coraza/v3, including wrappers and integrations that embed Coraza indirectly, then compare the resolved release with the affected range.
2. Identify deployments that accept attacker-controlled query strings, application/x-www-form-urlencoded bodies, or JSON bodies, especially endpoints protected by rules targeting ARGS, ARGS_GET, ARGS_NAMES, ARGS_GET_NAMES, ARGS_POST, or ARGS_PATH.
3. Review SecArgumentsLimit and the configured request-body and JSON-flattening budgets to determine where input can be truncated or amplified.
4. In an authorized test environment, submit requests that exceed the configured limits and verify that truncation is surfaced, rejected, or handled explicitly by rules rather than silently passed to the downstream application.
5. Review WAF audit logs, request-body processing errors, memory alerts, and heap or restart telemetry during periods involving high-argument or large-body requests. Treat this as precautionary monitoring, not as a confirmed indicator.
6. Do not treat the absence of log entries or errors as proof of safety, because the vulnerable behavior can omit data without producing a clear signal.