CVE-2026-33137 · XWiki Platform Unauthenticated XAR Import via REST /wikis/{wikiName}

01 · The Real Story

Like leaving the server room door unlocked with a sign reading 'Upload Your Malware Here' taped to the rack

CVE-2026-33137 is a missing-authorization flaw (CWE-862) in the XWiki Platform REST server component xwiki-platform-rest-server. The POST /xwiki/rest/wikis/{wikiName} endpoint accepts a XAR (XWiki Archive) file and imports it into the wiki — creating or overwriting arbitrary pages — without performing any authentication or authorization check whatsoever. Because XAR files carry author metadata, an attacker can set the page author to xwiki:XWiki.Admin, causing embedded {{groovy}} or {{velocity}} macros to execute with full programming rights when the page is rendered. The result is unauthenticated remote code execution as the Java/Tomcat service account. Affected versions span 15.10.6 through the fix releases: 16.10.17, 17.4.9, 17.10.3, 18.0.1, and 18.1.0-rc-1.

No vendor CVSS 3.1 score was published in NVD at the time of this assessment (NVD status: Deferred). The XWiki project's own GitHub Security Advisory (GHSA-qrvh-r3f2-9h4r) assigns a CVSS 4.0 score of 9.3 CRITICAL, and the GitLab Advisory Database independently calculates a CVSS 3.1 of 9.8. Both scores are accurate representations of the technical severity: the endpoint is network-accessible, requires zero privileges, zero user interaction, and delivers full CIA impact. The only real-world downward pressure is XWiki's niche install base (~0.17% document management market share per Enlyft, ~129 tracked enterprises). For any organization actually running XWiki, this is as bad as it gets — a fully weaponized public PoC with an --rce flag makes exploitation trivial.

The vulnerability was disclosed on 2026-05-20 and reported by Sho Odagiri of GMO Cybersecurity by Ierae, Inc. The fix commit (4b7b95b7) adds an authorization check via ContextualAuthorizationManager.checkAccess(Right.ADMIN, ...) before the import executes.

"Unauthenticated RCE in XWiki REST API — one POST imports a Groovy payload, no credentials needed"

02 · The Attack Path

4 steps from start to impact.

STEP 01

Discover target XWiki instance

The attacker identifies internet-facing or internal-network XWiki instances via Shodan dorks (http.title:"XWiki"), FOFA queries, or internal network scanning. The REST API at /xwiki/rest openly discloses the exact product version without authentication, confirming vulnerability in a single GET request. Prior mass-exploitation campaigns against XWiki (RondoDox botnet, November 2025) demonstrate that threat actors actively maintain target lists of XWiki instances.

Conditions required:

Network access to target XWiki on port 8080 or 443

Where this breaks in practice:

XWiki has ~0.17% document management market share; smaller target pool than Confluence or MediaWiki
Many deployments are internal-only, reachable only from the corporate LAN or VPN

Detection/coverage: Shodan/Censys probes visible to GreyNoise community sensors; version-enumeration GETs appear in web access logs as requests to /xwiki/rest

STEP 02

Build weaponized XAR payload

The attacker creates a minimal XAR archive containing a package.xml manifest and a page XML document with embedded {{groovy}} macros for arbitrary OS command execution. The page's <creator> and <contentAuthor> fields are set to xwiki:XWiki.Admin to inherit programming rights and bypass XWiki's content-based security model. The public PoC at portbuster1337/CVE-2026-33137 on GitHub automates the entire process with a --rce "id" flag that accepts arbitrary shell commands as arguments.

Conditions required:

Knowledge of XAR format (fully automated by public PoC)

Where this breaks in practice:

None — the PoC handles all payload construction

STEP 03

Upload XAR via unauthenticated POST

The attacker sends POST /xwiki/rest/wikis/xwiki with the malicious XAR file as the request body. The xwiki-platform-rest-server component processes the import without checking authentication, authorization, CSRF tokens, or rate limits. The document is created or overwritten in the target wiki immediately. A single curl command or the PoC's --rce mode is sufficient. No credentials, tokens, sessions, or cookies are required.

Conditions required:

Network access to XWiki REST API port

Where this breaks in practice:

None — the endpoint is completely unprotected in all vulnerable versions

