XWiki is a flexible, open-source wiki platform that lets you build websites, project documentation, knowledge bases, and even pretty advanced web applications. But sometimes, even the world’s smartest apps have security bugs that can give attackers a window into what should be kept secret.

CVE-2022-41935 is one of those silent, sneaky problems—fixed in XWiki early in 2023, but dangerous if you’re running older versions. This post breaks down exactly what went wrong, how to exploit it, and (most importantly) how to patch your system.

What Is CVE-2022-41935?

Put simply: users who aren’t supposed to see private wiki docs could figure out those documents exist—just by running smart searches in the “Livetable” feature.

Here’s the core of the problem

- Livetable: XWiki has a dynamic, filterable table widget ("Livetable") that can search or list documents.
- Leak: Even if you don’t have permission to VIEW some documents, repeated Livetable queries would “hint” that hidden docs exist, because the results and counts didn’t properly filter out restricted entries.

Why is this bad?  
Knowing that a document or project _exists_ can leak confidential info, even if nobody can open it—think “Secret-Merger-Plan” or “Layoffs-Q4-2024”, etc.

Where’s the Bug?

The problem comes from how XWiki.LiveTableResultsMacros generates and cleans up its response. When someone queries the Livetable with filters or sorts, the results include metadata—number of total entries, page count, etc. This data was not always fully “scrubbed” to remove private or restricted documents.

Suppose you have this in your wiki

- /Projects/SecretProject (restricted)
- /Projects/PublicProject (public)

An attacker with _no permissions_ could run a Livetable search, filtering by “Projects”, and notice the number of results:

{
  "totalrows": 2, // (should have been 1!)
  "results": [
    {"doc": "Projects.PublicProject"}
  ]
}


Even though only one project shows in the list, "totalrows": 2 tells the attacker that something else is there.

The JavaScript query looks something like this

$.ajax({
  url: '/xwiki/bin/view/Table/LiveTableResults',
  type: 'GET',
  data: {
    query: 'project',
    start: ,
    limit: 10
  },
  success: function (data) {
    // process data.results
    // notice data.totalrows!
  }
});


Attackers could repeat queries with different filters. If the total number changes, it leaks the number (and structure) of hidden docs.

Go to a live table view.

3. Use the filters/search to submit different queries, watching the totalrows value in the response.
4. Each time you tweak the filter, the number might jump or drop, revealing patterns or counts for restricted documents.

Potential structure of the wiki

They cannot directly _read_ secret stuff, but in security, sometimes just knowing something exists is bad enough.

13.10.8

They made sure the Livetable's responses are strictly filtered, cleaning up any traces of obfuscated or restricted entries. The "totalrows" and similar fields now only show the _results you’re allowed to view_.

The patch on XWiki.LiveTableResultsMacros (a Groovy macro) basically adds logic like

// Before: count all potential results, including hidden docs

// After: only count results where current user has view rights

def visibleResults = results.findAll {
  services.security.authorization.hasAccess('view', it.doc)
}

def totalRows = visibleResults.size()


(The real code is more complex, but that’s the big idea.)

Edit the XWiki.LiveTableResultsMacros page on your wiki.

- Apply the filtering logic from the official patch.

Import Patched XAR Archive

- Download the fixed macro (as a .xar archive) from the XWiki extensions repo or security advisory.

13.4.4

Note: There are _no known workarounds_ if you can’t patch or import the macro (e.g., due to locked down hosting).

Official References and Resources

- XWiki Security Advisory (CVE-2022-41935)
- GitHub Patch Commit
- CVE Entry on NVD

If not possible, patch XWiki.LiveTableResultsMacros manually.

3. Audit document access rights: Just because a doc is “hidden” by permissions doesn’t mean its name or presence isn’t leaking elsewhere.
4. Stay up to date with XWiki Security Notices.

In Summary

CVE-2022-41935 is a good reminder: Even simple UI features like tables and search can leak sensitive information if not carefully programmed. With a couple of well-timed queries, attackers could “feel their way” through your supposedly secret wiki structure. But with some quick patches, you can slam that window shut.

If you’re running XWiki, update your system now. If you can’t, grab the patched macro from the links above and stay protected!

Timeline

Published on: 11/23/2022 20:15:00 UTC
Last modified on: 07/06/2023 13:37:00 UTC