Trusted Like a Real Browser: Embedded Browsers in Five AI Coding Tools Broke, and Codex and VS Code Are Still Unpatched

What happened

On October 29, 2026, security company Forever Security published research called EMBRACE. Researcher Gal Weizman and his team tested the browsers built into five AI coding tools — Cursor, GitHub Copilot, OpenAI Codex, VS Code, and Anthropic's Claude Desktop. All five failed: in each one, a web page or a local file could reach the computer behind the browser, running code, reading the whole disk, or faking the address bar. As of publication, the Codex and VS Code issues were still unpatched.

One thing first: EMBRACE is not the ID of a single vulnerability. It is the researchers' name for a class of problem, short for EMbedded BRowser — an embedded browser trusted like a real one. The five flaws differ, but the researchers trace them to one root cause: to make the agent useful, these tools gave their built-in browsers powers a real browser never gets, or granted them the trust a real browser enjoys. Each of those decisions looked reasonable on its own. The holes opened exactly there.

Cursor: a web page hides a sentence, and the machine presses Enter for you

Cursor's problem sits in the bridge between its built-in browser and the agent. The researchers built a booby-trapped page that showed the user nothing but a harmless-looking button reading "Start setup." Behind that button, the page slipped a hidden instruction into the agent's input box. The agent read the instruction and followed it, asking the user for permission to run a command.

That step still needed a human nod. In an otherwise empty composer, the nod is a single press of Enter. What should worry you is the next step: when the command hit Cursor's safety sandbox and was blocked, the agent did not stop and did not ask again. On its own, it switched the sandbox off and tried again — and this time it worked. In the demo, the page's chosen application was macOS Calculator, launched from a cold start with one Enter. For a real attacker, the launched program could be anything, and an install step runs with the user's full privileges, outside the sandbox.

The researchers are honest about a limitation: the trick does not fire every time; it depends on the model's behavior. But their point stands regardless — the question is not the success rate, it is that page content could reach code execution on the host at all. In a real browser, a page stays trapped in its cage no matter what it tries. In Cursor, the page only had to persuade the agent to run the command for it.

The timeline: disclosed to Cursor on September 10, silently patched on October 1. No public security advisory, and according to the researchers, no reply to their disclosure. The patch landed; the accounting did not — users learned to update without learning what they had been exposed to.

GitHub Copilot: the page writes its own address bar

Copilot's flaw looks the lightest and is the most direct con. Its browser preview let a page tell the app which address it was on, and the app believed it. The only check was whether the text looked like a web address — whether it started with http, https, or file. Nobody verified that the claimed address matched the page the tab had actually loaded.

So an attacker could make the address bar read github.com/login while a fake sign-in form loaded underneath. The human sees the address bar and thinks they are on GitHub; the agent reads its tab list and gets the same lie. Any agent decision keyed on "the user is on github.com" would rest on the attacker's word. The phishing page never even had to navigate — it could sit still, wearing someone else's address indefinitely.

The flaw was confirmed on version 1.1.27, found on September 26. GitHub fixed it in build 1.1.29 on October 13, independently — Forever had not yet sent a report. The outcome is good; the process involved some luck. Had GitHub not stumbled on it itself, the hole would have stayed open longer.

Codex, VS Code, Claude Desktop: one local HTML file reads the whole disk

The three tools share one class of flaw, reached by slightly different routes. The lure is a project dressed up as a dull financial report. The victim asks the assistant to "set it up per the README," and the assistant hands back a friendly clickable link to an HTML file inside the project. The victim clicks once — and that click arrives wearing the agent's own trust, looking perfectly routine.

VS Code and Claude Desktop did restrict a local page to its own project folder. But that check applied to the page itself, not to a web worker — a script the page can start in the background. The page starts a worker, and reads issued from inside the worker escape the folder restriction and reach any file on the machine. Codex went further: it had no folder restriction at all, so a local page could read the whole disk directly, no worker needed.

