AI Assistant Browser Security Flaws
Researchers reported embedded-browser issues in Cursor, Copilot, Codex, VS Code, and Claude Desktop — trusted AI links can still open untrusted content.
Short answer
Built-in browsers in AI coding tools can blur boundaries between untrusted web content and local files — Forever Security's October 2026 research reported file-access and misleading-login scenarios in several products, with patch status varying by vendor. Isolate untrusted projects, limit assistant scope, treat previews as hostile, and rotate credentials if exposure is possible.
We are becoming accustomed to giving artificial intelligence access to our work. An AI assistant can now open a project, read a web page, and help write computer code. It feels convenient, and often it is. But what if the assistant's built-in browser is less secure than the ordinary browser we use every day?
On 29 October 2026, security researchers at Forever Security published findings about five popular AI development tools: Cursor, GitHub Copilot, OpenAI Codex, Microsoft Visual Studio Code, and Anthropic Claude Desktop. Their research examined browsers built into these products and identified different ways that seemingly harmless content could cross important security boundaries.
The researchers demonstrated that, in one Cursor scenario, a malicious page could lead an assistant towards executing a command on the computer after a user approval step. In GitHub Copilot, a page could display a misleading web address above a false sign-in screen. With local project files opened through Codex, Visual Studio Code, and Claude Desktop, the researchers reported ways to read files outside the project folder, potentially including stored credentials.
These were controlled demonstrations, not evidence that every product was being widely exploited by criminals. Forever Security reported that the Cursor issue had been patched on 1 October and the Copilot issue fixed on 13 October. It said the reported Codex and Visual Studio Code file-access issues remained unresolved on 29 October. Those were the researchers' publication-day assessments, so users should check current vendor information.
The larger problem is easy to understand: a trusted-looking link supplied by an AI assistant may still open content created by somebody you do not trust.
Why this matters
A developer's laptop may contain customer records, unreleased software, cloud passwords, and keys that authorise access to business systems. A contractor opening an unfamiliar project may unintentionally expose information belonging to several clients.
The danger is not that AI assistants are necessarily malicious. It is that their convenience can blur the boundary between untrusted websites or project files and sensitive information on the computer. A request to approve an action is not much protection if the user cannot see what the action really does.
What to do
Check what is installed. Identify which AI coding assistants staff use and confirm that current security updates and vendor guidance have been applied.
Separate unfamiliar projects. Review untrusted code in isolated environments without access to production passwords or confidential files.
Limit what assistants can reach. Give AI tools only the folders, credentials, and connections required for the immediate job.
Treat previews as untrusted. Inspect unexpected links, sign-in forms, and requests to run commands, even when an assistant presents them.
Prepare for exposure. If sensitive files or credentials may have been accessed, investigate activity and replace affected access keys promptly.
Sources
- Forever Security, 29 October 2026 — EMBRACE technical overview of embedded-browser vulnerabilities.
- Help Net Security, 29 October 2026 — research on AI assistant browsers.
- ISO/IEC 42001 explained — International Organization for Standardization.
We inventory where AI assistants operate, review access and supplier responsibilities, and align approvals with technical limits — through gap assessment.