AI coding assistant security · Embedded browser flaws in five AI coding assistants
Embedded browser flaws hit five AI coding assistants
Forever Security reports separate flaws in Cursor, GitHub Copilot, Codex, VS Code and Claude Desktop. Codex and VS Code remained unpatched at publication.
Treat pages and local previews as hostile even when an assistant opens them.
The research shows three distinct failure modes rather than one shared bug: a page influenced agent execution in Cursor, a page spoofed its address in GitHub Copilot, and local HTML could read beyond its intended directory in Codex, VS Code and Claude Desktop. Cursor, Copilot and Claude Desktop had fixes by publication, according to the researchers. The Codex and VS Code file-read paths remained open, so teams should stop previewing untrusted local HTML in those embedded browsers and investigate any trusted project that contains it.
- Products tested
- Cursor, GitHub Copilot, Codex, VS Code and Claude Desktop
- Highest reported impact
- Host code execution or local-file exfiltration
- Still open on October 29
- Codex and VS Code file-read paths
- Required interaction
- The disclosed file-read chain needs a local HTML link to be opened
What the researchers disclosed
Forever Security published technical research covering five desktop AI assistants on October 29.[1] The team reports host code execution in Cursor, address-bar spoofing in GitHub Copilot, and local-file reads in Codex, VS Code and Claude Desktop.
The researchers grouped the findings under EMBRACE, but the products do not share one implementation defect.[1] Each assistant extended an embedded browser with access or context that an ordinary browser would deny, and each extension created a different security failure.
Help Net Security independently interviewed the researcher and reviewed the findings [2]. Its report says Cursor, GitHub Copilot and Claude Desktop had fixes, while Codex and VS Code remained unpatched on October 29.
How the local-file chain works
The disclosed chain begins inside a project that contains a crafted HTML file. After the assistant presents a link and the developer opens it, JavaScript in the local page starts reading files that should sit outside the preview's allowed directory.[1][2]
Forever Security says Codex did not enforce a project-folder limit for the local page.[1] VS Code and Claude Desktop applied a folder check to the page, but a Web Worker could operate outside that check. The researchers used macOS metadata files to locate additional folders, then demonstrated collection of SSH keys, environment files, npm tokens and the hosts file.[1][2]
A click is required in the published chain. That requirement lowers exploitability compared with a zero-click path, but an assistant-generated preview link can look like a normal setup step inside a project.
Why Workspace Trust does not close this path
Microsoft documents Workspace Trust as a way to limit automatic code execution in untrusted folders [3]. The reported file-read chain starts after a user trusts the project and opens its local preview, which is a common step when testing a repository.
Forever Security says Microsoft and Anthropic initially pointed to trust prompts when responding to reports.[1][2] The researchers' result shows why a trusted workspace must not make every file inside it equivalent to trusted application code.
Workspace Trust still matters because it blocks other automatic behaviors. Teams should keep it enabled, but they also need a separate rule for local browser content: a repository can be trusted for editing while its HTML remains untrusted for host-file access.
Patch status by product
These statements reflect the researchers' and reporter's publication-time status. Vendor release channels can change after publication, so managed fleets should verify the current installed version and vendor advisory before restoring local-preview workflows.
- Cursor: Forever Security reports that Cursor patched the prompt-injection and execution path on October 1 after a September 10 disclosure.[1][2]
- GitHub Copilot: the researchers say version 1.1.29 fixed the address-spoofing issue on October 13.[1][2]
- Claude Desktop: Help Net Security reports a fix by publication, but public reporting does not provide a version number.[2]
- Codex: the researchers reported no fix or vendor response by October 29.[1][2]
- VS Code: the researchers reported no fix for this Web Worker file-read path by October 29.[1][2]
Response checklist for developer teams
- Disable or avoid local HTML previews in Codex and VS Code for repositories that have not received a manual security review.
- Enumerate trusted workspaces on developer machines and flag projects received through coding tests, archives, pull requests or unfamiliar forks.
- Inspect HTML files, Web Workers and scripts in those projects before opening them through an assistant.
- Update Cursor, GitHub Copilot and Claude Desktop, then verify the fixed version or vendor notice rather than assuming automatic updates completed.
- If a suspicious local preview ran, preserve logs and network evidence, isolate the workstation, and rotate SSH keys, package tokens, cloud credentials and API secrets that the user account could read.
- Move coding assistants into a container or virtual machine when testing untrusted repositories, with separate credentials and deny-by-default network access.
- Add a regression case that opens a harmless local HTML fixture and confirms it cannot read outside the project directory.
What remains uncertain
- The public research does not identify real-world exploitation of these five findings.[1][2]
- The reports do not establish that every operating system and application build is affected in the same way.
- OpenAI and Microsoft had not published incident-specific advisories when the research appeared, so the unpatched status comes from the researchers and corroborating report.
- Claude Desktop's fixed version is not named in the public report.[2]
- The Cursor execution result depended partly on model behavior and was not reliable on every attempt.[1][2]
- The demonstration proves readable files can be collected under its test conditions, but it does not measure exposure across production fleets.
How this differs from instruction-file hijacking
The earlier Downloads-folder incident used AGENTS.md or CLAUDE.md to persuade a coding agent to change configuration and run tools. This disclosure targets the embedded browser itself. A local page reaches files, a web page influences the agent, or a page lies about its address.
The controls overlap, especially isolated workspaces and limited credentials, but teams need both tests. Instruction provenance checks do not stop a Web Worker from reading files, and browser isolation does not stop an agent from following a malicious project instruction.
Frequently asked questions
- Are all five products affected by one vulnerability? No. The researchers grouped separate flaws by a shared embedded-browser trust pattern.[1]
- Which findings were still open at publication? The Codex and VS Code local-file-read paths.[1][2]
- Does exploitation require a click? The published local-file chain requires the user to open a local HTML link.[1][2]
- Is Workspace Trust useless? No. It limits other risky behavior, but it did not stop the disclosed path after a project was trusted.[1][3]
- Should teams rotate credentials? Rotate readable developer credentials when a suspicious local preview ran or evidence cannot rule out exfiltration.
- What is the safest temporary control? Keep untrusted repositories and their previews inside a disposable VM or container without personal or production credentials.
Keep learning on Learnetto
Sources
[1] Forever Security: EMBRACE technical research
[2] Help Net Security: independent report and researcher interview