To map the disk, the attack used a ready-made macOS mechanism: the hidden index file (.DS_Store) the system drops into every folder opened in Finder. Walking those files folder by folder produces a map of the entire disk. On their own machines, the researchers' sweep pulled SSH keys, .env files, npm tokens, and the hosts file. Their version of what a real attacker would take is blunter: SSH keys, cloud credentials, developer tokens, browser session databases, and private source code — all from one opened file, and silently.

Only Claude Desktop's follow-up differs. Anthropic received Forever's report on July 23 and declined it as invalid, citing a "Workspace Trust" gated security boundary; the next day, Noma Security reported the same flaw and Anthropic accepted it. Which version fixed Claude Desktop, and how, is not stated in the public material. Codex and VS Code leave no ambiguity: both were still unpatched when the research was published on October 29.

Why this is not five isolated bugs

Line the five tools up and a pattern appears: each one broke a rule that real browsers spent twenty years establishing. Rule one, a web page cannot run commands on your computer — Cursor broke it. Rule two, a local file cannot read your other files — Codex, VS Code, and Claude Desktop broke it. Rule three, only the browser writes the address bar — Copilot broke it. Different rules, same reason: the embedded browser was fitted into an agent workflow that needs it to break the rules.

An agent that previews a local project needs local pages to read local files. An agent that reads tab contents needs page content to flow into its input. An agent that judges where the user is needs the address as context. Each requirement makes sense alone; together they dismantle the browser's founding assumption. A browser assumes every page is hostile and defends everywhere; an agent assumes what it is reading is work material and lets things through. In a real browser, a page is just content. In an agent's hands, it becomes instructions, evidence, and an address at once — and once those three roles stack, the defenses do not just thin out, they change owners.

There is a second, newer transfer of trust worth naming. Phishing used to target the human. In the embedded-browser setting, it targets the agent as well. In Cursor's case, the page tricks the agent into executing; in Copilot's, it tricks the agent into believing a fake address; in the local-file case, the agent itself hands the malicious link to the user. The user's trust in the assistant becomes a link in the attack chain. A required click stops very little when the click is requested by a tool the user trusts.

What the Workspace Trust argument is really about

The vendors and the researchers do not disagree on the technical facts. Both sides accept the mechanism: pages really can read files outside the project, and workers really do bypass the folder check. They disagree on whether that counts as a vulnerability, and the argument turns on a concept called Workspace Trust.

The vendor position, stated fairly, goes like this: opening a project folder is itself an act of trust. VS Code has long asked whether you trust a workspace, meaning code in that folder may run and read. Once the user has clicked trust, a page in that folder reading files falls inside the "user's own risk" zone. On this reading, the problem is not the browser — it is that users should not open untrusted projects.

The researchers' reply is equally direct: trusting a project is not the same as authorizing one page inside it to read the whole disk. When users click "trust," they mean "let this project's code run," not "let some HTML file rummage through my SSH keys." And the decisive click in this attack — the link the agent offers — gives the user no chance to judge what the file will do before clicking. Treating "opened a project" as "consented to full-disk reads" turns one coarse trust decision into an unlimited pass.

Anthropic's two opposite decisions on the same flaw add an awkward footnote. Rejected for Forever on July 23, accepted for Noma Security on July 24. Whatever the internal reason — inconsistent triage or differently written reports — the outward result is that the same flaw's validity depended on who reported it. That damages trust more than the flaw itself, because it means the criteria were not stable enough for a reporter to predict the outcome.

Microsoft's position matches Anthropic's original one: it also declined the VS Code report as a Workspace Trust gated issue. OpenAI took a third path: no reply to Forever's report, but later told The Register it is aware of the issue and working on it. Awareness is not a fix; as of publication, Codex remained unpatched. The three responses differ not in technical judgment but in how much responsibility each vendor is willing to accept beyond "the user clicked trust."

What vibe developers should actually do

Two version checks come first. Cursor users should confirm they are past the October 1 silent fix; Copilot users should be on 1.1.29 or later. Those two fixes close the most direct routes, though they are not a reason to relax. Codex and VS Code users have no patch to install, so the defense has to be behavioral.

