CVE-2026-48048

The patch for the original password hash oracle vulnerability was structurally incomplete, not just insufficient—this CVE proves it. Attackers can revive the bit-by-bit extraction using 'slightly modified parameters,' which is forensic evidence that the original fix addressed a specific attack vector rather than the underlying timing oracle in LiveTableResults. The oracle itself—the timing-sensitive query construction that enables sequential bit extraction—remained intact at another parameter configuration the original patch didn't cover. The 768 requests required for extraction is telling: it's noisy enough to suggest the original attack was faster, meaning the partial patch attenuated the exploit without eliminating it. This creates a dangerous false sense of security. Organizations that closed their remediation tickets after applying the GHSA-5cf8-vrr8-8hjm fix are now sitting on unpatched exposure without knowing it. The blast radius of an incomplete patch extends not just to vulnerable systems, but to every audit and security assessment that treated the original CVE as resolved. The manual workaround compounds the problem. The patch lives in XWiki.LiveTableResultsMacros—a wiki page, not a JAR. This means security logic lives in versioned user content rather than compiled platform code. Your security validation workflow now requires auditing the actual content of that macro across all wiki instances (main wiki plus subwikis), verifying no local overrides reintroduced vulnerable parameter construction, and tracking whether migrations or restores have reverted the patch. This is a substantially harder assurance problem than checking a version number. The version fragmentation across 16.x, 17.x, and 18.x suggests architectural debt: the timing-sensitive query construction pattern keeps reproducing in different code paths as the platform evolves. The underlying query abstraction wasn't hardened—each point release negotiated between fixing the reported vector and preserving feature behavior until someone found the next parameter variant. The real question is whether that page's logic should ever have been trusted to contain security-critical branching in the first place. Treat this as unpatched until you've verified the LiveTableResults macro content itself, not just the platform version.

Reviewed through automated stages and approved by a human before publication.