VYPR
High severity7.5GHSA Advisory· Published May 26, 2026· Updated May 26, 2026

XWiki Platform's Livetable results still allow reconstructing password hashes using 768 requests

CVE-2026-48048

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.

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

Patches

1
c4442716b02f

XWIKI-23875: LiveTable may use the wrong property class for password and email checks

https://github.com/xwiki/xwiki-platformMichael HamannJan 7, 2026via ghsa
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 != '' &amp;&amp; $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 &amp;&amp; $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

4

News mentions

0

No linked articles in our index yet.