Detection/coverage: WAF rules inspecting POST bodies for XAR/XML content types at the /xwiki/rest/wikis/ path; web server access logs show unauthenticated POST; XWiki's audit log records document creation by guest user

STEP 04

Achieve remote code execution

When the imported page is rendered — either by the attacker requesting its URL directly, by any legitimate user navigating to it, or by XWiki's internal indexing and notification subsystems — the embedded {{groovy}} macro executes with the rights of the spoofed Admin author. This provides arbitrary OS command execution as the Java/Tomcat process user (typically tomcat or xwiki). The attacker can then read hibernate.cfg.xml for database credentials, install web shells, dump wiki content, or pivot to other internal systems via the compromised host.

Conditions required:

Page is rendered (attacker can trigger this by requesting the page URL)
Author metadata set to a user with programming rights (default Admin has them)

Where this breaks in practice:

Minimal — attacker triggers rendering by requesting the page URL in the same HTTP session

Detection/coverage: Process monitoring detects unexpected child processes of Java/Tomcat (e.g., /bin/sh -c id); EDR behavioral rules for LOLBins spawned from Java; XWiki activity stream shows new page creation by anonymous/guest user

03 · Compensating Control

CRITICAL 9.3→LOW 2.0

SEVERITY REDUCED

Block POST to /xwiki/rest/wikis/ at reverse proxy or WAF — Add an nginx, Apache, HAProxy, or cloud WAF rule returning 403 for any POST request whose URI matches /xwiki/rest/wikis/. This is the vendor-recommended workaround from GHSA-qrvh-r3f2-9h4r. It directly breaks step 3 of the attack chain by preventing the unauthenticated XAR upload from reaching the application. Deploy within 3 days per the noisgate mitigation SLA for CRITICAL findings. Verify the rule does not block legitimate wiki API operations by testing GET requests to the same path.

CRITICAL 9.3→MEDIUM 5.5

SEVERITY REDUCED

Restrict XWiki network access to VPN or zero-trust gateway — Move XWiki behind a VPN, ZTNA gateway (Zscaler, Cloudflare Access, Tailscale), or firewall ACL so that only authenticated internal users on managed devices can reach the application. This breaks step 1 by eliminating internet-facing exposure and requiring the attacker to already have internal network access. Deploy within 3 days. Note: this does not protect against insider threats or post-compromise lateral movement from other compromised internal hosts.

CRITICAL 9.3→HIGH 7.0

SEVERITY REDUCED

Disable Groovy and Velocity scripting macros — Set rendering.macro.groovy.enabled=false and restrict Velocity macro execution in xwiki.cfg or via the XWiki admin panel. This breaks step 4 by preventing the RCE payload from executing even if the XAR is imported. Deploy within 3 days. Caveat: the attacker can still create and overwrite arbitrary wiki pages (content manipulation, defacement, social engineering via modified documentation), so this only eliminates the RCE path, not the full impact.

CRITICAL 9.3→IGNORE 0.0

SEVERITY REDUCED

Upgrade to patched version — Apply the vendor fix by upgrading to 16.10.17, 17.4.9, 17.10.3, or 18.0.1+. This is the definitive remediation — the fix adds ContextualAuthorizationManager.checkAccess(Right.ADMIN) before XAR import. Target completion within 90 days per the noisgate remediation SLA for CRITICAL findings, but push for faster given the weaponized PoC and XWiki's exploitation history.

What doesn't work

XWiki's built-in access rights and guest restrictions — The vulnerability bypasses all application-layer authorization checks in the REST server; internal wiki permissions, page-level restrictions, and guest access policies are never consulted before the XAR import executes.
Rate limiting or request throttling — A single HTTP POST is sufficient to exploit the vulnerability. Rate limiting adds no meaningful friction to an attack that succeeds on the first request.
CSRF token enforcement — The endpoint performs no authentication at all; CSRF protections are architecturally irrelevant to an unauthenticated endpoint. Even if XWiki's CSRF filter were applied, the attacker is not relying on a victim's browser session.
Content Security Policy (CSP) headers — The attack does not rely on client-side script injection or browser rendering; it is a server-side XAR import that executes Groovy on the server. CSP has no bearing on server-side code execution.

04 · Intelligence Metadata

The supporting signals.

