XWiki is a popular open-source platform for creating collaborative knowledge bases and wikis. Many major industries rely on it—including education, research, and software development. But sometimes, a small bug can open the way to a huge problem. That’s exactly what happened with CVE-2023-29507, a vulnerability in the "XWiki Commons" technical libraries used by many XWiki projects.

In this article, you'll find a plain-English breakdown of the vulnerability, a code example to show how it worked, exploit details, references for further reading, and information about the official fix.

What Happened? (The TL;DR)

The XWiki platform lets you write scripts that can interact with documents and their authors. A bug in the Document script API meant attackers could swap out authors by using the DocumentAuthors API, assigning themselves rights, and then running code with higher privileges.

This made it possible for any attacker who could run scripts to elevate their permissions and execute code as someone with much higher rights than they should have.

User A creates a document. Only they, or another authorized user, can run scripts as that user.

- Normally, the system checks which user wrote the script when deciding if it should run with high-level permissions.

But with CVE-2023-29507, any user who could access the script API could change the "author" field of a document—even giving themselves full rights. That meant they could:

The Vulnerable Code Pattern

The issue sits in the way the API returns the DocumentAuthors object directly, instead of a safer, restricted one.

Here’s a somewhat simplified, illustrative code snippet

// Vulnerable: Direct access to set author!

Document doc = getSomeDocument();
DocumentAuthors authors = doc.getAuthors();
// Oops: You can set any author!
authors.setAuthor("superadmin");

// Now any script run here will check as if "superadmin" wrote the script!
// So the checks pass, and you can do things only superadmin could do:
executeAdminScript(doc);

The problem is clear: authors.setAuthor()'s effect is trusted everywhere else, but a regular user could manipulate it.

Step-by-Step Exploit Example

Let’s say you’re a user on a public XWiki server and you have the right to run scripts. Here’s what the exploit could look like in Velocity code:

#set($doc = $xwiki.getDocument('Sandbox:TestPage'))
#set($authors = $doc.getAuthors())
#* Set yourself (or any account) as the document's author *#
$authors.setAuthor("XWiki.SuperAdmin")
#* Now, run admin-only actions as part of a script *#
#if($xwiki.hasAdminRights())
  ## This code will now execute as if it were run by SuperAdmin!
  $services.admin.doAdminThings()
#end

Result: The script block will now work as if it was executed by "SuperAdmin". Any admin-restricted script or admin-level tool can now be exploited and run by the attacker.

Privilege escalation: Any script-writer can become an admin for the purpose of script execution.

- Remote Code Execution: Attackers can potentially run arbitrary code/server commands, depending on script content.

The Fix: Returning a Safe Script API

After this bug was reported, the XWiki team moved quickly and released patches.

XWiki 14.4.7

Solution: Change the API so that when a script requests the DocumentAuthors object, it doesn't get a mutable reference it can use to set the author arbitrarily. Instead, a safe "read-only" API is returned, preventing the setAuthor() call.

If you’re running XWiki, upgrade NOW if you haven’t!

References & Further Reading

- CVE-2023-29507 on NIST
- GHSA-8h39-jvp7-8j5p (GitHub Advisory)
- XWiki Release Notes
- XWiki Security Advisories

Final Thoughts

XWiki is very powerful—its script APIs let you do almost anything inside the wiki environment. But with great power comes great risk: A single overlooked method can create a privilege escalation bug. If you run or develop on XWiki, always keep an eye on scripts, permissions, and patch your instance regularly.

Has your XWiki not been updated since early 2023? Stop reading and patch it now!

Stay safe, and watch those APIs! 🚨

*Exclusive breakdown by OpenAI’s ChatGPT. Please credit if shared.*

Timeline

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