OpenClaw GHSA-3xfw-4pmr-4xc5: safeBins grep File Read Bypass Explained

OpenClaw Security Advisory GHSA-3xfw-4pmr-4xc5 — GitHub Security Advisory: OpenClaw GHSA-3xfw-4pmr-4xc5 - safeBins grep File Read Bypass

Introduction

On February 21, 2026, a moderate-severity security advisory was published for OpenClaw, an open-source tool available on npm, disclosing a file read bypass vulnerability in its tools.exec.safeBins configuration when grep is enabled. Tracked as GHSA-3xfw-4pmr-4xc5, this vulnerability demonstrates a subtle but significant class of security flaw: the incomplete deny-list bypass. Specifically, the flaw allows an attacker with permission to invoke execution tools to read arbitrary files from the working directory -including sensitive files like .env, private keys, or credential stores -in contexts that were designed to be strictly limited to standard input processing.

This write-up provides a thorough technical analysis of the vulnerability, walks through how it can be exploited, examines its root cause, reviews the fix, and discusses broader lessons for developers building AI-adjacent tools that offer sandboxed command execution.

What is OpenClaw?

OpenClaw is an npm package designed to provide AI agents and automated tooling with a structured, safe interface for executing shell commands. One of its core security abstractions is the tools.exec.safeBins configuration -a curated allowlist of binaries that the tool permits agents to run. The underlying philosophy is straightforward: rather than giving an AI agent unrestricted shell access, operators define a narrow set of trusted executables (the "safe bins") and restrict how those executables can be invoked.

By design, certain tools in the safeBins list are intended to operate exclusively on piped standard input (stdin), never on files from the filesystem. This constraint matters enormously in security-sensitive deployments where an agent might be processing untrusted data streams, log files, or external API responses. Allowing such an agent to read arbitrary files from disk would violate the principle of least privilege and could expose sensitive configuration data to a compromised or malicious prompt injection.

The grep utility is a natural candidate for inclusion in such a list -it is ubiquitous, powerful for text filtering, and commonly needed for log analysis or output filtering tasks. It is also, as this advisory reveals, surprisingly dangerous when added to safeBins without additional constraints on how it accepts its arguments.

The Vulnerability: CWE-184 Incomplete List of Disallowed Inputs

At its core, GHSA-3xfw-4pmr-4xc5 is a manifestation of CWE-184: Incomplete List of Disallowed Inputs. This CWE describes situations where a security control attempts to block malicious input by maintaining a list of known-bad patterns or arguments, but the list is incomplete -leaving alternative attack paths open.

In OpenClaw's case, the safeBins policy for grep was designed to prevent file-based reads by restricting how the binary could be called. However, the restriction failed to account for the full combinatorial space of valid grep argument arrangements. Specifically, the policy did not adequately handle the case where the -e flag is used to supply the search pattern as an inline option argument rather than as a standalone positional operand.

Understanding why this matters requires a brief look at how grep parses its arguments.

Technical Deep Dive: The -e Flag Exploitation

Under normal circumstances, grep accepts its pattern as the first positional argument, followed optionally by one or more filenames:

grep PATTERN [FILE...]

When no file is supplied, grep reads from standard input. This is the behavior OpenClaw's safeBins policy intended to enforce -grep should only process what is piped into it, never touch the filesystem.

However, grep also supports the -e flag, which allows the pattern to be supplied as a named option argument rather than a positional argument:

grep -e PATTERN [FILE...]

Crucially, when -e PATTERN is used, the pattern is "consumed" as the argument to the -e flag. This frees up the positional argument slot that grep would normally use for the pattern. From grep's perspective, after processing -e SECRET, it has received its pattern -so any remaining positional argument is treated as a filename to read from. The following command is therefore entirely valid:

grep -e SECRET .env

Here, SECRET is the search pattern (passed via -e), and .env is the file to search in. If OpenClaw's policy only checked whether a filename appeared as the first positional argument after the binary name, an invocation structured this way would slip through undetected -and grep would happily read and output lines from .env that contain the word "SECRET".

This technique is both simple and effective. It does not require any special privileges, unusual shell features, or exotic system configurations. Any actor with permission to invoke execution tools in OpenClaw -including an LLM agent operating autonomously -could use this one-liner to exfiltrate the contents of sensitive files from the working directory.

Affected Versions and Prerequisites

The vulnerability affects all versions of OpenClaw up to and including 2026.2.19-2. The fix was introduced in version 2026.2.21, released on the same day the advisory was published.

Exploitation requires two conditions to be met:

grep must be explicitly enabled in safeBins. It is not part of the default configuration. Operators who have not manually added grep to their safeBins list are not affected.
The actor must have permission to invoke execution tools. This means the vulnerability is only reachable if an agent or user has been granted the ability to run commands via OpenClaw's execution interface.

While these prerequisites limit the scope of affected deployments, they are not particularly restrictive in practice. Grep is one of the most commonly added utilities to any text-processing toolset, and in agentic AI pipelines, execution tools are often the primary mechanism through which an agent interacts with the system.

Impact: What Can Be Read?

An attacker successfully exploiting this vulnerability can read any file accessible to the process running OpenClaw that exists within or is path-accessible from the working directory. In typical deployment scenarios, this includes:

.env files -containing API keys, database credentials, third-party service tokens, and environment-specific configuration secrets.
Private key files -SSH keys, TLS certificates, or application signing keys left in the project directory.
Configuration files -config.json, settings.yaml, or application-specific configuration files that may embed connection strings or secrets.
Source code -if the attacker wishes to exfiltrate business logic, proprietary algorithms, or hardcoded credentials scattered throughout the codebase.
Log files -which may contain sensitive runtime data, user information, or authentication tokens.

In the context of modern AI-powered development tools, this type of file read bypass is especially dangerous. AI agents are increasingly being given the ability to autonomously execute commands, read and write code, and manage project environments. A compromised agent -or one operating under a prompt injection attack -could silently exfiltrate the entire secrets surface of a project through a single, innocuous-looking grep invocation.

The Fix: Commit c6ee14d

The vulnerability was addressed in commit c6ee14d60e4cbd6a82f9b2d74ebeb1e8ee814964, which was included in the 2026.2.21 release. While the full patch details are available in the repository's commit history, the fix falls into the category of input validation hardening -specifically, improving how OpenClaw parses and validates the argument structure of commands passed to safeBins executables.

A robust fix for this class of vulnerability requires moving beyond simple positional argument inspection. The correct approach is to fully parse the argument vector according to the target binary's option grammar, identify all non-option positional arguments (which correspond to files in grep's case), and reject any invocation where such arguments are present. This must be done regardless of whether the pattern is supplied positionally or via a named flag like -e, -f, or --regexp.

For grep specifically, any of the following flag forms supply the pattern as a named option, freeing the positional slot for a filename:

grep -e PATTERN FILE
grep --regexp=PATTERN FILE
grep -f PATTERN_FILE FILE

A comprehensive policy must account for all of these forms, ideally by using a proper argument parser rather than ad-hoc string matching.

Broader Lessons: The Perils of Deny-List Security in Shell Contexts

This vulnerability highlights a fundamental tension in tool sandboxing: deny-list approaches are inherently brittle when applied to tools with rich, flag-heavy command-line interfaces. Unix utilities like grep, awk, sed, find, curl, and others were designed for maximum flexibility -not for use in constrained security contexts. They support dozens of flags, multiple input modes, and complex interaction between options that can radically change their behavior.

When a security control attempts to restrict a binary by blocking specific argument patterns, it implicitly takes on the maintenance burden of tracking every flag combination that could violate the intended behavior. This is an extremely difficult property to guarantee, especially as tool versions change and new flags are added upstream.

A more defensive approach is to use allowlists of explicit, safe invocation patterns rather than trying to block unsafe ones. Instead of saying "grep is allowed, but not grep with file arguments," a stronger policy says "only grep -i PATTERN and grep -n PATTERN without any additional positional arguments are allowed." This shifts the burden from enumerating unsafe patterns (unbounded) to defining safe ones (bounded).

Alternatively, tools that require stdin-only semantics should be invoked in an environment where filesystem access is architecturally impossible -for example, via a container with no mounted volumes, or a restricted execution context using namespaces or seccomp filters.

Timeline and Disclosure

Reporter: @athuljayaram
Advisory Published: February 21, 2026
Affected Versions: ≤ 2026.2.19-2
Fixed Version: 2026.2.21
Fix Commit: c6ee14d
Severity: Moderate
CWE: CWE-184 -Incomplete List of Disallowed Inputs

Credit for discovering and responsibly disclosing this vulnerability goes to @athuljayaram. Responsible disclosure of tool-level security issues in open-source AI infrastructure projects is critically important as this ecosystem matures, and the community owes a debt of gratitude to researchers who take the time to investigate and report these issues through proper channels.

Recommendations

If you are using OpenClaw in your project or AI agent infrastructure, take the following steps immediately:

Upgrade to version 2026.2.21 or later. This is the most important action. Run npm update openclaw or update your package.json dependency and reinstall.
Audit your safeBins configuration. Review every binary you have added to safeBins and consider whether its full argument surface has been properly restricted. Pay particular attention to utilities that support multiple input modes (file vs. stdin).
Apply defense in depth. Even after patching, consider running OpenClaw in a sandboxed environment with restricted filesystem access so that a future bypass of this type has limited impact.
Monitor execution logs. If you have logging enabled for tool invocations, review recent logs for any suspicious use of the -e flag in grep invocations, particularly those targeting files rather than stdin.
Treat AI agents as untrusted principals. Any agent that can invoke execution tools should be treated with the same level of skepticism as a remote API caller. Apply the principle of least privilege to agent tool permissions.

Conclusion

GHSA-3xfw-4pmr-4xc5 is a textbook example of why security sandbox designs must account for the full argument grammar of any tool they permit, not just its most common use patterns. The -e flag bypass in grep is not an exotic or obscure technique -it is standard behavior documented in every grep man page. The vulnerability exists not because grep did something unexpected, but because the security policy around it made an assumption that the tool's argument structure did not guarantee.

As AI agents gain more autonomy and are given access to increasingly powerful execution primitives, the correctness of tool sandboxing mechanisms becomes ever more critical. A single bypass in a safeBins policy can be the difference between an agent safely processing a data stream and silently exfiltrating the entire secrets surface of a production environment.

The OpenClaw team acted swiftly to address this issue, releasing a fix the same day the advisory was published. Users are strongly encouraged to upgrade immediately and take this opportunity to audit their broader tool configuration for similar classes of issues.

Advisory reference: GHSA-3xfw-4pmr-4xc5 | Reporter: @athuljayaram