In-the-wild exploitation	No confirmed exploitation of CVE-2026-33137 specifically as of 2026-09-26. However, the closely related CVE-2025-24893 (also XWiki unauth RCE) was mass-exploited by the RondoDox botnet and multiple coin-mining campaigns within days of PoC publication (November 2025), and was added to CISA KEV on 2025-10-30. Threat actor familiarity with the XWiki attack surface is well-established.
Proof-of-concept	Public weaponized PoC at portbuster1337/CVE-2026-33137 on GitHub. Python script with `--rce` flag automates XAR crafting, author spoofing, and Groovy payload injection. Usage: `python poc.py -t http://target:8080 --rce "id"`. Also supports `--probe` for safe version detection.
EPSS	0.00879 (0.879% probability of exploitation in the next 30 days). Elevated above the median CVE but not in the top decile. Given the weaponized PoC and XWiki's exploitation history, the EPSS likely understates near-term risk.
CISA KEV	Not listed as of 2026-09-26. No federal remediation deadline. Note: the predecessor XWiki RCE (CVE-2025-24893) was KEV-listed.
CVSS vector	CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N → 9.3 (per GHSA-qrvh-r3f2-9h4r). CVSS 3.1 equivalent: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H → 9.8 (per GitLab Advisory). Network vector, low complexity, no privileges, no user interaction, full CIA impact.
Affected versions	`xwiki-platform-rest-server` ≥15.10.6 to <16.10.17, ≥17.0.0-rc-1 to <17.4.9, ≥17.5.0 to <17.10.3, ≥18.0.0-rc-1 to <18.0.1
Fixed versions	16.10.17, 17.4.9, 17.10.3, 18.0.1, 18.1.0-rc-1. Fix commit: `4b7b95b79256374d487e9ece1dc48f527966990f`. The patch adds `ContextualAuthorizationManager.checkAccess(Right.ADMIN)` before the XAR import executes.
Exposure surface	XWiki holds ~0.17% market share in document management per Enlyft, with ~129 tracked enterprise deployments. Hundreds to low-thousands of instances are visible on Shodan and FOFA. Prior campaigns (RondoDox) demonstrate that attackers actively scan for and exploit exposed XWiki instances at scale.
Disclosure timeline	Disclosed 2026-05-20, NVD published same day, NVD modified 2026-07-23 (status: Deferred). GHSA-qrvh-r3f2-9h4r published alongside the fix releases.
Reporter	Sho Odagiri, GMO Cybersecurity by Ierae, Inc.

Sources.

05 · The Call

Final Verdict

= UNCHANGED to CRITICAL (9.3/10)

Why this verdict

Zero authentication friction: The endpoint requires no credentials, no tokens, no session, and no CSRF protection. A single unauthenticated HTTP POST delivers the payload. This is the lowest possible attacker position — unauthenticated remote — with no narrowing of the reachable population among XWiki instances.
Weaponized public PoC with RCE flag: The portbuster1337/CVE-2026-33137 GitHub repository provides a turnkey Python exploit that automates XAR payload crafting, author spoofing to xwiki:XWiki.Admin, and Groovy macro injection. The --rce flag accepts arbitrary OS commands. This collapses exploitation complexity to a single command.
Established threat-actor interest in XWiki: CVE-2025-24893 (a prior XWiki unauth RCE) was mass-exploited by the RondoDox botnet and multiple coin-mining campaigns within days of public PoC availability, and was added to CISA KEV in October 2025. The same attacker tooling and scanning infrastructure will trivially adapt to this new endpoint.
Role multiplier: XWiki is not a canonical high-value component (not an IdP, domain controller, hypervisor, PKI, or network edge appliance). Its typical deployment role is an internal documentation and knowledge management wiki. Blast radius is host-level (RCE as the Java/Tomcat service user) with potential for tenant-level impact (exfiltration of wiki content that may include credentials, architecture diagrams, runbooks, and internal procedures) and lateral movement from the compromised host. Approximately 0.17% document management market share with ~129 tracked enterprises means the high-value-role floor rule does not force a minimum. However, the frictionless unauthenticated RCE chain independently warrants CRITICAL for any reachable instance.
Internet-facing exposure exists: While many XWiki deployments are internal-only, Shodan and FOFA scans show hundreds to low-thousands of internet-facing instances. Prior mass-exploitation campaigns confirm that attackers actively discover and target these exposed systems. Even internal-only instances are trivially exploitable by any attacker with LAN/VPN access.

