XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it

CVE-2026-33137 is a missing-authorization flaw in XWiki's REST handler for POST /wikis/{wikiName}. On affected branches, that endpoint imports a XAR archive without checking authentication or authorization first, so an unauthenticated remote attacker can create or overwrite documents inside the target wiki. XWiki's issue tracker ties the bug to the REST component and lists affected versions beginning at 15.10.16, 16.4.6, and 16.10.2, with fixes in 16.10.17, 17.4.9, 17.10.3, 18.0.1, and 18.1.0-rc-1.

In practice this is worse than 'just content tampering'. XWiki's own bug notes say a guest can import XWiki.XWikiPreferences and grant guest the programming right, which collapses the gap between document write access and full application-level takeover. The only real brakes are product population and exposure: XWiki is less common than Exchange or Confluence, and many deployments live on internal networks, but if you expose XWiki to the internet this is a pre-auth remote compromise path, not a nuisance bug.

Why this verdict

• Pre-auth remote path: no credentials, no user interaction, and no special attacker position beyond HTTP reachability.
• Privilege-escalation built into the bug's own notes: XWiki says a guest can import XWiki.XWikiPreferences and grant guest programming right, which is far more dangerous than ordinary document edits.
• Low operational friction for attackers: weaponization is just an HTTP POST with a XAR payload; no race, no heap grooming, no auth bypass chain.
• Exposure is the only meaningful downtick: many XWiki deployments are internal or niche, so enterprise-wide prevalence is lower than appliance/VPN bugs, but that does not save the instances you actually expose.
• Threat intel is quiet, not comforting: low EPSS and no KEV keep this from being a panic-in-the-wild event, but they do not materially reduce impact on a reachable target.

Why not higher?

This is not an every-enterprise, every-perimeter product, and I found no primary-source evidence of exploitation or a polished public exploit kit. Also, the strongest downstream impact is application-context takeover through XWiki rights and scripting, not a one-packet, directly demonstrated OS-level RCE in the advisory.

Why not lower?

Downgrading this to HIGH would underweight the absence of authentication and the fact that the vulnerable action is a write primitive into a privileged import workflow. Once an attacker can import arbitrary documents and potentially change XWiki.XWikiPreferences, the practical blast radius on an exposed instance is too large for a mid-tier bucket.

1. Block POST to /wikis/* at the edge — Put a reverse-proxy or WAF rule in front of XWiki to deny unauthenticated POST requests to /wikis/{wikiName} and similar REST import paths. This is the vendor's stated workaround pattern and should be deployed within 3 days because the noisgate CRITICAL bucket demands fast risk reduction.
2. Restrict XWiki to trusted networks — If the instance does not need public access, move it behind VPN, SSO gateway, or internal-only ACLs so the attacker can no longer hit the vulnerable route from the internet. Use this as a compensating control within 3 days where patch rollout is slower.
3. Alert on anonymous writes to wiki preferences and core spaces — Create detections for edits to XWiki.XWikiPreferences, global templates, and newly created pages authored by guest/anonymous context. This will not prevent exploitation, but it shortens dwell time and should be in place within 3 days for exposed deployments.
4. Diff page history for privilege-bearing documents — Continuously audit high-value XWiki pages and objects for unauthorized changes, especially rights, preferences, and script-bearing documents. For internet-facing instances, stand this up within 3 days to catch silent abuse while remediation is scheduled.

Run this on the target XWiki host or inside the container/VM that serves the app, not from an auditor workstation. Invoke it as sudo bash ./check-cve-2026-33137.sh /path/to/xwiki/webapp or just sudo bash ./check-cve-2026-33137.sh; it needs read access to the deployed XWiki webapp/WAR directories so it can inspect xwiki-platform-rest-server JAR versions.

#!/usr/bin/env bash
# check-cve-2026-33137.sh
# Detects likely exposure to CVE-2026-33137 by locating the deployed
# xwiki-platform-rest-server artifact and comparing its version to known fixed branches.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -euo pipefail

TARGET_PATH="${1:-}"
FOUND_JAR=""
FOUND_VERSION=""

find_candidate_jar() {
  local base="$1"
  find "$base" -type f \( -name 'xwiki-platform-rest-server-*.jar' -o -path '*/WEB-INF/lib/xwiki-platform-rest-server-*.jar' \) 2>/dev/null | head -n 1
}

