All posts
Unproven Execution

GuardFall: Regex Guardrails Don't Constrain Bash

Adversa AI defeated the destructive-command filters in 10 of 11 open-source AI coding agents by exploiting how bash rewrites the string it runs

Securityv0 Intelligence Team OWASP: ASI05 sv0 finding: unproven_execution
guardfall ai-coding-agent prompt-injection shell-injection agentic-execution adversa-ai

The Incident

On June 30, 2026, Adversa AI publicly disclosed GuardFall, a class of shell-injection bypasses that defeats the destructive-command filters shipped by ten of the eleven open-source AI coding and computer-use agents its researchers surveyed. No CVE has been assigned; GuardFall is a class-of-tool disclosure aimed at the guardrail pattern itself rather than any single project. The affected agents named in Adversa’s report and independently corroborated by industry coverage are Hermes, opencode, Goose, Cline, Roo-Code, Aider, Plandex, Open Interpreter, OpenHands, and SWE-agent. Continue was the sole surveyed tool judged to substantially mitigate the class, by parsing the tool call the way bash will before deciding what to allow and by maintaining a policy-owned block list of destructive commands.

The bypass is not a new bug in bash. It is the reappearance of decades-old shell-interpretation tricks against a new class of guard: the regex or text-match filter that agents apply to a tool call before handing the string to the shell. The trivial demonstration is r''m: a text-match filter looking for rm sees a different string, but bash removes the empty quotes at parse time and executes rm. Adversa’s report extends the pattern to $IFS expansion (rm$IFS-rf$IFS/), command substitution ($(echo rm) -rf /), base64-piped payloads, and alternate destructive binaries that bypass an allowlist tied to a specific command name. The delivery vector is a booby-trapped repository, dependency, or prompt-injected file that the developer asks their agent to read; the tool call it emits then evades the guardrail on its way to a shell that runs as the developer’s user. No in-the-wild exploitation has been publicly attributed to GuardFall as of publication.

MITRE ATT&CK coverage: T1059.004 (Unix Shell), T1027 (Obfuscated Files or Information), T1552.001 (Unsecured Credentials in Files).

The Authority Path That Failed

The identity carrying execution authority at the moment of failure is the AI coding agent’s process, running inside the developer’s local shell session with the developer’s user identity. The scope that identity holds is the full developer account — the process can read ~/.ssh, ~/.aws, ~/.config/gh, any token or credential on disk, and can write to any path the user can. The scope the deploying developer intended to exercise was constrained by the agent’s own destructive-command filter: “run bash, but block obviously destructive shapes.” The trust anchor that failed first is the mental model behind that filter. The filter reads the argument as a string and pattern-matches on its textual shape; bash reads the same argument after quote removal, $IFS expansion, and command substitution. Those are two different languages, and the developer’s operator trust was riding on the assumption that they were one.

That gap was flaggable in advance. Any tool that ships a text-match filter over a shell interpreter is structurally in the same position as pre-2000-era CGI input filters — an anti-pattern that the shell-injection literature has catalogued for thirty years. The authority to run arbitrary shell commands was granted by the framework, exercised by the LLM at attacker direction through prompt-injected input, and never surfaced to the operator who owned the deployment. Continue’s chosen mitigation is instructive precisely because it names the failure: read the command the way bash will before deciding, tokenize it, and refuse a hard-coded block list outright. That is not a stricter regex; it is a different execution model for the guardrail.

SecurityV0 Perspective

The SecurityV0 finding is unproven_execution. The finding applies wherever a developer or platform team has deployed a coding agent whose shell tool is gated by a textual filter — meaning the operator’s declared intent (“bash, but constrained”) has never been proven against the runtime that actually interprets what the agent emits. This is the same shape as our Langflow CSV Agent + Python REPL reference: a framework attaches a code-execution tool, the operator deploys it under the assumption that a documented guardrail meaningfully constrains that tool, and the guardrail is not what the operator was led to believe it was. The delivery vector is prompt injection from an untrusted repo or file, which is the scope_drift half of the story; the reason the injection succeeded is the guardrail, which is unproven_execution.

The evidence pack SecurityV0 would produce lists, per developer workstation and per repository engagement, which coding agent is attached, which shell tool is exposed, and whether the guardrail on that tool is a textual filter or a structural parser. Pre-incident, it answers: “which of our engineers is pointing an agent whose guardrail is a regex at a third-party repository right now, and how would you know?” Post-incident, it answers: “for the workstation that ran r''m -rf ~/.aws, which agent version, which repo prompt, and which tool call reached the shell?” The remediation the pack points to is not a patch bulletin — no vendor has been asked to ship one for this class — it is an operator-side change: swap in an agent whose guardrail structure matches bash’s parse tree, or scope the developer session down so the agent can’t reach the credentials that make the class dangerous.

What To Do

  • Treat any regex-gated shell tool in an AI coding agent as unproven execution. For every agent your developers run, name the shell tool it exposes and inspect the guardrail source. If the block list is a set of string or regex matches over the raw argument, it will not withstand $IFS, quote-stripping, or $(...) bypass; treat the tool as ungated and re-scope accordingly.
  • Prefer agents that parse before they filter. Continue’s approach — tokenize the argument the way bash will, then apply a hard block list against the resolved command — is the load-bearing pattern. When evaluating an agent for adoption, ask the vendor which shell parser their guardrail uses and require an answer.
  • Scope developer sessions so the agent cannot reach shared credentials. Run coding agents against a shell whose environment does not carry cloud CLIs, long-lived API tokens, or SSH agent forwarding. If GuardFall succeeds, the exercised scope is bounded by the credentials the agent’s process can actually reach.
  • Isolate the agent’s working tree from untrusted content. Prompt-injection payloads arrive through code, dependencies, and text files the developer asks the agent to read. Run agent sessions against untrusted repositories inside a container or ephemeral VM whose network egress and secret store are explicitly enumerated, not inside the developer’s home directory.
  • Collect the tool-call log per agent session and diff it against declared intent. The pre-incident question is which agent tools were called during which session; the post-incident question is which of those tool calls resolved to a command the developer’s guardrail was never designed to constrain. Neither answer exists if the agent runtime does not log tool-call arguments; require it.

Sources

All posts