Raw vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:LSummary
CVE-2023-29511 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 40% 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 SI-10 (Information Input Validation) and SI-2 (Flaw Remediation) — 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 Platform, a generic wiki platform, contains an improper input sanitization flaw in the default-installed XWiki.AdminFieldsDisplaySheet component. The issue stems from inadequate escaping of section identifiers, which permits any user possessing edit rights on a page to inject and execute arbitrary Groovy, Python, or Velocity code, resulting in complete control over the XWiki installation. The vulnerability is tracked as CVE-2023-29511 with a CVSS score of 9.9 and is associated with CWE-95.
An authenticated attacker with page edit permissions, such as on their own user page, can exploit the flaw to run server-side scripts that bypass intended access controls and achieve full system compromise, including data exfiltration or modification. No special user interaction or advanced network positioning is required beyond standard edit access.
Official advisories and patches recommend upgrading to XWiki versions 15.0-rc-1, 14.10.1, 14.4.8, or 13.10.11, where the escaping logic in AdminFieldsDisplaySheet has been corrected; the fixes are detailed in the referenced GitHub commits and security advisory GHSA-rfh6-mg6h-h668. The EPSS score has remained flat at its peak value of 0.2925 with no material increase observed after disclosure.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2023-1391
Vulnerability Data
XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. Any user with edit rights on a page (e.g., it's own user page), can execute arbitrary Groovy, Python or Velocity code in XWiki…
more
leading to full access to the XWiki installation. The root cause is improper escaping of the section ids in `XWiki.AdminFieldsDisplaySheet`. This page is installed by default. The vulnerability has been patched in XWiki versions 15.0-rc-1, 14.10.1, 14.4.8, and 13.10.11.
- 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
Directly requires validation and sanitization of untrusted input (section IDs) to block injection of Groovy/Python/Velocity code.
Mandates prompt application of vendor patches that correct the missing escaping logic in AdminFieldsDisplaySheet.
Enforces that page-edit rights must not implicitly grant arbitrary server-side code execution privileges.
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.
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.