CVE-2026-33691: 
Progress LoadMaster vulnerability analysis and mitigation

CVE-2026-33691 is a WAF bypass vulnerability in the OWASP ModSecurity Core Rule Set (CRS) that allows unauthenticated attackers to upload files with dangerous executable extensions by inserting whitespace padding in filenames. The vulnerability was reported by @HackingRepo on 2026-03-10, fixes were merged on 2026-03-15, and the advisory was published on 2026-03-28/2026-04-02. Affected versions include all CRS releases prior to 3.3.9 and all 4.x releases prior to 4.25.0. It carries a CVSS v3.1 base score of 7.5 (High) per NVD, or 6.8 (Moderate) per the GitHub Security Advisory, reflecting environment-dependent exploitability (GitHub Advisory).

The root cause is classified as CWE-178 (Improper Handling of Case Sensitivity / input normalization), where CRS rules 933110 (PHP Script File Upload Found, PL1), 933111 (PHP Double-Extension File Upload, PL3), 944140 (JSP File Upload Detection, PL1), and 932180 (Restricted File Upload) apply only t:lowercase transformation before evaluating file extension regexes — without first stripping whitespace. An attacker can craft a multipart file upload request with a filename such as photo. php (space before extension) or shell.jsp (trailing space), causing the dot-extension regex check to fail to match and the upload to pass through the WAF unblocked. On Windows backends that normalize or strip whitespace from filenames before storage, the uploaded file is stored with the executable extension intact (e.g., photo.php), enabling subsequent execution. All paranoia levels up to and including PL4 are affected (GitHub Advisory, PR #4546).

Successful exploitation allows an attacker to upload web shells or other malicious server-side scripts (.php, .phar, .jsp, .jspx) to a target web server, bypassing the WAF's file upload protection entirely. On Windows-based backends where filename whitespace is normalized, the uploaded file can be directly executed, leading to remote code execution, full server compromise, data exfiltration, and potential lateral movement within the network. The integrity impact is rated High; confidentiality and availability impacts depend on subsequent attacker actions post-upload (GitHub Advisory).

No confirmed in-the-wild exploitation has been reported as of the time of publication. A Metasploit Framework pull request (PR #21277) referencing this CVE has been identified, indicating active development of a proof-of-concept exploit module (Feedly). The EPSS score is approximately 0.054% (very low probability of exploitation in the next 30 days), and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation is network-accessible, requires no authentication or user interaction, but is practically limited to environments with Windows backends that normalize whitespace in filenames.

1. Reconnaissance: Identify web applications protected by OWASP CRS versions prior to 3.3.9 or 4.25.0 that expose file upload functionality, particularly those running on Windows backends.
2. Craft malicious filename: Prepare a web shell payload (e.g., a PHP web shell) and assign it a whitespace-padded filename such as shell. php (space between dot and extension) or shell.php (trailing space after extension).
3. Construct bypass request: Build a multipart/form-data HTTP POST request with the Content-Disposition header specifying the whitespace-padded filename, e.g.:

Content-Disposition: form-data; name="file"; filename="shell. php"
Content-Type: text/plain

<?php system($_GET['cmd']); ?>

4. Submit upload: Send the crafted request to the target application's file upload endpoint. The CRS rules (933110, 944140) fail to match the extension due to the whitespace, and the upload is not blocked.
5. Trigger execution: On a Windows backend, the server normalizes shell. php to shell.php upon storage. Navigate to the uploaded file's URL to execute the web shell and achieve remote code execution (GitHub Advisory, PR #4546).

• Network: Multipart file upload HTTP POST requests where the Content-Disposition filename field contains whitespace adjacent to the file extension (e.g., filename="shell. php" or filename="shell.php "); requests to uploaded file paths with executable extensions shortly after an upload event.
• Logs: WAF/ModSecurity access logs showing file upload requests that were not blocked by rules 933110, 933111, 944140, or 932180 for filenames containing PHP/JSP extensions with embedded whitespace; web server logs showing GET/POST requests to newly created .php or .jsp files in upload directories.
• File System: Unexpected .php, .phar, .jsp, or .jspx files in upload or media directories; files with names that differ from what was submitted (whitespace stripped by OS), indicating backend normalization occurred.
• Process: Unusual child processes spawned by the web server process (e.g., cmd.exe, powershell.exe on Windows, or sh/bash on Linux) following access to files in upload directories.

Upgrade OWASP CRS to version 3.3.9 or 4.25.0 (or later), which add the t:removeWhitespace transformation to rules 932180, 933110, 933111, and 944140, ensuring filenames are normalized before extension regex evaluation (GitHub Advisory, Patch Commit). If immediate upgrade is not possible, apply the following workarounds:

• Enforce filename validation at the application layer: reject uploads with whitespace in or around file extensions.
• Store uploaded files outside the webroot and rename them to random, safe filenames.
• Configure the web server to never execute files in upload directories regardless of extension.
• Add a custom ModSecurity rule that applies t:removeWhitespace to FILES and FILES_NAMES variables before processing, as a local override to the affected rules.

The vulnerability was discussed on the oss-security mailing list and noted in the security community on Bluesky (infosec.skyfleet.blue) shortly after disclosure (oss-sec). The CRS maintainer (fzipi/Felipe Zipitria) promptly developed and merged fixes within days of the report, and the release of CRS 4.25.0 (LTS) and 3.3.9 was covered by Linux-focused news outlets (LinuxCompatible, MajorGeeks). The Metasploit Framework community has also engaged with the vulnerability through a related pull request, indicating researcher interest in weaponization.