CVE-2026-33229: 
Java vulnerability analysis and mitigation

CVE-2026-33229 is a remote code execution vulnerability in XWiki caused by an improperly protected Velocity scripting API that allows any user with script right to bypass sandbox restrictions and execute arbitrary code (e.g., Python scripts), gaining full access to the XWiki instance. It affects XWiki versions 17.0.0-rc-1 through 17.4.7 and 17.5.0-rc-1 through 17.10.0, impacting the Maven packages org.xwiki.platform:xwiki-platform-oldcore and org.xwiki.platform:xwiki-platform-legacy-oldcore. The vulnerability was discovered by Youssef Azefzaf and disclosed on April 8, 2026. It carries a CVSS v4 score of 8.6 (High) and a CVSS v3.1 score of 9.8 (Critical) (Github Advisory, XWiki Advisory).

The root cause is CWE-862 (Missing Authorization): the ScriptXWikiServletRequest#getRequest() method in XWiki's Velocity scripting layer did not enforce an authorization check, allowing any user with script right to access the underlying raw servlet request object without restriction. By calling $request.request in a Velocity template, an attacker can retrieve the unwrapped HttpServletRequest, then use Tomcat's InstanceManager to instantiate arbitrary Java classes — including org.apache.batik.script.jpython.JPythonInterpreter — and invoke them to execute arbitrary Python (or other scripting language) code on the server. The fix (commit 9fe84da) adds a programming right check to getRequest(), returning null for users without that elevated privilege (XWiki Advisory, Patch Commit).

Successful exploitation grants an attacker full control over the XWiki instance, compromising confidentiality (access to all wiki data and credentials), integrity (ability to modify any content or configuration), and availability (potential to disrupt or destroy the service). Because the attacker executes code in the context of the XWiki server process, they can also pivot to underlying infrastructure, access databases, read environment variables and secrets, and potentially move laterally within the hosting environment (Github Advisory).

Public proof-of-concept exploit code is available on GitHub, published by the original reporter Youssef Azefzaf shortly after disclosure (PoC GitHub). The exploit uses a concrete Velocity payload injected into a wiki page to achieve RCE. As of the time of reporting, there is no confirmed evidence of in-the-wild exploitation, and the vulnerability is not listed in the CISA KEV catalog. The EPSS score is approximately 0.033–0.089%, indicating a currently low but non-negligible probability of exploitation in the near term. Exploitation requires an authenticated account with script right, which XWiki itself notes is a high-privilege role not recommended for untrusted users (Github Advisory, XWiki Advisory).

1. Obtain script right: Acquire an XWiki account that has been granted script right on the target instance (versions 17.0.0-rc-1 to 17.4.7 or 17.5.0-rc-1 to 17.10.0).
2. Create or edit a wiki page: Navigate to any wiki page where Velocity scripting is permitted and open the page editor.
3. Inject the sandbox-bypass payload: Insert the following Velocity template payload into the page content or title:

$request.request.getServletContext().getAttribute("org.apache.tomcat.InstanceManager").newInstance("org.apache.batik.script.jpython.JPythonInterpreter").evaluate("import os; os.system('touch /tmp/RCE')")

4. Trigger execution: Save and render the page. XWiki's Velocity engine evaluates the template, calling $request.request to obtain the unwrapped servlet request (bypassing the sandbox), then uses Tomcat's InstanceManager to instantiate a JPython interpreter.
5. Achieve RCE: The Python code executes on the server in the context of the XWiki process. Replace the os.system payload with a reverse shell, file exfiltration command, or other malicious action as desired (PoC GitHub, XWiki Jira).

• Logs: XWiki rendering logs or application logs showing Velocity template evaluation involving $request.request, InstanceManager, or JPythonInterpreter; unexpected Java exceptions related to ScriptXWikiServletRequest.getRequest() on unpatched instances.
• File System: Unexpected files created by the XWiki process (e.g., /tmp/RCE or similar test artifacts); new scripts, web shells, or binaries in the XWiki installation or temp directories.
• Process: Unusual child processes spawned by the XWiki/Tomcat JVM process, such as python, python3, bash, sh, curl, or wget; unexpected outbound network connections from the Java process.
• Network: Outbound connections from the XWiki server to unknown external IPs or C2 infrastructure, particularly initiated by the Tomcat/XWiki process user.
• Application: Newly created or modified wiki pages containing Velocity expressions referencing $request.request, getServletContext, InstanceManager, or scripting interpreter class names (PoC GitHub, XWiki Jira).

Upgrade to XWiki 17.4.8 or 17.10.1 (or later), which fix the vulnerability by requiring programming right to access ScriptXWikiServletRequest#getRequest() (XWiki Advisory, Patch Commit). No configuration-based workaround exists; the only partial mitigation is to carefully restrict script right to highly trusted administrators only, as XWiki itself recommends not granting script right to untrusted users. Organizations should audit current script right assignments and revoke them from any non-essential accounts until patching is complete.

The vulnerability was reported by security researcher Youssef Azefzaf, who also published a public PoC repository on GitHub shortly after disclosure (PoC GitHub). The XWiki security team (michitux) published the advisory and patch on April 8, 2026. The vulnerability was noted in community security tracking feeds including Bluesky CVE bots and PoC-week roundups (tonyharris.io PoC Week). No major media coverage or significant public controversy has been identified beyond standard vulnerability disclosure channels.