ModSecurity Vulnerabilities Let Attackers Bypass WAF Rules

Two ModSecurity vulnerabilities can let attackers bypass web application firewall rules under specific conditions. The flaws are tracked as CVE-2026-52747 and CVE-2026-52761, and both have been fixed in ModSecurity 3.0.16.

The more serious issue, CVE-2026-52747, affects how libmodsecurity parses multipart form data. The second issue, CVE-2026-52761, affects the utf8toUnicode transformation on i386 systems. The ModSecurity project says users should upgrade their WAF to version 3.0.16 to stay protected.

ModSecurity acts as an inspection layer between web traffic and backend applications. When its parser or transformation logic changes what rules see, attackers may create requests that look safe to the WAF but reach the application in a different form.

What was fixed in ModSecurity 3.0.16?

The ModSecurity 3.0.16 release includes fixes for both vulnerabilities. The release notes list a fix for wrong utf8toUnicode behavior on i386 architecture and a fix for multipart/form-data request body handling involving carriage return and newline characters.

CVE-2026-52747 has a high severity rating with a CVSS score of 8.6. CVE-2026-52761 has a moderate severity rating with a CVSS score of 5.8.

The issues affect ModSecurity versions up to 3.0.15. Administrators using vulnerable versions should update quickly, especially if ModSecurity inspects multipart form submissions or runs on older 32-bit i386 infrastructure.

CVE	Severity	Affected area	Impact	Fixed version
CVE-2026-52747	High, CVSS 8.6	Multipart/form-data parser	Rules may inspect altered form-field values	3.0.16
CVE-2026-52761	Moderate, CVSS 5.8	utf8toUnicode transformation on i386	Rules using the transformation may be bypassed	3.0.16

CVE-2026-52747 affects multipart form inspection

The high-severity flaw sits in the multipart/form-data request body parser in libmodsecurity. According to the GitHub advisory for CVE-2026-52747, the parser silently removes embedded line breaks from non-file form-field values before exporting them to ARGS and ARGS_POST.

This creates a parser mismatch. ModSecurity rules may inspect a field value with line breaks removed, while the backend application still receives the original value with the line breaks preserved.

For example, a form field containing a line break can become a joined value during inspection. If a malicious payload depends on that line break, the WAF rule may miss it even though the application later processes the original content.

Why the multipart parser bug is risky

The risk comes from request-body inspection integrity. ModSecurity often acts as a security boundary, so rules need to evaluate the same input that the backend application will process.

The CVE-2026-52747 advisory says the issue can bypass detection or blocking rules for inputs where a line break changes meaning. This may include parser-sensitive payloads, multiline injection attempts, or signatures that depend on delimiters across line boundaries.

The advisory also notes that strict multipart validation variables may remain clear in reproduced cases. That means built-in multipart checks may not flag the altered request as suspicious.

• The issue affects non-file form fields.
• The parser can remove carriage return and newline characters before rule inspection.
• Backend applications may still receive the original line breaks.
• Rules that inspect ARGS or ARGS_POST can miss certain payloads.

CVE-2026-52761 affects i386 systems

The second vulnerability is narrower because it affects the utf8toUnicode transformation only on i386 architecture. The GitHub advisory for CVE-2026-52761 says rules using this transformation can be bypassed on i386 systems.

The problem comes from use of sizeof on a pointer type. On i386, the pointer size is 4 bytes, which causes the transformation to produce the wrong output. On 64-bit systems, the behavior does not trigger in the same way because the pointer size is 8 bytes.

This makes the bug architecture-specific, but still important for organizations that run legacy 32-bit systems or test images. Any rule relying on the affected transformation may inspect malformed normalized data instead of the intended value.

Who should patch first?

Any organization using ModSecurity 3.0.15 or earlier should plan an update. The priority rises for deployments that inspect multipart form submissions, protect upload forms, process contact forms, or use custom rules built around ARGS and ARGS_POST.

Teams should also review older infrastructure. The CVE-2026-52761 advisory lists moving away from i386 as a workaround, which makes architecture review part of the remediation process.

The ModSecurity project published its explanation on June 29, 2026, the same day the CVEs were released. The project credits external reporters and maintainers for identifying and fixing the issues.

1. Check the installed ModSecurity version across production, staging, and test systems.
2. Upgrade vulnerable ModSecurity 3 deployments to version 3.0.16.
3. Review rules that inspect ARGS, ARGS_POST, multipart form fields, and utf8toUnicode output.
4. Test multipart form submissions with embedded line breaks after patching.
5. Retire i386 deployments where possible, especially for internet-facing WAF infrastructure.

What administrators should monitor after updating

After installing the patch, administrators should review WAF logs for unusual multipart/form-data requests. Attempts that contain unexpected line breaks in form fields may deserve closer inspection, especially if they target login forms, upload endpoints, search fields, or API gateways.

Security teams should also confirm that rules behave consistently before and after backend parsing. A WAF can only block reliably when its parser view matches the application’s view closely enough for rules to make accurate decisions.

The 3.0.16 release notes also include other fixes, but the two CVE patches are the urgent security changes. For most deployments, the safest response is to update first, then validate custom rules and parser-dependent protections.

FAQ