GHSA-4HMJ-39M8-JWC7: ANSI Escape Sequence Injection in OpenClaw ACP Prompts

OpenClaw is an AI assistant framework that integrates various tools through the Assistant Control Protocol (ACP). When an LLM or an external agent requests execution of a privileged tool, the framework halts execution and prompts the human user for authorization via the terminal interface. This interaction relies on presenting the tool's requested action, parameters, and metadata clearly to ensure informed consent before execution proceeds.

Vulnerability GHSA-4HMJ-39M8-JWC7 represents a failure in how this terminal interface sanitizes untrusted input originating from the LLM or compromised external tools. Specifically, the framework fails to properly neutralize ANSI escape sequences (CWE-150 and CWE-116) embedded within the tool's metadata, such as the tool title or execution arguments.

By injecting specialized Control Sequence Introducer (CSI) codes, an attacker can manipulate the terminal output layout, overwriting the legitimate security prompt with deceptive text. This bypasses the intended human-in-the-loop security boundary, leading to authorized execution of malicious payloads under false pretenses. The vulnerability compromises the primary defense mechanism preventing autonomous execution of destructive actions by the AI agent.

Terminal emulators interpret specific byte sequences as out-of-band commands to manipulate the display, rather than as printable characters. These sequences, standardized under ANSI X3.64, include Control Sequence Introducer (CSI) commands which dictate cursor movement, line erasure, and text formatting. The OpenClaw framework handles tool metadata, which is fundamentally untrusted data generated by the LLM or an external tool, and prints it directly to standard output during the authorization flow.

Prior to version 2026.3.26, OpenClaw attempted to sanitize this output using a restrictive regular expression: \x1b\[[0-9;]*m. This pattern strictly targets Select Graphic Rendition (SGR) sequences, which are exclusively used for altering text attributes such as color and weight. It fails to account for the broader spectrum of CSI sequences ending in different command bytes, such as A (Cursor Up), B (Cursor Down), or K (Erase In Line).

Because the sanitization logic allowed non-SGR sequences to pass through unaltered, terminal emulators receiving the output executed the embedded spatial manipulation commands. The terminal effectively trusts the data stream to define its visual state. This discrepancy between the sanitization pattern's limited scope and the terminal emulator's extensive execution capabilities constitutes the root cause of the UI redressing vulnerability.

The vulnerability resided primarily in the modules responsible for generating the terminal prompts, specifically where the tool title was interpolated into the output stream. The original implementation naively stripped only SGR sequences, leaving the application exposed to terminal manipulation attacks.

The patch, introduced in commit 464e2c10a5edceb380d815adb6ff56e1a4c50f60, comprehensively addresses this by replacing the targeted SGR regex with a broader CSI stripping pattern. The updated pattern accurately matches the structural definition of a CSI sequence: the ESC [ introducer, followed by any number of parameter or intermediate bytes, and terminated by a final command byte.

Additionally, the patch introduces a dedicated sanitization function within the terminal utilities module. This function applies the expanded regex alongside logic to strip Operating System Command (OSC) sequences, which could otherwise be abused to spoof hyperlinks or alter terminal window titles. Finally, it implements controls to neutralize basic inline control characters like carriage returns.

// Original vulnerable implementation (conceptual)
// Only stripped colors: const SANITIZED = input.replace(/\x1b\[[0-9;]*m/g, '');
 
// Patched implementation in src/terminal/safe-text.ts
const ANSI_CSI_PATTERN = "\\x1b\\[[\\x20-\\x3f]*[\\x40-\\x7e]";
const ANSI_OSC_PATTERN = "\\x1b\\](?:[0-8]|1[0-1]);[^\\x07\\x1b]*(?:\\x07|\\x1b\\\\)";
 
export function sanitizeTerminalText(input: string): string {
  let text = input.replace(new RegExp(ANSI_CSI_PATTERN, 'g'), '');
  text = text.replace(new RegExp(ANSI_OSC_PATTERN, 'g'), '');
  return escapeInlineControlChars(text);
}
 
// Applied in src/acp/client.ts
const toolTitle = sanitizeTerminalText(params.toolCall?.title ?? "tool");

Exploitation requires the attacker to influence the metadata of a tool called by the OpenClaw assistant. This is typically achieved via a malicious prompt injection that instructs the LLM to invoke a specific, highly privileged tool while overriding the tool's display title or arguments with a crafted string containing ANSI sequences.

The attacker constructs a payload utilizing sequences like \x1b[1A (Cursor Up) and \x1b[2K (Erase Entire Line). A functional payload string takes the form: exec: \x1b[2K\x1b[1A\x1b[2K[permission] Allow 'search' for more info? (y/N). When the framework attempts to render the legitimate prompt requesting execution permission, the terminal evaluates the injected sequences sequentially.

The terminal first prints the legitimate prefix, but upon encountering the injected payload, it erases the current line, moves the cursor up to the preceding line, erases that line as well, and finally prints the deceptive text. The resulting visual state completely obscures the destructive command, presenting the user with a benign-looking authorization request that fundamentally misrepresents the pending action.

The direct impact of this vulnerability is the compromise of the human-in-the-loop security model, which serves as the primary defense against autonomous execution of destructive actions by the AI agent. By reliably deceiving the user into approving malicious tool invocations, the attacker achieves the equivalent of unauthenticated execution of arbitrary tools within the context of the OpenClaw environment.

If the OpenClaw instance is configured with access to high-privilege tools—such as direct shell execution, file system manipulation, or cloud resource provisioning—the vulnerability escalates immediately to arbitrary local code execution. The attacker assumes the privileges of the system user running the OpenClaw terminal application. This mechanism circumvents all software-level safety rails placed on the LLM.

This vulnerability highlights the severe risks of trusting terminal interfaces as security boundaries when handling complex, attacker-influenced input streams. The lack of standard, built-in sanitization routines in many terminal environments forces application developers to implement complex output encoding logic, often resulting in UI redressing bypasses when implemented incorrectly.

The primary remediation is to upgrade the openclaw package to version 2026.3.26 or later. This release contains the finalized sanitization implementation, which correctly identifies and strips the full range of CSI and OSC sequences. Upgrading immediately neutralizes the UI redressing vector and restores the integrity of the terminal-based authorization prompts.

For deployments where immediate patching is not feasible, administrators can pipe the output of the OpenClaw CLI process through external sanitization tools configured to strip ANSI sequences entirely. While this approach prevents the exploitation of terminal escape sequences, it degrades the user experience by removing intended syntax highlighting and interface formatting. System administrators must evaluate this trade-off based on the deployment environment.

Developers building custom terminal applications that interact with LLMs must adopt strict output encoding practices. Any string originating from an external source, including LLM outputs and tool metadata, must be sanitized against a comprehensive list of terminal control sequences before being emitted to standard output or standard error streams. Relying solely on removing color codes is insufficient for preserving the integrity of the terminal UI.