CVE-2026-33691

Imagine your security system is a bouncer who checks a guest’s ID by looking at the file extension (like “.jpg” or “.pdf”). This bug lets someone put extra spaces inside the filename so the bouncer looks at the wrong part and mistakenly lets a harmful file type through. If the web server can then treat that uploaded file as executable code, attackers may be able to take over the site.

This matters if you run a web application firewall that uses the OWASP ModSecurity Core Rule Set (coreruleset) for detecting and blocking risky file uploads. The bypass does not require the attacker to be logged in, and it involves uploading files with a filename crafted to include whitespace around dangerous extensions. It becomes a risk when an attacker can reach your application’s file upload feature and your CRS version is prior to 3.3.9 (or 4.25.0), and the upload-checking logic is covered by the affected rules.

This is an AMBER issue because attackers can bypass upload extension checks over the network without needing an account. While there’s no clear public report of real-world exploitation in the findings, the fix is straightforward and addresses a direct path to uploading malicious files. Update the CRS rules to the fixed versions as soon as possible and verify upload blocking after the change.

1. Confirm exposure (check installed CRS version)

   • Locate the OWASP ModSecurity Core Rule Set (coreruleset) version actually loaded by your ModSecurity/compatible WAF in the production environment.
   • Determine whether the version is prior to 3.3.9 or prior to 4.25.0.

2. Apply the fix

   • If you are on a version earlier than 3.3.9, upgrade OWASP ModSecurity Core Rule Set to 3.3.9.
   • If you are on a version earlier than 4.25.0, upgrade OWASP ModSecurity Core Rule Set to 4.25.0.
   • Use the vendor’s patched release/commit referenced in the advisory; avoid partial/manual rule edits unless you can guarantee the whitespace-handling behavior is corrected.

3. Verify the remediation

   • Exercise your normal upload feature with harmless files.
   • Separately test that uploads with dangerous extensions are blocked even when the filename includes whitespace padding (for example, a filename that places spaces so the dangerous extension appears padded).
   • Confirm your WAF logs/alerts reflect the blocking behavior after the update.

4. Temporary workaround (if you cannot patch immediately)

   • Follow the vendor’s mitigation guidance from the OWASP CRS/coreruleset security advisory for GHSA-rw5f-9w43-gv2w, and ensure your upload handling does not rely solely on extension-based checks.

5. What to monitor

   • Monitor WAF logs around upload endpoints for requests attempting filename variations with whitespace.
   • Watch for repeated upload attempts and any unusual upload outcomes during the upgrade window.

CISA KEV note

• This CVE is not listed in the CISA KEV set per the findings.

Severity is reflected as medium (CVSS 6.8). The weakness is CWE-178 (improper neutralization of special elements used in a command/regex-like context), specifically around filename extension matching when whitespace padding is introduced. Mechanism: the affected CRS rules fail to normalize whitespace before evaluating file extension patterns, so crafted names like “photo. php” or “shell.jsp” can bypass the extension regex check and permit upload of dangerous extensions such as .php, .phar, .jsp, and .jspx.

Attack vector and prerequisites: network-reachable when an attacker can reach the upload function; authentication is not required per the findings; no user interaction is required.

Exploitation status: no clear dated real-world exploitation claims are present in the findings; no public exploit code is noted. KEV is not listed. EPSS is a low predicted likelihood (trend flat), but exploitation indicators from KEV/news are not present here, so urgency aligns with AMBER.

Fix: resolved in OWASP ModSecurity Core Rule Set (coreruleset) 3.3.9 and 4.25.0.