Raw vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:HSummary
CVE-2023-29509 is a critical-severity Eval Injection (CWE-95) vulnerability in Xwiki Xwiki. Its CVSS base score is 9.9 (Critical).
Operationally, ranked in the top 0.5% of CVEs by exploit likelihood; it is not currently listed in the CISA KEV catalog; a public proof-of-concept is referenced.
The strongest mitigations our analysis identified map to AC-3 (Access Enforcement) and SI-10 (Information Input Validation) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
XWiki Commons, the shared technical libraries used across multiple XWiki projects, contain a code-injection flaw in the documentTree macro. The macro is present by default on the FlamingoThemesCode.WebHome page, and its parameters are not properly escaped, allowing any user who can view commonly accessible documents to supply and execute arbitrary Groovy, Python, or Velocity code. The issue is tracked as CWE-95 and CWE-94 and carries a CVSS 3.1 score of 9.9.
An attacker with view rights on the affected documents can therefore obtain full control of the XWiki installation, including the ability to read, modify, or delete any content and to execute server-side operations. No special privileges beyond ordinary view access are required, and the attack can be performed remotely without user interaction.
The vulnerability was corrected in the releases XWiki 13.10.11, 14.4.7, and 14.10; the corresponding patches are documented in the project’s GitHub security advisory GHSA-f4v8-58f6-mwj4 and the commit 80d5be36f700adcd56b6c8eb3ed8b973f62ec0ae, as well as the Jira ticket XWIKI-20279. Administrators are advised to upgrade to one of the fixed versions.
The EPSS score for this CVE has remained flat at 0.3608 since disclosure, indicating no material increase in observed exploitation interest.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2023-1278
Vulnerability Data
XWiki Commons are technical libraries common to several other top level XWiki projects. Any user with view rights on commonly accessible documents can execute arbitrary Groovy, Python or Velocity code in XWiki leading to full access to the XWiki installation.…
more
The root cause is improper escaping of the `documentTree` macro parameters in This macro is installed by default in `FlamingoThemesCode.WebHome`. This page is installed by default. The vulnerability has been patched in XWiki 13.10.11, 14.4.7 and 14.10.
- CWE(s)
Related Threats
Likely ATT&CK TechniquesAI
Techniques this vulnerability likely enables, inferred from its description, weakness type, and attributed-actor tradecraft. Confidence is per-technique.
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
Mitigating Controls (NIST 800-53 r5) AI
Mandatory validation and escaping of all macro parameters would have blocked the unsanitized documentTree input that permits Groovy/Python/Velocity injection.
Proper enforcement of view-only rights would have denied the ability to trigger server-side code execution through the macro.
Application of the documented patches (13.10.11/14.4.7/14.10) directly eliminates the improper-escaping flaw in the default FlamingoThemesCode.WebHome macro.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure SDLC practices directly require input neutralization and avoidance of unsafe dynamic evaluation.
PR.DS-10 protects runtime data confidentiality/integrity but has no bearing on neutralizing externally influenced input during code generation, so neither direction shows any preventive effect.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing in development can detect eval injection vulnerabilities before deployment.
Secure development life cycle mandates input validation and safe coding practices that directly prevent eval injection.
Application security requirements include rules against dynamic code execution of untrusted input.
Secure architecture principles discourage unsafe dynamic evaluation constructs.
Secure coding explicitly requires neutralization of input before dynamic evaluation, directly mitigating eval injection.
Separation of environments limits the blast radius if eval injection occurs in non-production.