extract_version_from_name() {
  local jar="$1"
  local name
  name="$(basename "$jar")"
  name="${name#xwiki-platform-rest-server-}"
  name="${name%.jar}"
  printf '%s' "$name"
}

normalize_rc() {
  local v="$1"
  # Turn rc markers into a sortable suffix lower than final release.
  v="${v//-rc-/.~rc.}"
  v="${v//RC/.~rc.}"
  printf '%s' "$v"
}

ver_lt() {
  dpkg --compare-versions "$(normalize_rc "$1")" lt "$(normalize_rc "$2")"
}
ver_le() {
  dpkg --compare-versions "$(normalize_rc "$1")" le "$(normalize_rc "$2")"
}
ver_ge() {
  dpkg --compare-versions "$(normalize_rc "$1")" ge "$(normalize_rc "$2")"
}

classify_version() {
  local v="$1"

  # Known fixed versions from advisory: 16.10.17, 17.4.9, 17.10.3, 18.0.1, 18.1.0-rc-1
  # Because the lower affected bounds across old branches are not perfectly explicit in public metadata,
  # this script is conservative: unsupported/ambiguous old lines return UNKNOWN.

  # Patched branches
  if ver_ge "$v" "18.1.0-rc-1"; then
    echo "PATCHED"
    return
  fi
  if ver_ge "$v" "18.0.1" && ver_lt "$v" "18.1.0-rc-1"; then
    echo "PATCHED"
    return
  fi
  if ver_ge "$v" "17.10.3" && ver_lt "$v" "18.0.0"; then
    echo "PATCHED"
    return
  fi
  if ver_ge "$v" "17.4.9" && ver_lt "$v" "17.5.0"; then
    echo "PATCHED"
    return
  fi
  if ver_ge "$v" "16.10.17" && ver_lt "$v" "17.0.0"; then
    echo "PATCHED"
    return
  fi

  # Known vulnerable supported branches
  if ver_ge "$v" "18.0.0" && ver_lt "$v" "18.0.1"; then
    echo "VULNERABLE"
    return
  fi
  if ver_ge "$v" "17.5.0" && ver_lt "$v" "17.10.3"; then
    echo "VULNERABLE"
    return
  fi
  if ver_ge "$v" "17.0.0" && ver_lt "$v" "17.4.9"; then
    echo "VULNERABLE"
    return
  fi
  if ver_ge "$v" "16.10.2" && ver_lt "$v" "16.10.17"; then
    echo "VULNERABLE"
    return
  fi

  # Ambiguous / unsupported / older branches where public metadata is not precise enough
  echo "UNKNOWN"
}

if [[ -n "$TARGET_PATH" ]]; then
  if [[ ! -e "$TARGET_PATH" ]]; then
    echo "UNKNOWN - supplied path does not exist: $TARGET_PATH"
    exit 2
  fi
  FOUND_JAR="$(find_candidate_jar "$TARGET_PATH" || true)"
else
  for p in \
    /usr/lib/xwiki \
    /var/lib/xwiki \
    /opt/xwiki \
    /var/lib/tomcat* \
    /usr/share/tomcat* \
    /var/lib/jetty* \
    /srv \
    /opt ; do
    [[ -e "$p" ]] || continue
    FOUND_JAR="$(find_candidate_jar "$p" || true)"
    [[ -n "$FOUND_JAR" ]] && break
  done
fi

if [[ -z "$FOUND_JAR" ]]; then
  echo "UNKNOWN - could not locate xwiki-platform-rest-server JAR"
  exit 2
fi

FOUND_VERSION="$(extract_version_from_name "$FOUND_JAR")"
STATUS="$(classify_version "$FOUND_VERSION")"

echo "$STATUS - detected xwiki-platform-rest-server version: $FOUND_VERSION ($FOUND_JAR)"
case "$STATUS" in
  PATCHED) exit 0 ;;
  VULNERABLE) exit 1 ;;
  *) exit 2 ;;
esac

Sources

1. NVD record
2. GitHub Security Advisory GHSA-qrvh-r3f2-9h4r
3. XWiki patch commit 4b7b95b
4. XWiki JIRA issue XWIKI-23953
5. CISA Known Exploited Vulnerabilities Catalog
6. FIRST EPSS data documentation
7. Censys XWiki advisory noting exposed XWiki population
8. XWiki blog archive with fixed-version release dates