XWiki is a widely used open-source wiki platform. It allows organizations to build collaborative applications and manage documentation websites. In 2022, a critical security vulnerability (CVE-2022-41933) was found in XWiki’s password reset feature. This flaw resulted in users’ new passwords being stored in plain text in the database, creating a serious risk of password leaks and compromise.
In this article, we’ll break down what happened, show you examples of the vulnerability, provide links to references, and explain how the issue was fixed.
What is CVE-2022-41933?
CVE-2022-41933 is a vulnerability affecting XWiki 13.1RC1 and newer. When users used the “Forgot your password” feature at login, XWiki saved their new password in plain text inside the database. This means anyone with access to that database, or an attacker who could exploit another leak vulnerability (like GHSA-599v-w48h-rjrm), could retrieve passwords easily.
Manual password change (by user or admin) was NOT affected.
- Only users of the *main wiki* were concerned; users of “subwikis” in a farm setup were safe, due to an unrelated bug.
In the affected versions, after a password reset
- The new password entered by the user was being stored *in clear text* in the object data of the XWiki database.
- Any privileged user, attacker with database access, or someone exploiting a separate “read” vulnerability could directly recover all users’ reset passwords.
Code Example: What Might Have Happened
While the exact code is internal to XWiki, a bug like this usually happens if someone writes the following:
// Vulnerable Java-style pseudo-code
XWikiDocument userDoc = xwiki.getDocument(userPageRef, context);
BaseObject userObj = userDoc.getXObject("XWiki.XWikiUsers");
String newPassword = request.getParameter("newPassword");
// BAD: Storing password in clear text!
userObj.setStringValue("password", newPassword);
xwiki.saveDocument(userDoc, "Password reset", true, context);
Instead, XWiki should hash the password BEFORE saving
// Fixed code: Secure hashing
String hashedPassword = PasswordHasher.hash(newPassword);
userObj.setStringValue("password", hashedPassword);
But due to a flaw, plain text passwords were written to the database.
Exploit Scenario
Let’s imagine an attacker ‘Mallory’ exploits another XWiki read vulnerability, or has some way to dump the contents of the main wiki’s user database (e.g., SQL injection, backup theft).
In the database, for every user who recently used “Forgot your password,” Mallory finds entries like:
| username | password |
|----------|-----------------|
| alice | MySecret123 |
| bob | passwordReset42 |
| eve | letmein2022 |
Alone, it requires access to the XWiki database.
- If paired with ANY data disclosure flaw (e.g., GHSA-599v-w48h-rjrm), attackers get instant access to valid, real user passwords.
Most people reuse passwords—so the risk goes far beyond XWiki.
Who Was At Risk?
- Main wiki users only. If you ran XWiki as a “wiki farm,” user accounts on subwikis were not exposed—ironically, because of a separate bug.
- Only users who had recently used “forgot my password.” Admin/manual password changes were not at risk.
The XWiki team patched the problem in
- 14.6RC1 release notes
- 14.4.3 release notes
- 13.10.8 release notes
Making sure passwords are *never* stored plain-text (always hashed).
- Running a migration to remove all such plain-text passwords from past database entries and page histories.
2. Prompt them to set a new password with a reset link.
Admins could also configure the migration—whether to force everybody to reset passwords, or just re-hash the stored ones (less secure).
Upgrade! Move to at least 13.10.8 (LTS), 14.4.3, or 14.6RC1.
2. If you were running a vulnerable version, do a forced password reset for all users who used the “Forgot my password” feature.
Advise users not to reuse passwords between different services.
## References / Further Reading
- XWiki Security Advisory: CVE-2022-41933
- XWiki Official Release Notes
- CVE-2022-41933 Detail (MITRE)
Conclusion
CVE-2022-41933 teaches us why password handling must be airtight in all web applications. Even a temporary mistake can expose user secrets, especially when combined with other vulnerabilities. If you run XWiki, ensure you are fully patched and always hash passwords—even after “forgot password” resets.
Timeline
Published on: 11/23/2022 21:15:00 UTC
Last modified on: 12/02/2022 16:57:00 UTC