Prompt Injection leads to RCE and Sandbox Escape in Antigravity

Executive Summary

Pillar Security researchers have uncovered a vulnerability in Antigravity, Google's agentic IDE. This technique exploits insufficient input sanitization of the find_by_name tool's Pattern parameter, allowing attackers to inject command-line flags into the underlying fd utility, converting a file search operation into arbitrary code execution.

Critically, this vulnerability bypasses Antigravity's Secure Mode, the product's most restrictive security configuration. Secure Mode is designed to restrict network access, prevent out-of-workspace writes, and ensure all command operations run strictly under a sandbox context. None of these controls prevent exploitation, because the find_by_name tool call fires before any of these restrictions are evaluated. The agent treats it as a native tool invocation, not a shell command, so it never reaches the security boundary that Secure Mode enforces.

By injecting the -X (exec-batch) flag through the Pattern parameter, an attacker can force fd to execute arbitrary binaries against workspace files. Combined with Antigravity's ability to create files as a permitted action, this enables a full attack chain: stage a malicious script, then trigger it through a seemingly legitimate search, all without additional user interaction once the prompt injection lands.

This finding reinforces a pattern we continue to see across agentic IDEs: native tools designed for constrained operations can be weaponized when their parameters are not strictly validated.

Background: Antigravity's Tool Model

Antigravity is an agentic IDE that provides developers with native tools for filesystem operations. Among these is find_by_name, a tool that searches for files and directories using fd (a fast alternative to find). According to Antigravity's documentation, this tool "searches for files/directories using fd (smart case, respects .gitignore)."

When invoked, the tool accepts the following JSON schema:

The Pattern parameter is intended to accept a filename search pattern. In practice, it is passed directly to the underlying fd command without validation or argument termination.

Why Secure Mode Doesn't Help

Antigravity offers a Secure Mode that represents the strictest security posture available to users. When enabled, it restricts network access, prevents writes outside the working directory, and ensures all command operations are sandboxed.

However, find_by_name is classified as a native tool, not a shell command. This distinction is critical: native tool invocations are executed by the agent directly, before Secure Mode's command-level restrictions are evaluated. The security boundary that Secure Mode enforces simply never sees this call.

This means an attacker achieves arbitrary code execution under the exact configuration a security-conscious user would rely on to prevent it.

The Core Vulnerability

The Pattern parameter is vulnerable to direct command injection. Because the value is interpolated into the fd command line without sanitization, any string beginning with - is interpreted as a flag rather than a search pattern.

The critical flag here is -X (exec-batch). When passed to fd, this flag executes a specified binary against each matched file. By crafting a Pattern value of -Xsh, an attacker causes fd to pass matched files to sh for execution as shell scripts.

A limitation exists: spaces within the injected command string are treated as string literals, preventing direct argument passing to the -X flag. However, this constraint is bypassed because Antigravity can create files in the workspace without restrictions. File creation and file search are both permitted actions within the tool's normal operation. The attacker simply stages the payload as a file first, then triggers it through the search.

Root Cause

The root cause is twofold:

1. No input validation: The Pattern parameter accepts arbitrary strings without verifying they contain only legitimate search pattern characters.‍
2. No argument termination: The -- separator is not prepended before user-supplied values, so fd cannot distinguish between flags and search terms.

Proof of Concept

We issue a simple prompt injection to prove exploitation.

Result: Calculator launches. The search tool became an execution engine.

This was tested and confirmed with Secure Mode enabled and Auto Execution disabled, the most restrictive configuration available.

Indirect Prompt Injection

The same behavior can be triggered via indirect prompt injection without any prior compromise of the user's account. A user pulls a benign-looking source file from an untrusted origin, such as a public repository, containing attacker-controlled comments that instruct the agent to stage and trigger the exploit.

At no point does the attacker control the user's account or directly interact with the system. The injected instructions are processed as part of normal content ingestion. Antigravity follows the embedded directions, resulting in the same arbitrary code execution.

Disclosure Timeline

Jan 7, 2026 - Initial report submitted to Google via AI VRP with direct prompt injection PoC.

Jan 7, 2026 - Google acknowledges receipt.

Jan 24, 2026 - Google accepts the report and files an internal bug with the product team.

Feb 28, 2026 - Google marks the issue as fixed.

Mar 26, 2026 - VRP panel awards a bounty.

Conclusion

As we documented in our earlier research on Cursor (CVE-2026-22708), the pattern repeats across agentic IDEs: tools designed for constrained operations become attack vectors when their inputs are not strictly validated. The trust model underpinning security assumptions, that a human will catch something suspicious, does not hold when autonomous agents follow instructions from external content.

The fact that this exploit bypasses Secure Mode underscores a deeper issue: security controls that gate shell commands are insufficient when native tool invocations can achieve the same effect outside the control boundary. The industry must move beyond sanitization-based controls toward execution isolation. Every native tool parameter that reaches a shell command is a potential injection point. Auditing for this class of vulnerability is no longer optional, and it is a prerequisite for shipping agentic features safely.

‍