Cyber Resilience

CVE-2024-37900

RCE in Xwiki 4.2 – 14.10.21

Public PoCRCE
Published
31 July 2024
Modified
10 January 2025
Patch / advisory
CVSS Score v3.1 6.4
Click a component to see what it means
Raw vectorCVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:N
EPSS Score 0.16 97th percentile
Risk Priority 59 floored blend · peak EPSS

Summary

CVE-2024-37900 is a medium-severity Static Code Injection (CWE-96) vulnerability in Xwiki Xwiki. Its CVSS base score is 6.4 (Medium).

Operationally, exploitation aligns with the MITRE ATT&CK technique Command and Scripting Interpreter (T1059); ranked in the top 3% 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 SA-11 (Developer Testing and Evaluation) 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 Platform, a generic wiki platform, is affected by a client-side code injection vulnerability (CWE-94, CWE-96) that triggers when a user uploads an attachment whose filename contains malicious JavaScript. The flaw allows the injected script to execute in the browser during the upload process itself, with a CVSS 3.1 score of 6.4 reflecting the combination of network attack vector, high attack complexity, and required user interaction.

An attacker must first perform social engineering to convince a victim who possesses upload rights to submit a file with a crafted name. Successful exploitation runs arbitrary JavaScript solely in the context of the uploading user, enabling actions such as modifying content or performing privileged operations on that user’s behalf; the malicious filename is visible to the victim, limiting the practicality of the attack.

The vulnerability has been fixed in XWiki releases 14.10.21, 15.5.5, 15.10.6, and 16.0.0, as documented in the project’s GitHub security advisory and the associated code commits that sanitize attachment filenames before processing. The EPSS score remains flat at 0.0533 with no observed increase after disclosure.

OWASP Top 10 for Web (2025)

EU & UK References

Vulnerability Data

XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. When uploading an attachment with a malicious filename, malicious JavaScript code could be executed. This requires a social engineering attack to get the…

more

victim into uploading a file with a malicious name. The malicious code is solely executed during the upload and affects only the user uploading the attachment. While this allows performing actions in the name of that user, it seems unlikely that a user wouldn't notice the malicious filename while uploading the attachment. This has been patched in XWiki 14.10.21, 15.5.5, 15.10.6 and 16.0.0.

CWE(s)

Related Threats

MITRE ATT&CK Enterprise Techniques

T1059 Command and Scripting Interpreter Execution
Adversaries may abuse command and script interpreters to execute commands, scripts, or binaries.
T1059.001 PowerShell Execution
Adversaries may abuse PowerShell commands and scripts for execution.
T1059.002 AppleScript Execution
Adversaries may abuse AppleScript for execution.
T1059.004 Unix Shell Execution
Adversaries may abuse Unix shell commands and scripts for execution.
T1059.005 Visual Basic Execution
Adversaries may abuse Visual Basic (VB) for execution.
T1059.006 Python Execution
Adversaries may abuse Python commands and scripts for execution.
Derived from this CVE’s CWE(s) via the direct CWE→ATT&CK cross-walk.

CVEs Like This One

CVE-2024-55877Same product: Xwiki Xwiki
CVE-2024-55662Same product: Xwiki Xwiki
CVE-2023-46243Same product: Xwiki Xwiki
CVE-2023-37914Same product: Xwiki Xwiki
CVE-2024-37899Same product: Xwiki Xwiki
CVE-2023-26477Same product: Xwiki Xwiki
CVE-2023-40177Same product: Xwiki Xwiki
CVE-2023-29210Same product: Xwiki Xwiki
CVE-2023-35152Same product: Xwiki Xwiki
CVE-2023-35150Same product: Xwiki Xwiki

Affected Assets

xwiki
xwiki
16.0.0, 4.2 · 4.2 — 14.10.21 · 15.0 — 15.5.5 · 15.6 — 15.10.6

Mitigating Controls

Control response

Prevent
Stop it (NIST 800-53)

Detect
Catch it (NIST detect / respond)

Harden
Shrink the surface (DISA STIG)

Validate
Prove the fix (OWASP ASVS)
  • V1.3.1
  • V1.3.2

Mitigating Controls (NIST 800-53 r5) AI

Developer testing and evaluation can discover missing neutralization of directives in saved code artifacts.

Input validation directly stops unneutralized directives from being inserted into static code resources.

Least privilege limits the damage an injected code fragment can perform once executed.

Requiring documented secure development standards and tools enforces use of safe code-generation APIs and escaping.

Engineering principles include secure input handling and neutralization requirements that structurally avoid static injection.

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.

PR.PS-06 mostly match
prevents

Secure SDLC practices directly require input neutralization to block static code injection into templates, configs, or libraries.

PR.DS-10 none match
prevents

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.

finds

Security testing in development and acceptance will detect static code injection but does not prevent it at the source.

prevents

Secure development life cycle mandates input validation and sanitization that directly prevents static code injection.

prevents

Application security requirements include rules for neutralizing untrusted input before it is stored in executable resources.

prevents

Secure architecture principles reduce injection surfaces but do not prescribe the specific neutralization techniques.

prevents

Secure coding explicitly requires proper neutralization of directives in templates, libraries and configuration files.

mitigates

Change management can catch unsafe code changes but does not enforce input neutralization.

References