The OWASP core rule set

CVE-2026-33691 is a whitespace-normalization gap in OWASP CRS file-upload detection. In CRS versions earlier than 3.3.9 and 4.25.0, rules 933110, 933111, and in v4 also 944140, can miss dangerous upload names like photo. php or shell.jsp because the regex sees the space and fails to match the blocked extension. The vulnerable population is any app behind CRS that accepts file uploads and relies on these rules to catch executable extensions.

The vendor's MEDIUM 6.8 is reasonable as a lab score, but for enterprise patch triage it still overstates broad operational risk. This is a *defense bypass* in a rule set, not a direct server-side code execution bug: the attacker also needs a reachable upload feature, weak application-side validation, and a backend or hosting path that turns the whitespace-padded name into an executable file, which the advisory notes is especially practical on Windows and much less so on typical Linux deployments.

Why this verdict

• Defense-bypass, not direct code execution: CRS fails to catch a bad filename pattern, but the attacker still needs the application and hosting stack to mishandle the uploaded file after the WAF lets it through.
• Environment dependency cuts the population hard: the vendor advisory explicitly says practical exploitation is common on Windows-style whitespace normalization and much harder on Linux unless the application trims filenames itself.
• Reachability is narrower than the CVSS baseline implies: only Internet-facing or attacker-reachable upload endpoints behind affected CRS versions are in scope, and many enterprise uploads are authenticated, renamed, stored outside webroot, or pushed to object storage.
• Threat intel is cold: no KEV listing, no public campaign evidence, and the supplied EPSS 0.00031 is near the floor.

Why not higher?

This is not a one-request server takeover. The attacker must chain the CRS miss with a weak upload implementation and a backend that converts the padded filename into an executable or otherwise dangerous artifact, which is a lot of real-world friction.

Why not lower?

It is still remotely testable and requires no local foothold. In estates with legacy IIS/Windows upload handlers or sloppy filename normalization, this bypass can be the last step that turns an otherwise blocked web-shell upload into a real compromise.

1. Rename uploads server-side — Force every upload to a random safe name and store the original filename only as metadata. This breaks the exploit chain regardless of CRS behavior; for a LOW verdict there is no fixed SLA date, so fold this into normal app-hardening work rather than emergency change control.
2. Store uploads outside webroot — Make uploaded files non-executable by design and serve them indirectly through the application or object storage. That removes the main impact path entirely; for LOW, treat this as backlog hygiene in the next routine platform hardening cycle.
3. Add local t:removeWhitespace to affected rules — If you cannot update CRS immediately, patch the local copies of rules 933110, 933111, and 944140 as the vendor advisory recommends. For LOW, there is no mitigation SLA, so do it in the next ordinary WAF policy maintenance window.
4. Reject whitespace-padded executable names in the app — Application-side filename validation should reject suspicious patterns like spaces around dangerous extensions and should not trust multipart filename= values. For LOW, implement during normal developer backlog work, prioritizing any public upload workflow on Windows-backed apps.

Run this on the WAF or reverse-proxy host where CRS rule files are actually deployed, not from a scanner box. Invoke it as sudo bash check-cve-2026-33691.sh; root is recommended so it can read packaged rule locations under /etc, /usr/share, or /opt.

#!/usr/bin/env bash
# check-cve-2026-33691.sh
# Detects whether deployed OWASP CRS rules for CVE-2026-33691 include t:removeWhitespace.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

SEARCH_DIRS=(
  "/etc/modsecurity"
  "/etc/crs4"
  "/usr/share/modsecurity-crs"
  "/usr/share/owasp-modsecurity-crs"
  "/opt/owasp-crs"
  "/opt/coreruleset"
)

found_dirs=()
for d in "${SEARCH_DIRS[@]}"; do
  if [ -d "$d" ]; then
    found_dirs+=("$d")
  fi
done

if [ ${#found_dirs[@]} -eq 0 ]; then
  echo "UNKNOWN - no common CRS directories found"
  exit 2
fi

find_rule_context() {
  local rule_id="$1"
  local hit file line start end
  while IFS= read -r hit; do
    file="${hit%%:*}"
    line_rest="${hit#*:}"
    line="${line_rest%%:*}"
    if [[ "$line" =~ ^[0-9]+$ ]]; then
      start=$(( line > 12 ? line - 12 : 1 ))
      end=$(( line + 25 ))
      sed -n "${start},${end}p" "$file"
      return 0
    fi
  done < <(grep -R -n -E "id:?${rule_id}([, ]|$)" "${found_dirs[@]}" 2>/dev/null)
  return 1
}

rule_status() {
  local rule_id="$1"
  local ctx
  if ! ctx="$(find_rule_context "$rule_id")"; then
    echo "NOTFOUND"
    return 0
  fi
  if grep -q "t:removeWhitespace" <<< "$ctx"; then
    echo "PATCHED"
  else
    echo "VULNERABLE"
  fi
}

r933110="$(rule_status 933110)"
r933111="$(rule_status 933111)"
r944140="$(rule_status 944140)"

# Need the PHP rules to make a determination.
if [ "$r933110" = "NOTFOUND" ] || [ "$r933111" = "NOTFOUND" ]; then
  echo "UNKNOWN - affected rule IDs 933110/933111 not found in deployed CRS content"
  exit 2
fi

# v4 installs normally include 944140; v3 does not.
if [ "$r944140" = "NOTFOUND" ]; then
  if [ "$r933110" = "PATCHED" ] && [ "$r933111" = "PATCHED" ]; then
    echo "PATCHED - v3-style rule set appears fixed (933110/933111 include t:removeWhitespace)"
    exit 0
  else
    echo "VULNERABLE - v3-style rule set missing t:removeWhitespace in 933110 and/or 933111"
    exit 1
  fi
else
  if [ "$r933110" = "PATCHED" ] && [ "$r933111" = "PATCHED" ] && [ "$r944140" = "PATCHED" ]; then
    echo "PATCHED - v4-style rule set appears fixed (933110/933111/944140 include t:removeWhitespace)"
    exit 0
  else
    echo "VULNERABLE - v4-style rule set missing t:removeWhitespace in one or more affected rules (933110/933111/944140)"
    exit 1
  fi
fi

Sources

1. GitHub Security Advisory GHSA-rw5f-9w43-gv2w
2. NVD CVE-2026-33691
3. OWASP CRS release v4.25.0
4. OWASP CRS release v3.3.9
5. PR #4546 fix(933110)
6. PR #4548 fix(944140)
7. Debian security tracker for CVE-2026-33691
8. CISA Known Exploited Vulnerabilities Catalog