JOURNAL

EMBRACE: The Browser Bug Hiding Inside Five AI Coding Tools

Forever Security found that Cursor, GitHub Copilot, Claude Desktop, VS Code and Codex all embed browsers with more power than a real one — leading to code execution, file theft and address-bar spoofing. Two of the five flaws are still unpatched.

Conceptual illustration of coordinated workers, routing, state storage and security checks.

Read with AI

Choose content to copy and paste into your AI assistant. Nothing is sent automatically. CMS content is converted to Markdown; original Markdown is used when available.

July 23, 2026. That’s when Forever Security researcher Gal Weizman first reported a browser bug to Anthropic and OpenAI. The public writeup didn’t land until October 29, three months later, and by then the list had grown to five tools: Cursor, GitHub Copilot, Claude Desktop, VS Code, and Codex. Two of those five are still exploitable as of publication.

Weizman’s name for the bug class is EMBRACE, short for embedded browser. The one-line version of what he found: every one of these coding tools ships a browser inside the app, and every one of them gave that browser powers a real browser would never get. A regular browser tab can’t read your SSH keys. An embedded one, in at least three of these tools, can.

Three distinct failure modes came out of this, not one. Cursor got arbitrary code execution: a webpage can plant hidden instructions that the agent’s composer picks up and runs as commands, no user click required beyond opening the page. GitHub Copilot got address-bar spoofing: a page can make the bar read “github.com/login” while serving a phishing form, because the bar display and the actual navigation target aren’t tied together the way they are in Chrome or Firefox. Claude Desktop, VS Code, and Codex all got the same file-read bug through a different door — background web workers that ignore the folder restrictions the rest of the app enforces, so a hostile page can walk the whole disk and exfiltrate .env files, npm tokens, and browser credential databases.

Who fixed what, and who didn’t answer

Embedded browser trusted like a real browser, granted extra host powers, leading to code execution, file theft and address-bar spoofing across five AI coding tools.
One embedded browser, three ways to get burned. Source: Forever Security’s EMBRACE research.

Cursor patched silently on October 1, three weeks after the September 10 disclosure, and declined to comment or publish an advisory. GitHub fixed Copilot independently in build 1.1.29 on October 13 — independently meaning they found it or got told through another channel, not from this report, and didn’t respond to press questions either. That’s two vendors that fixed real security holes without telling their users what was fixed or why.

The other three are where this gets uncomfortable. Anthropic rejected the Claude Desktop report as a “Workspace Trust” boundary issue — not a bug, by their framing — until Noma Security sent in an almost identical report later and Anthropic accepted that one as valid. Same vulnerability, different verdict depending on who sent the email. Microsoft called the VS Code issue an invalid workspace-trust concern too, and it remains unpatched. OpenAI acknowledged Codex has no local file restrictions at all and said it’s “working to address it,” which three months after first contact is not actually a fix.

I don’t think “workspace trust” holds up as an answer here. Workspace trust is a model for deciding whether to run code from a folder you opened. It was never designed to cover a webpage loaded inside an embedded browser reading files outside that folder entirely. Calling that the same category of risk is a category error, and it’s the kind of category error that’s convenient to make when the fix is expensive.

What this means if you use any of these tools

If you have Codex or VS Code open with any kind of web preview or browser panel active, you have an unpatched file-read path sitting in a tool you probably use daily. The realistic trigger isn’t a sketchy site you’d never visit — it’s any webpage the agent itself loads while doing its job: a documentation page, a Stack Overflow result, a page a prompt-injected dependency redirects you to. You don’t get to audit every page an agent decides to open.

Rotate anything an embedded-browser session could have reached if you’ve had Claude Desktop, VS Code, or Codex open with untrusted content on screen in the past few months — SSH keys, .env values, npm and GitHub tokens. That sounds like overkill until you remember the exploit doesn’t need you to do anything except have the page open. Where you can, disable or avoid the embedded browser feature entirely until there’s an actual patch, not a press statement about one.

The broader lesson for anyone building agentic tools: an embedded browser is not a browser with a logo slapped on an AI product. Chrome and Firefox spent two decades building sandbox boundaries around exactly the capabilities these tools handed back to web content for convenience. If your product embeds a browser, it inherits every assumption that sandbox model depends on, and skipping the sandbox because it’s inconvenient for your feature is how you end up with five vendors answering the same question five different ways, three months after the first report.

Sources

Forever Security: EMBRACE — How We Hacked the Browsers Embedded in Top Five Desktop AI Assistants (primary disclosure, retrieved October 30, 2026).

The Register: Researchers find bugs in 5 AI developer tools, with OpenAI and Microsoft flaws still unpatched (October 29, 2026).

Discussion

Comments are reviewed before publication. Your email is kept private.

← Back to allĐọc tiếng Việt