Coraza WAF Request Body Inspection Bypasses

JSON body inspection bypass in Coraza 3.0.0 through 3.8.1 lets unauthenticated remote attackers hide SQL-injection payloads from OWASP CRS rules while the backend still receives and processes them. The flaw is in Coraza's JSON body processor, which flattens nested objects into dot-separated ARGS_POST names without escaping dots that appear literally in property names, so a decoy sibling key such as "account.role" overwrites the flattened entry for the nested "account.role" value inside Coraza's map while standard backend JSON parsers keep both properties intact. Real-world impact is conditional: the bypass only matters where the protected application has an injectable downstream sink, though the vendor advisory demonstrates the evasion working against CRS v4.25 rule 949110; no public exploit code was identified and there is no KEV/active-exploitation signal, and independent assessment rates the direct risk as integrity-only (CVSS 3.1 5.3, C:N/I:L/A:N) rather than as code execution.

Request body inspection bypass in Coraza WAF versions 3.0.4 through 3.8.0 allows unauthenticated remote attackers to evade custom body rules by sending a valid URL-encoded form body with a Content-Type parameter such as 'application/x-www-form-urlencoded; charset=UTF-8', leaving ARGS_POST and REQUEST_BODY empty while the backend still parses the payload. This is a moderate-priority WAF evasion issue rather than a server compromise; deployments that rely on custom ARGS_POST or REQUEST_BODY rules are exposed, while an unmodified current OWASP CRS with rule 901340 forces fallback inspection and neutralizes the bypass. No public exploit identified at time of analysis; vendor-released patch: 3.8.1.

Coraza WAF before 3.8.1 can be induced to record a decoy multipart filename for FILES-based inspection while a downstream application receives a different, attacker-chosen name, allowing upload-name restrictions to be bypassed when the backend honors RFC 5987 filename* parameters. The root cause is Go's mime.ParseMediaType, which silently discards filename* values whose charset is not us-ascii or utf-8, so a header such as filename*=iso-8859-1''shell.php is either masked by a benign plain filename or, when filename* appears alone, causes the part not to be classified as a file upload at all. Exploitation is unauthenticated but requires both FILES/FILES_SIZES-based Coraza rules and a backend that itself parses filename*, and no public exploit identified at time of analysis.