Raw vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:LSummary
CVE-2022-36097 is a high-severity Cross-site Scripting (CWE-79) vulnerability in Xwiki Xwiki. Its CVSS base score is 8.9 (High).
Operationally, ranked in the top 1% 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-15 (Information Output Filtering) — 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 Attachment UI, a component of the generic wiki platform XWiki, contains a stored cross-site scripting vulnerability. Versions from 14.0-rc-1 up to but not including 14.4-rc-1 allow JavaScript to be persisted in an attachment filename; the script executes in the browser of any user who later attempts to move that attachment. The flaw is tracked under CWE-79 and CWE-80 and carries a CVSS 3.1 score of 8.9.
An authenticated user with attachment-creation privileges can upload a file whose name contains executable script. When another user with move rights opens the move dialog for that attachment, the script runs with the victim’s session privileges, enabling theft of sensitive data, account takeover, or other actions within the wiki’s security context.
The project’s security advisory and the associated patch commit state that the issue is fixed in XWiki 14.4-rc-1. Administrators unable to upgrade immediately are advised to copy the template moveStep1.vm into the web application directory and replace the vulnerable code with the version supplied in the patch.
EPSS for the CVE rose from a low baseline after disclosure to a peak of 0.4419 on 2025-12-11 before receding to the current value of 0.2183, indicating a clear increase in observed exploitation interest well after the original publication date.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2022-6764
Vulnerability Data
XWiki Platform Attachment UI provides a macro to easily upload and select attachments for XWiki Platform, a generic wiki platform. Starting with version 14.0-rc-1 and prior to 14.4-rc-1, it's possible to store JavaScript in an attachment name, which will be…
more
executed by anyone trying to move the corresponding attachment. This issue has been patched in XWiki 14.4-rc-1. As a workaround, one may copy `moveStep1.vm` to `webapp/xwiki/templates/moveStep1.vm` and replace vulnerable code with code from the patch.
- 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
Rejects or sanitizes attachment filenames containing script before they are stored or rendered in the move dialog.
Filters or escapes filenames on output so that JavaScript embedded in an attachment name cannot execute in any user's browser.
Requires prompt application of the vendor patch (or the documented moveStep1.vm template fix) that eliminates the unsanitized filename rendering.
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 target introduction of XSS via coding standards/testing (mostly), yet the single broad outcome leaves many specific neutralization vectors unaddressed (partial).
Patching and EOL replacement can remediate known XSS instances in libraries or frameworks (partial) but do nothing to enforce input neutralization in application code (none).
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.
Secure-coding testing and automated code-analysis tools are applied to detect improper neutralization of script-related content during web-page generation.
Knowledge exchange on emerging attack techniques and patches reduces the likelihood that cross-site scripting flaws remain unaddressed in deployed applications.
Operational indicators of compromise for web-application attacks can be incorporated into WAF or input-filtering rules, lowering the likelihood that unsanitized data reaches the browser.
Requiring language-specific secure-coding standards and automated scanning during the SDLC catches missing output encoding or improper neutralization of untrusted data before the software reaches production.
Application security requirements explicitly call for neutralization of script-related HTML tags.
Secure-coding standards, SAST scans and removal of insecure code samples together eliminate the failure to neutralize script content that produces cross-site scripting flaws.