GHSA-4v38-964c-xjmw
CRITICALCode injection via unescaped translations in xwiki-platform
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
org.xwiki.platform:xwiki-platform-administration-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
In XWiki, every user can add translations that are only applied to the current user. This also allows overriding existing translations. Such translations are often included in privileged contexts without any escaping which allows remote code execution for any user who has edit access on at least one document which could be the user's own profile where edit access is enabled by default.
The following describes a proof of concept exploit to demonstrate this vulnerability:
- Edit the user profile with the wiki editor and set the content to
error={{/html}} {{async async="true" cached="false" context="doc.reference"}}{{groovy}}println("hello from groovy!"){{/groovy}}{{/async}}
- Use the object editor to add an object of type
XWiki.TranslationDocumentClasswith scopeUSER. - Open the document
WikiManager.AdminWikiDescriptorSheet.
The expected result would be that a message with title {{/html}} {{async async="true" cached="false" context="doc.reference"}}{{groovy}}println("hello from groovy!"){{/groovy}}{{/async}} is displayed while in fact an error that the HTML macro couldn't be executed is displayed, followed by the text "hello from groovy!" and some raw HTML, showing that the Groovy macro has been executed.
Patches
A mitigation for this vulnerability is part of XWiki 14.10.2 and XWiki 15.0 RC1: translations with user scope now require script right. This means that regular users cannot exploit this anymore as users don't have script right by default anymore starting with XWiki 14.10.
Workarounds
There are no known workarounds apart from upgrading to a patched versions.
References
- https://jira.xwiki.org/browse/XWIKI-19749
- https://github.com/xwiki/xwiki-platform/commit/d06ff8a58480abc7f63eb1d4b8b366024d990643
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-administration-ui | ≥ 4.3-milestone-2&&< 14.10.2 | 14.10.2 |
Research 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-administration-ui. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update org.xwiki.platform:xwiki-platform-administration-ui to 14.10.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-4v38-964c-xjmw is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-4v38-964c-xjmw is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-4v38-964c-xjmw. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-4v38-964c-xjmw in your dependencies?
O3 detects GHSA-4v38-964c-xjmw across Maven dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.