Two newly disclosed vulnerabilities in libmodsecurity, the core engine powering the widely deployed ModSecurity Web Application Firewall (WAF), expose organizations to detection bypass risks that undermine the very security boundary the tool is meant to enforce.
Security researcher airween published both advisories last week, affecting all libmodsecurity versions up to v3.0.15, with fixes shipped in v3.0.16.
The more severe of the two, tracked as CVE-2026-52747, carries a CVSS score indicating High severity and stems from a parser differential bug in how ModSecurity handles multipart form data. The second, CVE-2026-52761, is a Moderate-severity flaw affecting the t:utf8toUnicode transformation specifically on i386 architectures.
The root cause lives in src/request_body_processor/multipart.cc, where ModSecurity’s multipart/form-data parser mishandles buffered bytes held in m_reserve.
When reassembling non-file form-field values, the code was supposed to prepend reserved bytes to the current buffer, but a coding error causes the reserved data to be immediately overwritten instead of appended:
d.assign(&(m_reserve[1]), m_reserve[0]);
d.assign(m_buf, MULTIPART_BUF_SIZE - m_bufleft);The second assign() call replaces the string entirely rather than appending to it. Practically, this means a form field submitted with an embedded line break, say, a value like A\r\nB gets silently collapsed into AB before ModSecurity ever evaluates it in ARGS or ARGS_POST.
File-upload parts don’t share this flaw since they write reserved bytes before the buffer, but standard text form fields are fully exposed under the default modsecurity.conf-recommended configuration, where SecRequestBodyAccess On is enabled out of the box.
The danger here isn’t memory corruption or data leakage; CVSS confirms no confidentiality or availability impact. It’s an integrity failure in rule inspection. Backend applications that preserve line breaks will process the raw field value with its embedded \r\n or \n intact, while ModSecurity’s rule engine sees a sanitized, line-break-free version.
Any WAF rule relying on multiline patterns to catch injection payloads think SQLi fragments split across lines, header-injection attempts, or log-poisoning strings can slip through undetected.
Making this worse, the built-in strict multipart validation variables (MULTIPART_STRICT_ERROR, MULTIPART_LF_LINE, MULTIPART_CRLF_LF_LINES) all remain at 0 during exploitation, meaning the shipped detection safety net doesn’t catch the anomaly either.
The researcher’s proof-of-concept, built by compiling the actual parser source with lightweight stubs, confirmed the bypass reproducibly for both CRLF and bare LF sequences.
“This is a textbook case of CWE-180 validating before canonicalizing,” the advisory notes, since ModSecurity’s strict-mode checks run before the data is fully normalized, letting corrupted values slip past inspection cleanly.
CVE-2026-52761 is narrower in scope but still notable for anyone running ModSecurity on 32-bit architecture. In utf8_to_unicode.cc, three separate snprintf() calls use sizeof(reinterpret_cast<char *>(unicode)) to determine buffer size, but this returns the size of a pointer (4 bytes on i386), not the actual buffer length.
On 64-bit systems this coincidentally matches the intended buffer size, masking the bug entirely. On i386, it doesn’t, corrupting transformation output and letting rules using t:utf8toUnicode be bypassed. The CoreRuleSet team caught this after adding i386 test coverage to their CI pipeline.
- Upgrade libmodsecurity to v3.0.16 immediately, especially if running WAF rules that inspect multiline payloads in POST bodies.
- Audit CRS or custom rulesets for dependencies on multiline pattern matching within
ARGS/ARGS_POST. - Migrate away from i386 deployments where feasible, or confirm patched builds before relying on
t:utf8toUnicodetransformations. - Add regression tests validating that embedded
\r\n/\nsequences in multipart fields survive parsing unchanged.
Both issues underscore a recurring theme in WAF security: the effectiveness of any inspection engine hinges entirely on parsing fidelity between the security layer and the backend it protects.
About the Author
