XWiki.WebHome vulnerable to Improper Privilege Management in XWiki resolving groupsGHSA-g4h6-qp44-wqvx
HIGHFix: xwiki/xwiki-platform#1800GHSA-g4h6-qp44-wqvx is a high-severity (CVSS 8.1) Improper Privilege Management vulnerability in org.xwiki.platform:xwiki-platform-oldcore. 2 public exploit or proof-of-concept references are indexed, so weaponization risk is real. A fix is available for org.xwiki.platform:xwiki-platform-oldcore — see the affected versions and patch details below.
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- A successful exploit gives an attacker total control of the affected component, not partial access.
Exploitation and automatability from CISA’s SSVC triage for GHSA-g4h6-qp44-wqvx.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
Where this sits among everything scored
Real-World Exposure
org.xwiki.platform:xwiki-platform-oldcore☕org.xwiki.platform:xwiki-platform-oldcoreReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.
Description
Impact
It's possible to exploit a bug in XWikiRights resolution of groups to obtain privilege escalation.
More specifically, editing a right with the object editor leads to adding a supplementary empty value to groups which is then resolved as a reference to XWiki.WebHome page. Adding an XWikiGroup xobject to that page then transforms it to a group, any user put in that group would then obtain the privileges related to the edited right.
Note that this security issue is normally mitigated by the fact that XWiki.WebHome (and XWiki space in general) should be protected by default for edit rights.
Patches
The problem has been patched in XWiki 13.10.4 and 14.2RC1 to not consider anymore empty values in XWikiRights.
Workarounds
It's possible to workaround the problem by setting appropriate rights on XWiki.WebHome page to prevent users to edit it.
References
For more information
If you have any questions or comments about this advisory:
- Open an issue in Jira XWiki.org
- Email us at Security Mailing List
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | org.xwiki.platform:xwiki-platform-oldcore | ≥ 11.3.7&&< 13.10.4 | 13.10.4org.xwiki.platform:xwiki-platform-oldcore:13.10.4 |
| ☕Maven | org.xwiki.platform:xwiki-platform-oldcore | ≥ 14.0-rc-1&&< 14.2-rc-1 | 14.2-rc-1org.xwiki.platform:xwiki-platform-oldcore:14.2-rc-1 |
Affected Products
xwikixwikiResearch use only. For defensive security, authorized penetration testing, and academic research only. Never execute exploit code against systems without explicit written authorization.
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for org.xwiki.platform:xwiki-platform-oldcore, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update org.xwiki.platform:xwiki-platform-oldcore to 13.10.4 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-g4h6-qp44-wqvx is resolved across your whole dependency graph.
Workarounds
Close the privilege gap rather than the entry point: audit which accounts, roles and service identities can reach the affected operation, drop the component to the least privilege it actually needs, and review file and directory permissions created by earlier installs — a default left in place is what makes this reachable.
Frequently Asked Questions
Is GHSA-g4h6-qp44-wqvx in your dependencies?
Find it across Maven, including transitive dependencies.