CVE-2023-29209 is a serious vulnerability that struck XWiki, an open-source enterprise wiki platform, exposing installations to severe remote code execution (RCE) risks. Discovered in the XWiki Commons libraries, this flaw gives any user—including those with only viewing rights—the ability to run arbitrary code (Groovy, Python, or Velocity) on the XWiki server. Below, we break down the cause, show how it can be exploited, and give you the steps you need to secure your XWiki.
What Is XWiki Commons?
XWiki Commons is a set of technical libraries shared among various XWiki projects. XWiki is known for its extensibility and scripting power, but those same strengths can turn into weaknesses when not handled securely. The Commons library contains a macro called the legacy notification activity macro, which is involved in presenting change notifications as an activity stream.
Key Points
- Unauthenticated Code Execution: Any user with view rights on a document with the legacy notification activity macro can inject and execute code.
- Macro Parameter Escaping Flaw: The problem was caused by improper escaping of macro parameters, allowing malicious input to break out into executable code.
Default Installation: The vulnerable macro is present by default in all installations.
- Multiple Avenues for Attack: Vulnerability can be triggered via any editable wiki page—including user profiles—or, with just view rights, through the HTMLConverter function in the CKEditor (which ships with XWiki).
Exploit Scenario
Let’s say there’s a page in your XWiki that includes the legacy notification activity macro. An attacker with view rights could exploit the lack of parameter sanitization in this macro. Here’s how they might do it.
Suppose the macro gets rendered like this
{{activityStream livetableColumns="doc.title,doc.space,doc.date" /}}
If an attacker can inject parameters, malicious Velocity or Groovy code could be inserted
{{activityStream livetableColumns="$services.component.script.execute('groovy', 'println(\"PWNED\")')" /}}
If the macro parameters are not properly escaped or sandboxed, this code will execute on the XWiki backend with the privileges of the XWiki server.
Realistic Exploit via CKEditor’s HTMLConverter
Even without edit rights, features like the HTMLConverter (part of CKEditor integration) double down on the risk. CKEditor is WYSIWYG and may process (and execute) input from users with only view rights due to poor isolation of backend script evaluation.
Proof-of-Concept (PoC) Exploit
Below is a simple proof-of-concept (for educational use only) showing how to inject Groovy code via macro parameters in a vulnerable XWiki page.
Step 1: Place a macro call on a page you can view (might happen automatically in profiles, activity feeds, etc):
{{activityStream livetableColumns="doc.title,doc.space,doc.date" parameter="='#set($e='123')#foreach($i in [1..2])$e#end${script:groovy:println('PWNED!')}" /}}
What happens?
When the page is rendered, PWNED! will be printed to server logs or page output, proving code execution.
References
- Original XWiki Security Advisory
- Sonar Source Blog Post
- CVE-2023-29209 at NVD
- XWiki Vulnerability Timeline
Preferably, upgrade to the latest 14.10 version.
Limit view access where possible.
- Use least privilege: only give edit/view/share rights to trusted users.
Conclusion
CVE-2023-29209 serves as a sharp reminder that flexibility in platforms like XWiki comes with security risks. Don’t rely on user rights alone for safety—improperly escaped macros can turn “view-only” accounts into full system access for attackers. Patch now, double-check your pages, and stay alert for news of new vulnerabilities.
If your XWiki is exposed to the internet and not fully patched, you could be running on borrowed time.
*This content is original, with details summarized and clarified from the official advisories and security research. For the good of the community: patch early, patch often!*
Timeline
Published on: 04/15/2023 17:15:00 UTC
Last modified on: 04/25/2023 17:26:00 UTC