Arbitrary directory deletion via attacker-controlled `decompiledSrcPath` input.

[monperrus]

Confirmed vulnerability: If an attacker can control the decompiledSrcPath argument to JarLauncher, they can cause the application to recursively delete any directory on the filesystem that is writable by the process. This is due to the call to FileUtils.deleteDirectory(decompiledRoot) (lines 83-91) without any path sanitization or restriction. There are no checks for symlinks, traversal, or safe directory boundaries. This allows for unintended and unsafe filesystem effects, including deletion of arbitrary directories.

Highest-risk effect: Arbitrary directory deletion via attacker-controlled decompiledSrcPath input.

** 🤖💪 Deploying Task Flow Agent(s): ['seclab_taskflows.personalities.web_application_security_expert']
** 🤖💪 Task ID: 2a2602e1-7e58-49a9-9d12-8e0fdb4cf44e
** 🤖💪 Model : openai/gpt-4.1
[03/31/26 15:59:41] INFO Starting MCP server 'Memcache' with transport 'stdio' server.py:2491

** 🤖🛠️ Tool Call: 7ff9e676e031memcache_get_state
Hypothesis checked:

• Potential for arbitrary directory deletion if attacker controls decompiledSrcPath input to JarLauncher.

Implementation paths inspected:

• JarLauncher.java: constructor and logic around jarPath and decompiledSrcPath (lines ~32, 41, 50, 59, 70, 74-80, 83-101, 117-124).
• FileUtils.deleteDirectory usage on decompiledRoot if decompile=true and directory exists.
• No path sanitization or restriction on decompiledSrcPath.

Concrete finding:

• If decompiledSrcPath is attacker-controlled, FileUtils.deleteDirectory will recursively delete any directory specified by the attacker, with no checks for symlinks or path traversal. This confirms a concrete vulnerability: arbitrary directory deletion.

[monperrus]

@copilot fix and add a test please.

[copilot-swe-agent]

The agent encountered an error and was unable to start working on this issue: Please try again later, or contact support if the problem persists. (Request id: 9AA2:9BC6:CEB5B0:88B757:69CBE0D7)

[monperrus]

@copilot try again

[I-Al-Istannen]

What is the threat model you have in mind here? If the user can control arbitrary spoon parameters, things very likely aren't safe. I think the threat model for spoon would be analyzing malicious code, not having malicious code configure spoon?

How would you even constrain the deletion? There is no general "spoon root" (and if there was, the attacker could change it as well). If you want to clean up generated decompiled sources, spoon needs to issue a delete. Not following symbolic links during deletion would be good, I am not sure if spoon already does it. I would expect apache commons FileUtils to do this correctly?