The vulnerability is a classic command injection flaw within the execution workspace lifecycle of Paperclip AI. The root cause is a lack of input validation on the cleanupCommand field, which can be set by a user via a PATCH request to the /api/execution-workspaces/:id endpoint. The analysis of the commits between the vulnerable version (v2026.403.0) and the patched version (v2026.416.0) confirms this. The patch adds crucial authorization checks in the PATCH handler within server/src/routes/execution-workspaces.ts to ensure that only administrative users can modify the cleanupCommand. The exploitation occurs in two stages: first, the injection of the malicious command, and second, the execution. The execution is triggered when the workspace is archived, which calls the cleanupExecutionWorkspaceArtifacts function in server/src/services/workspace-runtime.ts. This function, in turn, calls recordWorkspaceCommandOperation, which unsafely uses child_process.spawn with a shell to execute the stored command. All three of these functions are critical to the vulnerability and would appear in a runtime profile during exploitation.
This function is the main entry point for the vulnerability. It handles the PATCH request to update an execution workspace's configuration. Before the patch, it lacked proper validation and authorization for the 'cleanupCommand' field, allowing an attacker to inject and persist a malicious OS command in the workspace's metadata.
cleanupExecutionWorkspaceArtifacts
server/src/services/workspace-runtime.ts
This function is triggered when a workspace's status is set to 'archived'. It retrieves the malicious 'cleanupCommand' that was previously injected and passes it to 'recordWorkspaceCommandOperation' for execution, which ultimately leads to remote code execution.
recordWorkspaceCommandOperation
server/src/services/workspace-operations.ts
This function is the final step in the exploit chain. It receives the untrusted command from 'cleanupExecutionWorkspaceArtifacts' and executes it using 'child_process.spawn' with shell execution enabled ('-c'). This direct execution of an unvalidated, user-provided command is the core of the command injection vulnerability.
Any user with company access can exploit this vulnerability. The assertCompanyAccess check occurs AFTER the database query (BOLA/IDOR pattern), and no additional authorization is required to modify workspace config fields.
Proof of Concept — 3 Independent RCE Proofs (Windows 11)
All proofs executed via the automated PoC script poc_paperclip_rce.py.
+================================================+
| VULNERABLE - Arbitrary Code Execution! |
| cleanupCommand was executed on the server |
+================================================+
Proof file: %TEMP%\rce-proof-595c04f7.txt
Content: RCE_PROOF_595c04f7
Platform: Windows 11
Proof 2: System Command Execution (Data Exfiltration)
+================================================+
| System command output captured! |
+================================================+
Host Name: [REDACTED]
OS Name: Microsoft Windows 11 Home
OS Version: 10.0.26200 N/A Build 26200
OS Manufacturer: Microsoft Corporation
Registered Owner: [REDACTED]
Product ID: [REDACTED]
System Manufacturer: [REDACTED]
System Model: [REDACTED]
System Type: x64-based PC
... (72 total lines of system information)
Proof 3: GUI Application Launch (calc.exe)
Payload:calc.exe
Result:
+================================================+
| calc.exe launched! Check your taskbar. |
| This is server-side code execution. |
+================================================+
Windows Calculator was launched on the host system by the Paperclip server process.
Impact Assessment
| Impact | Description |
|--------|-------------|
| Remote Code Execution | Arbitrary commands execute as the Paperclip server process |
| Data Exfiltration | Full system info, environment variables, files readable by server process |
| Lateral Movement | Attacker can install tools, pivot to internal network |
| Supply Chain | Workspaces contain source code — attacker can inject backdoors into repositories |
| Persistence | Attacker can create scheduled tasks, install reverse shells |
| Privilege Escalation | Server may run with elevated privileges; attacker inherits them |
Attack Scenarios
Desktop user (local_trusted): Any process or malicious web page making local HTTP requests to 127.0.0.1:3100 can achieve RCE with zero authentication
Team deployment (authenticated): Any employee with Paperclip access can compromise the server and all repositories managed by it
Chained attack: Combine with SSRF or DNS rebinding to attack Paperclip instances from the network
Remediation Recommendations
Immediate (Critical)
Input validation: Reject or sanitize cleanupCommand and teardownCommand fields in the PATCH handler. Do not allow user-supplied values to be passed to shell execution.
Command allowlisting: If custom cleanup commands are needed, implement a strict allowlist of permitted commands (e.g., git clean, rm -rf <workspace_dir>).
Use execFile instead of spawn with shell: Replace spawn(shell, ["-c", command]) with execFile() using an argument array, which prevents shell metacharacter injection.
Short-term
Authorization check: Add proper authorization checks BEFORE processing the PATCH request. Validate that the user has explicit permission to modify workspace configuration.
Separate config fields: Do not allow the same endpoint to update both workspace status and security-sensitive configuration fields like commands.
Long-term
Sandboxed execution: Run cleanup commands in a sandboxed environment (container, VM) with minimal privileges.
Audit logging: Log all modifications to command fields for forensic analysis.
Security review: Audit all spawn, exec, and execFile calls across the codebase for similar injection patterns.