XWiki patches scripting API sandbox bypass enabling instance takeover
TL;DR — XWiki’s scripting API can let users with Script right bypass Velocity sandboxing and execute arbitrary scripts (e.g., Python), resulting in full instance compromise.
What happened
XWiki Platform is a generic wiki platform that also provides runtime services for applications built on top of it. CVE-2026-33229 describes an improperly protected scripting API that allows a user who already has Script right to bypass the sandboxing of the Velocity scripting API and execute arbitrary scripts (the CVE explicitly calls out Python as an example), leading to full control of the XWiki instance.
| Item | Source value |
|---|---|
| Affected product | xwiki-platform (XWiki Platform) |
| Impact (per CVE) | Bypass Velocity sandboxing; execute arbitrary scripts; full instance compromise |
| Severity | CVSS v4.0 8.6 (High) |
| Fix availability | Fixed in 17.4.8 and 17.10.1 |
While the attack requires Script right (a highly privileged capability), this still matters operationally because “power user” rights frequently sprawl in large wiki deployments; when they do, sandbox bypasses turn a content-level permission mistake into full application takeover.
Who is impacted
- XWiki deployments in the affected version ranges listed in the CVE record:
| Version range (per CVE record) | Status |
|---|---|
>= 17.0.0-rc-1, < 17.4.8 | affected |
>= 17.5.0-rc-1, < 17.10.1 | affected |
- Instances where non-admin users (or semi-trusted groups) have been granted
Scriptright, intentionally or via permission drift. - Organizations embedding application logic into XWiki pages/macros where a sandbox boundary is expected to contain user-authored scripts.
What to do now
- Follow vendor remediation guidance and apply a fixed version called out in the advisory/CVE record.
"This vulnerability is fixed in 17.4.8 and 17.10.1."
- Audit who has
Scriptright (directly and via group inheritance), and treat it as equivalent to “can run code on the server.”"Script right already constitutes a high level of access that we don't recommend giving to untrusted users."
- Inventory all XWiki instances (including test/staging) and prioritize upgrades for:
- internet-reachable wikis
- wikis used as internal app platforms (macros, embedded services)
- If compromise is suspected, assume secrets reachable by the XWiki runtime could be exposed; rotate credentials accessible to the service and review recent page/script changes from users with
Scriptright.
Content is AI-assisted and reviewed by our team, but issues may be missed and best practices evolve rapidly, send corrections to [email protected]. Always consult official documentation and validate key implementation decisions before making design or security choices.