Why not higher?

A 9.3 is near the scoring ceiling. The only factor preventing a 10.0 is that XWiki occupies a niche install base (~0.17% market share, ~129 tracked enterprises per Enlyft), bounding fleet-scale impact compared to ubiquitous infrastructure like Apache HTTP Server, Exchange, or Active Directory. The scope metric is Unchanged (no cross-component escalation beyond the XWiki host without additional post-exploitation steps), which mechanically caps the CVSS at 9.8 under v3.1 and 9.3 under v4.0.

Why not lower?

The chain requires zero authentication, zero user interaction, and has a fully weaponized public PoC with an --rce flag that delivers arbitrary OS command execution in a single HTTP request. Prior XWiki CVEs saw mass exploitation and CISA KEV listing within weeks. Any downgrade below CRITICAL would require the endpoint to be unreachable or the PoC to be non-functional — neither condition holds. The vulnerability is pre-authentication, meaning no compensating identity control (MFA, SSO, RBAC) applies unless network-layer blocking is in place.

06 · Verification

Crowdsourced verification payload.

Run from any workstation or auditor jumpbox with curl and network access to the target XWiki instance. No elevated privileges required — the script queries the public REST API for version data. Invoke as: bash check_cve_2026_33137.sh https://wiki.example.com

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/usr/bin/env bash
# CVE-2026-33137 Checker - XWiki Unauthenticated XAR Import
# Exit: 0=PATCHED  1=VULNERABLE  2=UNKNOWN
set -euo pipefail

TARGET="${1:-}"
if [ -z "$TARGET" ]; then
  echo "Usage: $0 <xwiki-base-url>"
  echo "Example: $0 https://wiki.example.com"
  exit 2
fi
TARGET="${TARGET%/}"
REST="${TARGET}/xwiki/rest"

echo "[*] Querying ${REST} ..."
RESP=$(curl -sSk --max-time 15 "${REST}" -H "Accept: application/xml" 2>/dev/null) || {
  echo "[!] Cannot reach ${REST}"; echo "UNKNOWN"; exit 2
}

# Extract version from <version>X.Y.Z</version>
VER=$(echo "$RESP" | sed -n 's/.*<version>\([^<]*\)<\/version>.*/\1/p' | head -1)
if [ -z "$VER" ]; then
  echo "[!] Cannot parse XWiki version."; echo "UNKNOWN"; exit 2
fi
echo "[*] Detected version: ${VER}"

# Extract numeric M.m.p
MAJ=$(echo "$VER" | cut -d. -f1)
MIN=$(echo "$VER" | cut -d. -f2)
PAT=$(echo "$VER" | cut -d. -f3 | sed 's/[^0-9].*//')
MAJ=${MAJ:-0}; MIN=${MIN:-0}; PAT=${PAT:-0}

# Compose single integer: MAJ*10000 + MIN*100 + PAT
V=$((MAJ * 10000 + MIN * 100 + PAT))

VULN=0
# Range 1: 15.10.06 <= v < 16.10.17
if [ "$V" -ge 151006 ] && [ "$V" -lt 161017 ]; then VULN=1; fi
# Range 2: 17.00.00 <= v < 17.04.09
if [ "$V" -ge 170000 ] && [ "$V" -lt 170409 ]; then VULN=1; fi
# Range 3: 17.05.00 <= v < 17.10.03
if [ "$V" -ge 170500 ] && [ "$V" -lt 171003 ]; then VULN=1; fi
# Range 4: 18.00.00 <= v < 18.00.01
if [ "$V" -ge 180000 ] && [ "$V" -lt 180001 ]; then VULN=1; fi

if [ "$VULN" -eq 1 ]; then
  echo ""
  echo "VULNERABLE"
  echo "[!] XWiki ${VER} is in an affected range for CVE-2026-33137."
  echo "[!] Upgrade to 16.10.17 / 17.4.9 / 17.10.3 / 18.0.1+."
  exit 1
else
  echo ""
  echo "PATCHED"
  echo "[+] XWiki ${VER} is outside the affected ranges."
  exit 0
fi