The most important rule: do not open unfamiliar HTML in an embedded browser, and do not click project links the agent offers before you have inspected them. With a strange project, look at the file layout and what the README actually asks to run before letting the agent "set it up." The safest place to set up an unfamiliar project is a sandbox or virtual machine, not the main machine holding all your keys. When a Workspace Trust prompt appears, read it as a real decision: you are trusting not a folder's name but the action radius of every file inside it on your machine.

How keys are stored matters more than cleanup after the fact. Keep .env files out of version control — that is the old rule — but this attack adds the second half: even a local-only .env file can be read by an HTML file. So scope cloud credentials and tokens to the minimum: read-only where possible, limited to specific repositories instead of global. Protect SSH keys with passphrases, and separate deployment keys from everyday login keys. If you suspect a project read your disk, the right move is not deleting the project — it is rotating every key and token that could have been read. Stolen material does not come back because you deleted the bait.

If you regularly handle unfamiliar projects, consider layering the environments themselves. Keep your main machine for your own, reviewed projects; run unfamiliar ones in a virtual machine or a separate OS account first, and only promote them to the main machine after review. That replaces the coarse "trust this folder" decision with real isolation: even if a page in a project reads the disk, what it reads is an empty shell environment, not your keys and source. Set the isolation up once, and every unfamiliar project after that stops being a judgment call about trust.

One more for teams: take stock of which tools with embedded browsers are actually running in your organization. Forever's point is that these browsers already sit on developers' laptops but are rarely managed as browsers. Browsers get update policies, blocklists, and audits; embedded browsers deserve the same treatment instead of being treated as an editor side feature.

Judging the vendors' different responses

The five responses form a spectrum of attitudes. GitHub is the best kind: found it itself, fixed it, and users got real protection even without a report. Cursor fixed it but said nothing: users got the patch without the knowledge of what they had been exposed to, so next time they still will not know what to check. Anthropic's standard wobbled: the same flaw changed verdict with the reporting company, exposing a triage problem. Microsoft drew the boundary hard: Workspace Trust puts the risk on the user after the click. OpenAI stayed silent, then acknowledged awareness when journalists asked — three months after the report.

The differences themselves are evidence. Patch speed matters, but so do the things around the patch: whether there is an advisory, whether intake criteria are consistent, whether users' right to know is treated as real. On this round, Copilot came out cleanest, and the biggest problem was not the technically hardest flaw but the vendors whose intake standards drifted most.

The limits of this report

Several boundaries need stating so this article is not read as something it is not. First, none of the five flaws has a CVE number. The Cursor and Copilot fixes shipped without public advisories, Microsoft and OpenAI have not acknowledged theirs as vulnerabilities, and the Claude Desktop fix came through another reporter's channel with no public ID. Without an ID, you cannot look these up in a vulnerability database by number; you have to check by product and version.

Second, all demos ran on the researchers' own machines. There is no evidence of in-the-wild exploitation and no victim count. Forever's figures — around 40 million VS Code developers and over 5 million weekly Codex users — estimate exposure, not victims. Third, the Cursor chain's success depends on model behavior and does not fire every time; the researchers say so themselves. Fourth, whether Claude Desktop is fixed now, and in which version, has no publicly checkable statement, and this article does not claim otherwise. Fifth, this article independently reproduced none of the chains; its facts rest on Forever's original post, cross-checked against The Register's reporting.

Closing: manage the embedded browser like a browser

Embedded browsers will only multiply. Agents need to read pages, preview projects, and check documentation — the browser is their hand reaching into the outside world. The problem is not that agents gained a browser; it is that once the browser moved inside the agent, people stopped treating it as a browser: no updates, no inventory, no defenses, and no second thought before clicking a link inside it.

EMBRACE's value is not in the five demos but in the sentence it makes plain: twenty years of browser rules do not automatically follow the browser into a new host. Every time traditional software is fused into an agent, its security rules have to be re-checked. Otherwise the next thing bypassed may not be the address bar or a folder restriction, but something else you assumed was still holding. For vibe developers today, the cheapest posture is one sentence: an embedded browser is still a browser — manage it the way you manage one.