CVE-2026-52761: 
ModSecurity vulnerability analysis and mitigation

CVE-2026-52761 is a security feature bypass vulnerability in ModSecurity, an open-source cross-platform Web Application Firewall (WAF) engine for Apache, IIS, and Nginx. The flaw affects ModSecurity versions 3.0.0 through 3.0.15 and causes the t:utf8toUnicode transformation to produce incorrect output on i386 (32-bit) architecture, allowing WAF rules that rely on this transformation to be bypassed. It was disclosed on June 29, 2026 via a GitHub Security Advisory and assigned CVE-2026-52761, with a fix released in version 3.0.16. The CVSS v3.1 base score is 5.3–5.8 (Medium/Moderate), depending on the scoring authority (GitHub Advisory, Red Hat).

The root cause is classified as CWE-467 (Use of sizeof() on a Pointer Type) and CWE-131 (Incorrect Calculation of Buffer Size). In src/actions/transformations/utf8_to_unicode.cc, the snprintf() call incorrectly uses sizeof(reinterpret_cast<char*>(unicode)) as its buffer size argument — this returns the size of a char pointer (4 bytes on i386) rather than the actual length of the unicode buffer (8 bytes). On 64-bit systems, the pointer size happens to equal the buffer length, masking the bug; on i386, the truncated buffer causes the transformation to produce wrong output, causing rules using t:utf8toUnicode to fail to match malicious payloads. The fix in commit edcd010 changes the unicode variable from unsigned char* to a stack-allocated char[8] array and passes sizeof(unicode) directly, correctly reflecting the buffer size (GitHub Advisory, Fix Commit).

An unauthenticated remote attacker can send crafted HTTP requests containing UTF-8 encoded payloads (e.g., full-width XSS vectors like %ef%bc%9cscript%ef%bc%9e) that bypass ModSecurity WAF rules relying on the t:utf8toUnicode transformation on i386 systems, allowing malicious requests to reach the protected web application undetected. The primary impact is an integrity bypass — the WAF's protective rules are rendered ineffective — with no direct confidentiality or availability impact from the vulnerability itself. The downstream risk depends on what attacks the bypassed rules were designed to prevent (e.g., XSS, SQLi), and is limited to deployments running ModSecurity on 32-bit i386 architecture (GitHub Advisory, Red Hat Bugzilla).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the time of disclosure (Feedly). The vulnerability is automatable (no user interaction or privileges required) but is constrained to i386 architecture deployments, significantly limiting the attack surface. The EPSS score is approximately 0.44%, indicating a low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No threat actor attribution has been reported.

1. Identify target: Locate web applications protected by ModSecurity 3.0.0–3.0.15 running on i386 (32-bit) architecture, using server banners, error pages, or fingerprinting tools.
2. Identify applicable rules: Determine which ModSecurity rules on the target use the t:utf8toUnicode transformation (e.g., OWASP CRS rule 941110 for XSS detection).
3. Craft bypass payload: Encode a malicious payload using full-width or multi-byte UTF-8 characters that would normally be normalized by t:utf8toUnicode (e.g., use full-width angle brackets %ef%bc%9c for < and %ef%bc%9e for > in an XSS payload like /?var=%ef%bc%9cscript%20%ef%bc%9ealert%281%29%ef%bc%9c/script%ef%bc%9e).
4. Send crafted request: Submit the HTTP request to the target. On i386, the truncated snprintf buffer causes the transformation to produce incorrect Unicode output, preventing the WAF rule from matching the malicious pattern.
5. Achieve objective: The malicious request passes through the WAF unblocked and reaches the backend web application, enabling attacks such as XSS or other injection attacks that the bypassed rules were designed to prevent (GitHub Advisory, Fix Commit).

• Network: HTTP requests containing full-width UTF-8 encoded characters (e.g., %ef%bc%9c, %ef%bc%9e, %ef%bc%9a) in query parameters or request bodies that are not blocked by ModSecurity on i386 systems; requests that would normally trigger WAF rules (e.g., CRS rule 941110) passing through without a 403 response.
• Logs: ModSecurity audit logs showing requests with multi-byte UTF-8 encoded payloads that were not matched or blocked by rules using t:utf8toUnicode; absence of expected WAF block entries for known attack patterns on i386 hosts.
• Application Logs: Unexpected XSS or injection-related activity in backend application logs originating from requests that should have been blocked by the WAF.

Upgrade ModSecurity to version 3.0.16, which contains the fix for this vulnerability (ModSecurity v3.0.16 Release). If immediate patching is not possible, migrate ModSecurity deployments from i386 to x86-64 (64-bit) architecture, where the bug does not manifest due to the pointer size coincidentally matching the buffer length. Alternatively, review and disable or replace WAF rules that rely on the t:utf8toUnicode transformation on affected i386 systems until the upgrade can be applied (GitHub Advisory, Red Hat).

The vulnerability was discovered by the OWASP CoreRuleSet team, who noticed test failures when running checks against i386 images and reported the issue to the ModSecurity maintainers (GitHub Advisory). Several security news outlets covered the disclosure, including GBHackers, CyberSecurityNews, and IT Security News, framing it alongside the companion vulnerability CVE-2026-52747 as ModSecurity WAF rule evasion flaws (GBHackers, CyberSecurityNews). Community reaction has been measured, with the practical impact recognized as limited due to the i386 architecture constraint.