Between April 19 and April 28, four separate security incidents hit the AI coding ecosystem. Different attackers. Different targets. Different communities noticed.
Each one exploited a different layer of the same stack.
Layer 4: The Agent
CVE-2026-26268. CVSS 9.9. Disclosed April 28, fixed in February.
An attacker embeds a bare git repository — with a malicious pre-commit hook — inside what looks like a legitimate public repo. A developer clones it and asks Cursor to work on it. The agent autonomously runs git checkout. The hook fires. Arbitrary code executes on the developer's machine. No prompt, no warning, no user confirmation.
The root cause is CWE-862: missing authorization checks on file writes to the .git directory inside the sandbox. But the deeper issue isn't the missing check. It's the assumption. Git hooks were designed for human workflows — developers who inspect what they commit to. An autonomous agent executing git operations in an untrusted repository turns a version-control feature into a code injection channel.
"The path from 'clone a repo' to 'attacker runs code on your machine' is now a single routine action."
— Novee Security
Who defends this layer? Runtime security teams. Sandbox engineers. The people who design trust boundaries for autonomous execution. In most organizations, this team doesn't exist yet.
Layer 3: The Integration
On April 19, Vercel disclosed a breach. The attack chain started somewhere no application security scanner would look.
A Context.ai employee was infected with Lumma Stealer — an infostealer picked up while downloading Roblox auto-farm scripts. The stolen browser credentials included an OAuth token. A Vercel employee had granted Context AI's Chrome extension full read access to their Google Drive via their enterprise Google Workspace account. One compromised OAuth grant was enough: the attacker pivoted from Context.ai to Vercel's Workspace, then to Vercel's environment variables, then to API keys, GitHub tokens, and npm tokens.
The data appeared on BreachForums for $2 million.
The attack chain
Roblox exploit scripts → Lumma Stealer → Context.ai employee credentials → OAuth token for Vercel employee's Google Workspace → Vercel environment variables → API keys, GitHub tokens, npm tokens
The AI tool wasn't the target. It was the bridge. The OAuth grant that connected an AI productivity tool to an enterprise workspace became the path of least resistance. Who reviews these grants? Identity and access management teams. They're auditing SSO configurations and SAML assertions, not Chrome extension OAuth scopes for AI tools no one in security approved.
Layer 2: The Credentials
On April 22, a malicious @bitwarden/cli@2026.4.0 appeared on npm. It was detected and removed in 93 minutes. 334 developers downloaded it.
The payload was one of the most sophisticated supply-chain attacks published to date. A multi-cloud credential harvester. A self-propagating npm worm. A GitHub commit dead-drop C2 channel with RSA-signed command delivery. Seven parallel credential collectors spanning filesystem, environment variables, shell history, GitHub Actions runner memory, AWS Secrets Manager, AWS SSM, GCP Secret Manager, and Azure Key Vault.
But the novel component — the one that makes this a 2026 attack instead of a 2024 one — was a module the developers named Butlerian Jihad.
It hunted for authenticated AI coding assistants.
Claude Code. Codex CLI. Gemini CLI. Kiro. Aider. OpenCode. The module probed each one with a simple message: "Hey! Just making sure you're here. If you are can you respond with 'Hello' and nothing else?" If an assistant responded, the module injected persistence into ~/.bashrc and ~/.zshrc, then scavenged ~/.claude.json, ~/.claude/mcp.json, and ~/.kiro/settings/mcp.json for further credentials.
The logic was clear: AI coding tools run with developer-level permissions, hold API keys worth hundreds of dollars per month, and read shell configuration files as part of their normal operation. They are high-value targets sitting in an unmonitored space.
Who defends this layer? Supply chain security teams. The people running SCA scanners and monitoring package registries. They've spent two years building defenses against malicious npm packages. They were not looking for malware that specifically targets the AI assistants running on developer machines.
Layer 1: The Output
From February 3 to April 20 — 76 days — every project on Lovable created before November 2025 was potentially exposed.
Lovable is a $6.6 billion vibe coding platform with eight million users. The vulnerability was a textbook BOLA — Broken Object Level Authorization, OWASP API Security's #1 risk. The /projects/{id}/* endpoints verified Firebase authentication tokens but skipped ownership checks entirely. Any free account could access any other user's projects, source code, database credentials, and full AI conversation history.
A security researcher reported it through HackerOne on February 22. HackerOne closed the report without escalation. Lovable called the exposed data "intentional behavior." Then blamed the documentation. Then blamed HackerOne.
The AI-specific twist: because Lovable stores full AI chat histories, the exposed data included every prompt developers sent — error logs, business logic, and credentials pasted mid-session. And because the AI itself generates code with hardcoded Supabase credentials, the output layer compounds the exposure. The AI writes insecure code; the platform stores it insecurely; the security report gets closed as intended behavior.
The number
91.5%
of vibe-coded applications assessed in Q1 2026 contained at least one vulnerability traceable to AI hallucinations. — VibeEval
Who defends this layer? Application security teams. They're running SAST scanners and reviewing pull requests. They know BOLA. They know hardcoded credentials. But they're staffed to review code written by humans at human speed — not code generated by AI at machine speed across eight million users.
One Stack, Four Silos
| Layer | Incident | Attack Surface | Defenders |
|---|---|---|---|
| Agent | Cursor CVE-2026-26268 | Autonomous git operations in untrusted context | Runtime security |
| Integration | Vercel / Context.ai | OAuth grants to AI tools | Identity & access |
| Credential | Bitwarden / Butlerian Jihad | AI tool auth tokens as targets | Supply chain security |
| Output | Lovable BOLA | AI-generated code with hardcoded credentials | Application security |
Four layers. Four incidents. Four different security teams, with different tools, different conferences, different Slack channels, different mental models.
The runtime security team thinking about agent sandbox escapes is not reading the Endor Labs analysis of npm supply chain malware. The identity team auditing OAuth grants is not tracking CVSS scores for AI IDEs. The appsec team running SAST scanners has no visibility into whether the AI assistant on a developer's machine has been compromised by a malicious shell injection.
The attackers have no such separation. The Bitwarden payload combined supply chain compromise with AI credential theft with shell persistence with npm worm propagation — crossing three of the four layers in a single package. Attackers compose across the stack. Defenders specialize within their layer.
This is the structural problem. We've spent the last year debating AI security as if it were one thing — prompt injection, mostly. The instruction surface I wrote about last week sits across all four layers. But the actual attacks aren't theoretical prompt injection chains. They're layer-specific exploits that different teams need different skills to detect, and no one is stitching the picture together.
IBM's 2025 data: 86% of organizations lack visibility into AI data flows. 97% lack proper AI access controls. The number tracks — not because organizations are negligent, but because the attack surface doesn't map to any existing team's charter.
Four incidents. One week. One stack that nobody owns.
Sources: Novee Security (CVE-2026-26268) · Vercel KB · Reco.ai · Trend Micro · Endor Labs · TNW · Cyber Kendra · Hackread · CSO Online