XWiki is an advanced wiki platform that allows you to write and run your own Wiki-based applications. But in 2023, a high-risk vulnerability (CVE-2023-41046) was discovered, which lets users execute arbitrary Velocity code—even if they don’t have the script permission. In this post, we break down what the bug is, how it works, why it’s dangerous, and how you can protect your XWiki installation. We’ll include simple code samples, relevant references, and a step-by-step explanation of the exploit.

Vulnerability Details

Normally in XWiki, you need special permissions ("script right") to run Velocity code (the scripting language XWiki uses). This helps prevent ordinary editors from running dangerous scripts. However, there’s a loophole: You can sneak your Velocity code into objects through a TextArea property with a specific content type. When XWiki renders the object, it runs the code, even if you don’t have script rights.

Content Type: VelocityCode _or_ VelocityWiki

Suppose you add such a property to a custom class ("XClass") and fill it with Velocity code. When someone views a document with an object of this class, the code will be executed, even if you only have edit permission (and not script right).

Data Exposure: Velocity may expose sensitive data by allowing access to internal APIs.

- Privilege Escalation: While APIs protected by script rights are safe, attackers could chain vulnerabilities or misconfigurations for privilege escalation.

1. Create an XClass with a “dangerous” TextArea property

Go to: XWiki.ClassEditor

Content Type: VelocityCode or VelocityWiki

https://user-images.githubusercontent.com/your-image.png" alt="XClass property creation" width="500">

Fill the “exploit” property with Velocity code, like

#set($services = $xwiki.get('xwiki:services'))
Document title: $doc.title
#foreach($user in $xwiki.getAllUsers())
 - $user
#end

This code will show the page title and list all users—just as a demo, but more malicious stuff is possible!

3. Save and View the Page

Even with only edit permissions, not script rights, the code will execute as soon as the object is rendered. It runs as your user context, so you don’t get access to protected APIs, but you may access data or abuse misconfigurations.

Exploit Example

Let’s say you want to read some page content you normally can’t see, and leak it via the comment section:

#set($secret = $xwiki.getDocument('Sensitive.Page').getContent())
## Now leak it via a comment, log, or any plugin that handles Velocity output
$secret

- Official CVE Entry
- XWiki Security Advisory
- Patched Release Notes
- XWiki Documentation - Scripting Rights

Who is Affected?

All XWiki installations prior to 14.10.10 and 15.4 RC1 are vulnerable.
If you have users with edit rights but NOT script rights, you’re at risk.

15.4 RC1 or later

No config tweaks, no workarounds exist. You must upgrade.

Conclusion

CVE-2023-41046 makes it much easier for ordinary wiki editors to run untrusted code by abusing the object property system in XWiki. A simple XClass and a textarea field are all you need for unauthorized code execution. To stay safe, always run the latest supported versions of XWiki, limit edit access, and audit your custom classes for suspicious use of VelocityCode or VelocityWiki fields.


Stay secure, keep your wikis patched, and always study how permissions interact with scripting in platforms like XWiki.


_This post is exclusive and written in simple language for better understanding. Share with your sysadmin friends and XWiki users!_

Timeline

Published on: 09/01/2023 20:15:00 UTC
Last modified on: 09/07/2023 19:20:00 UTC