CVE-2026-48048: XWiki Platform Information Disclosure

CVE-2026-48048 Overview

CVE-2026-48048 affects the XWiki Platform, a generic open-source wiki platform. The vulnerability resides in the LiveTableResults component and enables unauthenticated attackers to disclose password hashes and salts one bit at a time. XWiki maintainers found that the earlier patch for GHSA-5cf8-vrr8-8hjm was insufficient because slightly modified request parameters still trigger the leak. An attacker can recover a full user password salt and hash with approximately 768 crafted requests. Fixed versions are 18.0.0RC1, 17.10.13, 17.4.9, and 16.10.17. The flaw is tracked under CWE-359 (Exposure of Private Personal Information).

Critical Impact
Unauthenticated attackers can extract stored password hashes and salts from any XWiki user account over the network with roughly 768 HTTP requests, enabling offline password cracking.

Affected Products

XWiki Platform versions 6.2.1 through 16.10.16
XWiki Platform 17.x versions prior to 17.4.9 and 17.10.13
XWiki Platform 18.x versions prior to 18.0.0RC1

Discovery Timeline

2026-08-10 - CVE-2026-48048 published to NVD
2026-08-10 - Last updated in NVD database

Technical Details for CVE-2026-48048

Vulnerability Analysis

The vulnerability lives in the XWiki.LiveTableResultsMacros wiki page, which powers the live table result rendering. Live tables generate SQL queries dynamically from column names supplied in the request. The original protection excluded columns whose class type is Password or obfuscated Email. However, the check relied on $class.get($colname) resolving the property against the primary class only. Attackers can supply modified parameters that cause the type check to fall through, allowing password and email fields to be included in the query. Because query filters accept partial matches, an attacker can perform boolean-style comparisons and infer the hash bit by bit.

Root Cause

The patch for the earlier advisory GHSA-5cf8-vrr8-8hjm inspected the wrong property class when identifying Password and Email fields. When alternate class parameters were provided, the type detection returned no match and skipped the exclusion logic. This is a broken access control condition in the query construction path rather than a cryptographic weakness. The fix introduces the #livetable_getPropertyClassAndType macro to resolve the property class correctly before evaluating the field type.

Attack Vector

Exploitation requires no authentication and no user interaction. An attacker sends HTTP requests to the live table endpoint with tampered class and column parameters targeting the password field of a chosen user. Each request tests a single bit of the stored hash or salt using a filter comparison. Repeating the process across 768 requests yields the full hash and salt, which the attacker then cracks offline.

text

// Patch excerpt from XWiki.LiveTableResultsMacros.xml
   #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)

Source: XWiki Platform commit c4442716

Detection Methods for CVE-2026-48048

Indicators of Compromise

High-volume sequential requests to /xwiki/bin/get/XWiki/LiveTableResults or pages invoking LiveTableResultsMacros from a single client.
Query strings referencing password, password_hash, salt, or user class field names in the collist or filter parameters.
Repeated requests differing only by a small change in a filter value, consistent with bit-by-bit oracle probing.

Detection Strategies

Alert on unauthenticated access to live table endpoints returning HTTP 200 responses at rates above baseline for the environment.
Inspect access logs for classname parameter values that differ from the target document's declared class, combined with password-related column names.
Correlate large bursts of similar requests originating from the same source IP against XWiki paths within short time windows.

Monitoring Recommendations

Enable verbose HTTP access logging on the XWiki application server and forward logs to a central analytics platform for long-term retention.
Track authentication anomalies for accounts whose usernames appear in recent live table queries, since credential cracking may follow hash extraction.
Review web application firewall (WAF) telemetry for repeated variations of the same request signature targeting XWiki live table URLs.

How to Mitigate CVE-2026-48048

Immediate Actions Required

Upgrade XWiki Platform to 18.0.0RC1, 17.10.13, 17.4.9, or 16.10.17, whichever matches the current release track.
Force password rotation for all user accounts if the live table endpoint was exposed to untrusted networks prior to patching.
Restrict network access to the XWiki application to trusted networks until the upgrade is complete.

Patch Information

The fix is delivered in commit c4442716b02ffcdaa9d5e703b1db6203e36456fa and documented in the GitHub Security Advisory GHSA-rh28-mqj4-8x59. The upstream tracking ticket is XWIKI-23875. The patch replaces the vulnerable property class lookup with the new #livetable_getPropertyClassAndType macro so password and email fields are correctly excluded from generated queries.

Workarounds

Manually apply the patch to the XWiki.LiveTableResultsMacros wiki page using the diff published in the upstream commit.
Place the XWiki instance behind an authenticated reverse proxy so anonymous users cannot reach the live table endpoint.
Add WAF rules that reject requests to live table URLs whose parameters reference password or email field names.

bash

# Verify the installed XWiki version against fixed releases
curl -s https://xwiki.example.com/xwiki/bin/view/Main/ | grep -Eo 'XWiki [0-9]+\.[0-9]+\.[0-9]+'

# Example WAF deny rule (ModSecurity)
SecRule REQUEST_URI "@contains /xwiki/bin/get/XWiki/LiveTableResults" \
  "chain,id:1026048048,phase:2,deny,status:403,msg:'CVE-2026-48048 LiveTable password field access'"
  SecRule ARGS "@rx (?i)(password|passwd|salt)" "t:none"