XWiki Platform's Livetable results still allow reconstructing password hashes using 768 requests
Description
Impact
XWiki discovered that the patch for GHSA-5cf8-vrr8-8hjm was insufficient and with slightly modified parameters to the LiveTableResults, it is still possible to discover password hashes one bit at a time, so with 768 requests, the full password salt and hash can be retrieved of a user.
Patches
The check for password (and email properties) has been adjusted in XWiki 18.0.0RC1, 17.10.13, 17.4.9 and 16.10.17.
Workarounds
The patch can be applied manually to the wiki page XWiki.LiveTableResultsMacros.
### Resources * https://jira.xwiki.org/browse/XWIKI-23875 * https://github.com/xwiki/xwiki-platform/commit/c4442716b02ffcdaa9d5e703b1db6203e36456fa
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
XWiki LiveTableResults endpoint allows attackers to reconstruct password hashes via 768 requests due to insufficient filtering of password properties.
Vulnerability
The LiveTableResults macro in XWiki Platform fails to properly filter password and email properties when a class is specified via the _class parameter, bypassing the incomplete fix for GHSA-5cf8-vrr8-8hjm [2]. Affected versions include XWiki Platform >=6.2.1, <16.10.17; >=17.0.0-rc-1, <17.4.9; and >=17.5.0-rc-1, <17.10.13 [2]. An attacker can retrieve password hashes one bit at a time by making 768 requests to the endpoint.
Exploitation
An attacker sends crafted requests to /xwiki/bin/get/XWiki/LiveTableResults with parameters such as outputSyntax=plain, password_class=XWiki.XWikiUsers, collist=password, and password=hash:SHA-512:c [4]. By iterating over possible hash characters, the attacker reconstructs the full password salt and hash. No authentication is required if the endpoint is publicly accessible, and the attack requires 768 requests to complete [2].
Impact
Successful exploitation leads to disclosure of password hashes and salts for XWiki users. This enables offline password cracking, potentially compromising user accounts. The vulnerability is rated high severity due to the exposure of sensitive authentication data [2].
Mitigation
The fix is included in XWiki versions 18.0.0RC1, 17.10.13, 17.4.9, and 16.10.17 [3]. Users should upgrade to these versions. As a workaround, the patch can be applied manually to the wiki page XWiki.LiveTableResultsMacros as described in the commit [1]. No known KEV listing exists.
- XWIKI-23875: LiveTable may use the wrong property class for password … · xwiki/xwiki-platform@c444271
- CVE-2026-48048 - GitHub Advisory Database
- Livetable results still allow reconstructing password hashes using 768 requests
- Livetable results still allow reconstructing password hashes using 768 requests
AI Insight generated on May 26, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
3- Range: >= 17.5.0-rc-1, < 17.10.3
Patches
1c4442716b02fXWIKI-23875: LiveTable may use the wrong property class for password and email checks
2 files changed · +30 −3
xwiki-platform-core/xwiki-platform-livetable/xwiki-platform-livetable-ui/src/main/resources/XWiki/LiveTableResultsMacros.xml+4 −3 modified@@ -75,9 +75,10 @@ #foreach($colname in $collist) ## If a classname is defined and the class field corresponding to the column name, ## we check the type of the field and skip it if it's Password. - #if ($className != '' && $class.get($colname)) - #set ($isPasswordType = $class.get($colname).classType == 'Password') - #set ($isEmailType = $class.get($colname).classType == 'Email') + #livetable_getPropertyClassAndType($colname) + #if ($propType != '') + #set ($isPasswordType = $propClass.get($colname).classType == 'Password') + #set ($isEmailType = $propClass.get($colname).classType == 'Email') #set ($emailObfuscated = $services.mail.general.shouldObfuscate()) #if (!($isPasswordType || ($isEmailType && $emailObfuscated))) #livetable_addColumnToQuery($colname)
xwiki-platform-core/xwiki-platform-livetable/xwiki-platform-livetable-ui/src/test/java/org/xwiki/livetable/LiveTableResultsTest.java+26 −0 modified@@ -567,6 +567,32 @@ void cleanupAccessToPasswordFields() throws Exception + "and doc.fullName not in (:classTemplate1, :classTemplate2) "); } + @Test + void noAccessToPasswordFieldsWithClassPerProperty() throws Exception + { + // Initialize an XClass with a password field. + DocumentReference documentReference = new DocumentReference("xwiki", "XWiki", "MyClass"); + XWikiDocument xwikiDocument = this.xwiki.getDocument(documentReference, this.context); + BaseClass xClass = xwikiDocument.getXClass(); + xClass.addPasswordField("password", "Password", 30); + this.xwiki.saveDocument(xwikiDocument, this.context); + + when(this.queryService.hql(anyString())).thenReturn(this.query); + when(this.query.setLimit(anyInt())).thenReturn(this.query); + when(this.query.setOffset(anyInt())).thenReturn(this.query); + when(this.query.bindValues(any(Map.class))).thenReturn(this.query); + when(this.query.count()).thenReturn(0L); + when(this.query.execute()).thenReturn(Collections.emptyList()); + + this.request.put("password", "abcd"); + this.request.put("password_class", "XWiki.MyClass"); + this.request.put("collist", "password"); + + renderPage(); + + verify(this.queryService).hql(" where 1=1 "); + } + @Test void highLimitIsRejected() throws Exception {
Vulnerability mechanics
Root cause
"The LiveTableResults macro used the wrong property class object when checking field types, so a per-property class specification could bypass the password/email field filtering."
Attack vector
An attacker sends crafted requests to the LiveTableResults endpoint with a `password_class` parameter pointing to a class that has a password field, and includes `password` in the `collist` parameter. Because the macro previously used `$class.get($colname)` (the default class) instead of the per-property class, the password type check was skipped and the password hash was included in query results [ref_id=1]. By issuing approximately 768 requests that filter on individual bits of the hash, the attacker can reconstruct the full password salt and hash of any user [ref_id=1].
Affected code
The vulnerable code is in the `XWiki.LiveTableResultsMacros` wiki page, specifically the Velocity macro that iterates over `$collist` and checks field types using `$class.get($colname)` [ref_id=1]. The patch modifies lines 78-80 of the macro to use `#livetable_getPropertyClassAndType($colname)` and `$propClass.get($colname).classType` instead.
What the fix does
The patch replaces `$class.get($colname)` with a call to `#livetable_getPropertyClassAndType($colname)`, which correctly resolves the property class for each column [patch_id=2569304]. It then uses `$propClass.get($colname).classType` instead of `$class.get($colname).classType` to check for Password and Email types. This ensures that even when a per-property class is specified via request parameters, the field type check uses the correct class object and properly filters out sensitive fields.
Preconditions
- networkThe attacker must be able to send HTTP requests to the LiveTableResults endpoint
- inputThe attacker must know or guess a target user's password field property name and class reference
Generated on May 26, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
4News mentions
0No linked articles in our index yet.