CVERadar
HIGH · CVSS 3.1 8.8Exploit-DBEPSS 22.94% (p98)Threat level 58

CVE-2023-48292: CVE-2023-48292: The XWiki Admin Tools Application provides tools to help the administration of XWiki. Star…

xwiki · admin tools · NVD published 2023-11-21 · posted 2025-03-29 · last modified 2026-06-17

What it is

The XWiki Admin Tools Application provides tools to help the administration of XWiki. Starting in version 4.4 and prior to version 4.5.1, a cross site request forgery vulnerability in the admin tool for executing shell commands on the server allows an attacker to execute arbitrary shell commands by tricking an admin into loading the URL with the shell command. A very simple possibility for an attack are comments. When the attacker can leave a comment on any page in the wiki it is sufficient to include an image with an URL like `/xwiki/bin/view/Admin/RunShellCommand?command=touch%20/tmp/attacked` in the comment. When an admin views the comment, the file `/tmp/attacked` will be created on the server. The output of the command is also vulnerable to XWiki syntax injection which offers a simple way to execute Groovy in the context of the XWiki installation and thus an even easier way to compromise the integrity and confidentiality of the whole XWiki installation. This has been patched by adding a form token check in version 4.5.1 of the admin tools. Some workarounds are available. The patch can be applied manually to the affected wiki pages. Alternatively, the document `Admin.RunShellCommand` can also be deleted if the possibility to run shell commands isn't needed.

WeaknessCWE-352
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H (source: [email protected])
ATT&CK tacticsExecution

Exploitation evidence

First exploit evidence seen: 2025-03-29 (earliest date across the sources below).

Exploited in the wild

No source on this site lists in-the-wild exploitation yet (CISA KEV, VulnCheck KEV).

Public exploit code

Exploit-DB

  • EDB-52105: XWiki Standard 14.10 - Remote Code Execution (RCE) (2025-03-29)

Sources: Exploit-DB (OffSec).

Defend the Chain

The attack chain for CVE-2023-48292 laid across the MITRE ATT&CK Enterprise tactics. Solid cards come from the MITRE CTID KEV mappings; dashed cards are inferred by CVERadar from the CWE or description. Correct defences are real ATT&CK mitigations for that technique.

Threat level 58/100
Defender level 1 · 0 XP
Chain links broken: 0/1

Pick a red technique card on the board, then choose the defence that stops it.

Defend against T1204.001 Malicious Link Inferred

Inferred from CWE CWE-352

How to fix it

Fixed versions

  • xwiki admin tools: upgrade to 4.5.1 or later (affected from 4.4)

Derived from the NVD CPE configuration (versionEndExcluding / versionEndIncluding). Always confirm with the vendor advisory.

Vendor advisories and patches

MITRE ATT&CK mitigations for this chain

  • M1031 Network Intrusion Prevention (for T1204.001) : If a link is being visited by a user, network intrusion prevention systems and systems designed to scan and remove malicious downloads can be used to block activity.
  • M1017 User Training (for T1204.001) : Use user training as a way to bring awareness to common phishing and spearphishing techniques and how to raise suspicion for potentially malicious events.
  • M1021 Restrict Web-Based Content (for T1204.001) : If a link is being visited by a user, block unknown or unused files in transit by default that should not be downloaded or by policy from suspicious sites as a best practice to prevent some vectors, such as .scr, .exe, .pif, .cpl, etc. Some download scanning devices can open and analyze compressed and encrypted formats

Detection Generic guidance

  • Execution: Watch for the service process spawning shells or script interpreters (cmd.exe, powershell, sh, bash, python) via EDR process-tree rules.

Response checklist Generic guidance

  1. Inventory: find every instance of the affected product and version (include internet-facing and forgotten ones).
  2. Patch or mitigate per the vendor advisory; if you cannot patch, remove internet exposure or apply the vendor workaround.
  3. Assume compromise if the system was exposed before patching: hunt for the indicators in the advisory and review logs back to the disclosure date.
  4. Rotate credentials and secrets stored on or used by the affected system if compromise cannot be ruled out.

Sources