CVE-2026-114099 in Coraza
Summary
by MITRE • 10/22/2026
Coraza from 3.0.0 before 3.8.1 has a JSON body processor that flattens nested properties into dot-separated ARGS_POST names without escaping literal dots, so distinct properties collide. Unauthenticated attackers can add a later dotted property such as account.role that overwrites a malicious nested value, hiding SQL injection payloads from OWASP CRS rules while backends still receive them.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/22/2026
The vulnerability identified in Coraza versions prior to 3.8.1 stems from an improper handling of JSON body parsing within the ModSecurity-compatible web application firewall engine. Specifically, the default JSON body processor flattens nested object properties into a single-dimensional set of ARGS_POST variables by using dot notation as a separator between parent and child keys. This design choice fails to escape or handle literal dots that may exist within property names themselves, leading to ambiguous key resolution when distinct properties share similar prefixes but differ in their final segments. For instance, if an application defines both account.role and account_role, the parser's naive flattening logic can cause these two distinct fields to collide into a single ARGS_POST entry because it does not distinguish between structural dots used for nesting and literal dots within keys. This collision results in unpredictable overwriting behavior where later-parsed values overwrite earlier ones or vice versa depending on parsing order, creating an inconsistent state of the request variables available to subsequent security rules.
This technical flaw creates a significant bypass opportunity against rule-based intrusion detection systems such as the OWASP Core Rule Set which rely heavily on ARGS_POST for detecting injection attacks like SQL Injection and Cross-Site Scripting. An unauthenticated attacker can craft a malicious JSON payload that exploits this ambiguity by including both a legitimate-looking field and a hidden malicious field with overlapping prefixes separated by dots or underscores in ways that trigger the collision logic. By carefully ordering these fields, an attacker can ensure that their malicious payload overwrites the value checked by security rules while leaving another variable containing the actual attack vector intact for backend processing. Consequently, the web application firewall fails to detect and block the injection attempt because it inspects a sanitized or overwritten version of the data, whereas the backend server receives the original unfiltered input containing the SQL injection strings.
The operational impact of this vulnerability is severe as it effectively neutralizes one of the primary layers of defense for applications using Coraza with JSON content types. Attackers can bypass authentication checks, extract sensitive database information through blind or error-based SQL injection techniques, and potentially achieve remote code execution if the backend processes these inputs without additional validation. Since the flaw allows hiding payloads from automated security rules, it undermines the assumption that WAFs provide comprehensive protection against application-layer attacks. The vulnerability affects any system relying on Coraza versions 3.0.0 through 3.8.1 for JSON request inspection and is particularly dangerous in environments where complex nested JSON structures are common or when developers use naming conventions involving dots within property names.
Mitigation strategies primarily involve upgrading to Coraza version 3.8.1 or later, which addresses the parsing logic to properly escape literal dots and prevent key collisions during flattening operations. In cases where immediate upgrade is not feasible, administrators should consider disabling the JSON body processor if it is not strictly required for their specific rule sets, thereby forcing requests through alternative inspection methods that do not suffer from this ambiguity. Additionally, implementing strict input validation on backend applications to sanitize or reject inputs containing unexpected characters can provide a secondary layer of defense against injection attempts that might bypass the WAF due to parsing errors. Organizations should also review their OWASP CRS configurations to ensure they are robust enough to handle edge cases in JSON parsing and consider adding specific rules to detect anomalous patterns in ARGS_POST variables that indicate potential evasion techniques involving nested structures or unusual key naming conventions. This issue is categorized under CWE-20 Improper Input Validation as it relates to the failure to correctly validate and normalize input data, leading to security rule bypasses. From an ATT&CK perspective, this vulnerability facilitates T1505.003 Web Shell: Server Side Template Injection or more broadly T1190 Exploit Public-Facing Application by allowing attackers to evade detection mechanisms that are designed to block exploitation attempts at the network perimeter.