Reviewing Windsurf (now Devin Desktop) — the CVE that bypassed its own deny-list
A critical path-traversal flaw worked even with auto-execution off and the vulnerable tool explicitly deny-listed. What that means for trusting a platform's own safety controls, and what changed when Cognition folded Windsurf into Devin.
Cognition (maker of Devin) acquired Windsurf in December 2025, and on June 2, 2026 rebranded it as Devin Desktop — Devin Local replaced Windsurf's Cascade agent as the primary local agent, with legacy Cascade access ending July 1, 2026. Any review scoping a “Windsurf” deployment today needs to confirm which product a team is actually running, since documentation and defaults may still reference the pre-rebrand name. Past the naming, one disclosed CVE against Windsurf is worth reading closely — not because it's the most severe bug in this cluster, but because of exactly what it bypassed.
Windsurf → Devin Desktop, June 2026
Cascade was Windsurf's agentic engine — a VS Code fork with codebase understanding, multi-file edits, terminal command execution, and MCP support for tool integration. That architecture is what the CVE below was disclosed against; a review of a current Devin Desktop deployment should confirm whether Devin Local inherited the same tool surface, or replaced it with different controls. Devin Local itself was rewritten from scratch in Rust, is reported up to 30% more token-efficient, and adds parallel subagent support Cascade never had — a real architecture change, not a rename.
The rebrand also widened the trust-boundary question rather than narrowing it: Devin Desktop added native support for the Agent Client Protocol (ACP), letting it run third-party agents (Claude Agent, Codex, OpenCode) inside the same shell. The review question is no longer just “what can Devin's own agent do” — it's what any ACP-compliant third-party agent can do once plugged into the same execution environment.
CVE-2025-62353 — a deny-list that didn't hold
CVE-2025-62353 — both explicit safety controls were on, and neither held
| Step | What happens |
|---|---|
| 1. The setup | write_to_file is explicitly placed on the tool deny-list, and Auto Execution is turned off — both controls a team would reasonably expect to block this exact tool. |
| 2. The injection | HiddenLayer hides instructions inside a project's README.md using comments — content the agent reads as part of normal codebase understanding. |
| 3. The bypass | The hidden instructions change the agent's working path to the filesystem root and direct the tool to write to sensitive files in unrelated directories — despite the deny-list and Auto Execution being off. |
A deny-list and a disabled auto-execution setting are both policy decisions enforced somewhere in the application layer. This CVE is a case where the underlying tool implementation didn't actually respect either policy once the input reached it — the review lesson isn't “configure the deny-list,” it's “verify the deny-list is actually enforced at the point where the tool executes, not just checked before the agent decides to call it.”
Affected versions were 1.12.12 and older; a review of any current deployment should confirm the fixed version is in place and, more importantly, should not assume a deny-list configuration is sufficient evidence of a bounded tool without independent verification.
CVE-2026-30615 and the shared-Chromium exposure
A second, separate Windsurf CVE (CVSS 8.0) shows a different attack shape: prompt injection could cause unauthorized modification of the local MCP configuration, auto-registering a malicious MCP server that then executed arbitrary commands — the same “agent writes its own MCP config” pattern covered in reviewing Amazon Q Developer's MCP auto-execution CVE, appearing independently in a second product.
A supply-chain campaign, separately
Separate 2025 disclosures documented a campaign (“GlassWorm”) that specifically targeted Windsurf via malicious npm packages designed to harvest API keys and install rogue MCP servers, plus additional attack vectors causing Cascade to invoke tools without human approval and exfiltrate files like .env to attacker-controlled servers. Neither is the same bug as the deny-list bypass above — both point at the same general lesson as an MCP security review already covers: an MCP server installed by a dependency, not explicitly by the developer, is still a trust boundary the agent crosses. The campaign itself was disrupted May 26, 2026 in a coordinated takedown by CrowdStrike, Google, and the Shadowserver Foundation — worth knowing the outcome, though a disrupted campaign doesn't retroactively clean packages already compromised before the takedown.
Data handling: free tier trains, paid tier doesn't
The same structural default as Cursor's Privacy Mode applies here: on the Free tier, code may be used to improve models by default — training is opt-out, not opt-in. Teams and Enterprise plans get Zero Data Retention by default. The nuance worth flagging explicitly for a review: Zero Data Retention governs storage, not transmission — code still transmits to external infrastructure in cloud-hosted deployments regardless of tier, which is a distinction easy to miss if a review stops at “we're on the Enterprise plan.”
Review checklist
For any team on Windsurf or the product it became, a design-time review should be able to answer:
- Which product is actually deployed — legacy Windsurf/Cascade or Devin Desktop/Devin Local — and does documentation match the current branding?
- Is the version in use patched past 1.12.12, closing CVE-2025-62353?
- Is a tool deny-list or Auto Execution setting the only control relied on for a given tool, without independent verification that it's enforced at the point of execution?
- Is Zero Data Retention actually in effect, and is the storage-vs-transmission distinction understood by whoever approved the deployment?
- Is the local MCP configuration file protected against unauthorized modification, closing CVE-2026-30615?
- What Chromium/Electron version does the installed build actually bundle, tracked separately from the product's own release version?
- If Devin Desktop's ACP support is enabled, what third-party agents are permitted to run in the same execution environment, and have each been reviewed independently?
Sources
Blog
Get new posts in your inbox
AI security review, OWASP Agentic Top 10, ISO 42001 evidence, and what AI Committees actually need. No cadence promises — we publish when there's something worth reading.
Review a Windsurf or Devin Desktop deployment before it ships
Deny-list enforcement verification, MCP-server provenance, and data-retention scope — mapped to a disposition your AI Committee can act on.
A note on scope: Drel reviews assessed systems against documented architecture, configuration and intent. It does not ingest live telemetry from production environments. Dispositions reflect the assessed system at the time of review and the re-assessment triggers that govern when the disposition must be revisited.