Any user with view access to the XWiki space can change the authenticatorGHSA-f9c6-2f9p-82jj
Fix: xwiki/xwiki-platform@5efc31cGHSA-f9c6-2f9p-82jj is a CWE-862 vulnerability in org.xwiki.platform:xwiki-platform-security-authentication-ui. A fix is available for org.xwiki.platform:xwiki-platform-security-authentication-ui — see the affected versions and patch details below.
Exploitation Status
No confirmed exploitation observed yet
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- A successful exploit gives an attacker total control of the affected component, not partial access.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-f9c6-2f9p-82jj.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
Real-World Exposure
org.xwiki.platform:xwiki-platform-security-authentication-ui☕org.xwiki.platform:xwiki-platform-security-authentication-ui☕org.xwiki.platform:xwiki-platform-security-authentication-uiReal-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
A user who can access pages located in the XWiki space (by default, anyone) can access the page XWiki.Authentication.Administration and (unless an authenticator is set in xwiki.cfg) switch to another installed authenticator.
Note that, by default, there is only one authenticator available (Standard XWiki Authenticator). So, if no authenticator extension was installed, it's not really possible to do anything for an attacker.
Also, in most cases, if you have installed and are using an SSO authenticator (like OIDC or LDAP for example), the worst an attacker can do is break authentication by switching back to the standard authenticator (that's because it's impossible to login to a user which does not have a stored password, and that's usually what SSO authenticator produce).
Patches
This has been patched in XWiki 15.10.9 and XWiki 16.3.0RC1.
Workarounds
You can very easily fix this vulnerability in your instance through right configuration:
- access the page and children right administration of the page
XWiki.Authentication(https://myhost/xwiki/bin/admin/XWiki/Authentication/WebPreferences?editor=spaceadmin§ion=PageAndChildrenRights&space=XWiki.Authentication#|t=usersandgroupstable&p=1&l=10&uorg=groups&wiki=local&clsname=XWiki.XWikiGlobalRights) - make sure only admin user have the VIEW right
References
https://jira.xwiki.org/browse/XWIKI-22604 https://github.com/xwiki/xwiki-platform/commit/5efc31cea1501c9a5cb593566fea8b558ff32a2a
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-security-authentication-ui | ≥ 15.3-rc-1&&< 15.10.14 | 15.10.14org.xwiki.platform:xwiki-platform-security-authentication-ui:15.10.14 |
| ☕Maven | org.xwiki.platform:xwiki-platform-security-authentication-ui | ≥ 16.0.0-rc-1&&< 16.4.6 | 16.4.6org.xwiki.platform:xwiki-platform-security-authentication-ui:16.4.6 |
| ☕Maven | org.xwiki.platform:xwiki-platform-security-authentication-ui | ≥ 16.5.0-rc-1&&< 16.10.0-rc-1 | 16.10.0-rc-1org.xwiki.platform:xwiki-platform-security-authentication-ui:16.10.0-rc-1 |
Affected Products
xwikixwikiDetection & 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-security-authentication-ui, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update org.xwiki.platform:xwiki-platform-security-authentication-ui to 15.10.14 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-f9c6-2f9p-82jj is resolved across your whole dependency graph.
Workarounds
Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.
Frequently Asked Questions
Is GHSA-f9c6-2f9p-82jj in your dependencies?
Find it across Maven, including transitive dependencies.