corazawaf Coraza WAF fails to flag truncated multipart bodies, enabling parser-disagreement bypasses

OWASP Coraza WAF is a golang modsecurity compatible web application firewall library. From 3.4.0 until 3.8.0, the multipart processor in internal/bodyprocessors/multipart.go treats io.ErrUnexpectedEOF as nonfatal without setting MULTIPART_STRICT_ERROR. A remote attacker can submit a truncated multipart body that produces io.ErrUnexpectedEOF, causing parsing to stop without raising the strict-error signal used by the recommended defensive rule. Rules 200002 and 200003 do not fire, allowing multipart parser-disagreement payloads to reach a backend that interprets the truncated body differently. This issue is fixed in version 3.8.0.

• The github.com/corazawaf/coraza/v3 package from corazawaf Coraza is affected for >= 3.4.0, < 3.8.0.
• The vendor advisory expresses the same released range as >= 3.4.0, <= 3.7.0.
• The issue is fixed in 3.8.0. This does not establish the status of every later or parallel release branch.
• The advisory states that releases before 3.4.0 used different behavior and did not exhibit this bypass; that qualification applies only to the bypass described here.

The affected component is the multipart processor in internal/bodyprocessors/multipart.go. When file-part or field-part processing encounters io.ErrUnexpectedEOF, the code treats it as nonfatal without setting MULTIPART_STRICT_ERROR. Across three handling sites, this allows parsing to stop on an incomplete body while the function can still return success instead of reporting a body error. As a result, REQBODY_ERROR is not propagated and the recommended defensive rules 200002 and 200003 in coraza.conf-recommended do not fire. An attacker must send a truncated multipart body to a Coraza-protected request path; if the backend uses a parser with different behavior, fields or payload data that Coraza did not fully validate may still be processed by the backend. The exact downstream effect depends on the deployed backend parser and integration.

The flaw is remotely reachable over the network through an HTTP request containing a truncated multipart body. The supplied attack characteristics require no authentication and no user interaction. The request must produce io.ErrUnexpectedEOF, while the backend parser determines whether a usable parser disagreement occurs. The supplied record marks public exploit as false; real-world exploitation status is not established because the known exploited field is unspecified.

The technical outcome is a validation bypass between the WAF and the backend: Coraza may continue processing a body that should raise a strict error, while the backend may parse that body differently. This can cause an integrity impact or security-rule bypass in the downstream component, depending on the endpoint and backend parser. The impact can cross from the WAF into the backend, but the available evidence does not establish a confidentiality or availability impact. Exploitation requires no prior privileges or user interaction, but it does require a multipart processing path and a backend interpretation difference that can be used by the attacker.

• A malformed multipart request that the WAF is intended to reject may continue to the backend.
• If the backend accepts or extracts fields differently from Coraza, an attacker may achieve a rule bypass or influence data processed by the application.
• Possible business consequences include unauthorized state changes or actions at endpoints that rely on multipart data, but the outcome depends on the backend and application logic.
• The available evidence does not establish data disclosure, service interruption, a specific breach, or a named victim.

1. Upgrade the Coraza package to 3.8.0, the confirmed release containing the fix. Do not treat this as confirmation that every future or parallel release branch has been verified.
2. If an upgrade is not immediately possible, apply the source-level change in internal/bodyprocessors/multipart.go to set MULTIPART_STRICT_ERROR when io.ErrUnexpectedEOF occurs at all three handling sites, while preserving the nonfatal ProcessPartial behavior.
3. Confirm that coraza.conf-recommended or an equivalent policy still enforces rule 200002 for REQBODY_ERROR and rule 200003 for MULTIPART_STRICT_ERROR.
4. For deployments that intentionally allow partial processing, review the policy for rule 200003. The advisory describes either changing the rule to detection-only or scoping the exception with a secondary check that confirms whether the request-body limit was actually reached.
5. Retest incomplete multipart bodies in staging and confirm that the WAF, rule engine, and backend make consistent accept or reject decisions.

• Inventory deployments using github.com/corazawaf/coraza/v3 and compare their versions with the affected range in the affected summary.
• Review the corresponding code or binary behavior for internal/bodyprocessors/multipart.go, especially the file and field multipart branches that handle io.ErrUnexpectedEOF.
• Confirm that the deployment loads and enforces rules 200002 and 200003, and review telemetry for REQBODY_ERROR and MULTIPART_STRICT_ERROR when malformed bodies are processed.
• In a non-production test environment, submit truncated multipart requests safely and verify that the strict-error signal is set, policy is applied, and both defensive rules respond as expected.
• Compare the fields and values observed by the WAF with the data received by the backend. This is a precautionary check, not a confirmed indicator.
• Absence of a rule log entry does not prove that a deployment is safe; combine version, code-path, configuration, and test-result checks.