Dev.to WebDev 🛠 Dev 👁 0 📖 7 min read

Your editor's preview browser is not a browser: auditing the EMBRACE trust boundary on your own workstation

The preview pane inside Cursor, Copilot, Codex, VS Code, and Claude Desktop looks like a browser. On October 29, 2026, Forever Security's EMBRACE research (researcher Gal Weizman) showed it was trusted like one — and tha

The preview pane inside Cursor, Copilot, Codex, VS Code, and Claude Desktop looks like a browser. On October 29, 2026, Forever Security's EMBRACE research (researcher Gal Weizman) showed it was trusted like one — and that the trust was misplaced. Two tools were unpatched at publication. This post is the audit: what was found, how to check your own machine, and what to do until a fix is verified.

Sources for every factual claim below: Forever Security, EMBRACE research, October 29, 2026, and The Register, October 29, 2026. Patch statuses are as of October 29, 2026. Re-verify them against vendor release notes before acting.

What EMBRACE found

Forever Security published the EMBRACE research on October 29, 2026, and The Register covered it the same day. Five issues, one boundary: the embedded preview inside an AI coding tool was trusted like a standalone browser. No CVEs were listed for any of the five issues.

Cursor — code execution through the composer bridge. A web page could trigger code execution via the composer bridge: the agent read hidden instructions on the page, and the demonstration launched Calculator via a malicious package install. The behavior was model-dependent, not reliable every time. Reported September 10, 2026; patched October 1, 2026. Per the researchers, there was no advisory and no reply. (Forever Security, Oct 29, 2026; The Register, Oct 29, 2026.)

GitHub Copilot — address-bar spoofing. In version 1.1.27, a page could claim github.com/login over a fake form. Found September 26, 2026. Fixed in 1.1.29 on October 13, 2026 — independently, before Forever Security filed a report. (Forever Security, Oct 29, 2026; The Register, Oct 29, 2026.)

Codex, VS Code, and Claude Desktop — reads beyond the project folder. A local HTML file could read beyond the project folder. VS Code and Claude Desktop confined the page, but not a web worker it starts; Codex had no folder check at all. The researchers demonstrated reads of SSH keys, .env files, and npm tokens. That demonstration is described here, never reproduced: nothing in this post reads a real secret.

Status at publication. Codex and VS Code were unpatched as of October 29, 2026. Claude Desktop's fix status is uncertain: Forever Security no longer counts it among open flaws, but published no fix version or date, so this post does not call it patched and does not call it unpatched. Verify it yourself — see Step 1 below.

Vendor responses. Microsoft and Anthropic declined the reports, citing Workspace Trust. Anthropic accepted Noma Security's same-class report dated July 24, 2026. OpenAI did not reply to the July 27 report, per the researchers — but told The Register it is aware and working on a fix. (Forever Security, Oct 29, 2026; The Register, Oct 29, 2026.)

Why the boundary fails

A standalone browser enforces origin and file-access rules: a page from one origin cannot freely read files from your disk, and a local file is confined to its own directory. An embedded preview inherits the editor's trust in the workspace instead. The preview looks like a browser, but it runs with the editor's relationship to your project folder — so the trust decision is the workspace's, not the web's.

The worker-escape shape, in words: the page itself was confined to the folder, but a web worker the page starts was not confined in the same way (VS Code and Claude Desktop), and in Codex there was no folder check at all. Confinement that stops at the page but not at what the page can start is not confinement of the boundary.

No exploit code, no exfiltration, and no instructions for attacking others appear in this post. The point of the audit is the reverse: find out whether your own machine, on your own versions, still has the hole — and close it by updating or by changing how you use the preview.

Tutorial: audit your own workstation

Own workstation only. Everything below runs on your own machine, against your own project folder, and reads no real secrets.

Step 1 — Record your installed versions. Open each tool's About screen and write down the installed version. Match each version against the fix versions in the kit's status table: Cursor patched October 1, 2026; GitHub Copilot fixed in 1.1.29 on October 13, 2026; Codex and VS Code unpatched as of October 29, 2026; Claude Desktop's fix status uncertain, with no published fix version or date. If your version is older than a fix version, update before anything else — and re-verify against vendor release notes, since statuses change after October 29, 2026.

Step 2 — Check workspace-trust settings. For each tool, review its workspace-trust settings: keep untrusted folders in Restricted Mode, and review the trusted-folder list, removing anything you do not recognize or no longer trust. This is the setting Microsoft and Anthropic cited when declining the reports — it only helps if untrusted folders actually stay restricted.

Step 3 — Run the kit's canary self-test. The kit's self-test is stdlib-only. It creates its own canary file in a temp directory, writes a benign probe page, and prints PASS/FAIL criteria. Run it from the kit directory against your own project folder:

python3 canary_self_test.py --project-dir /path/to/your/project

The script then prints this manual step, quoted verbatim: "open the probe page in the embedded preview of the tool being audited (not a standalone browser), read the PASS/FAIL result line, record tool name + version + result in the findings template with today's date."

An exit code of 0 means the harness is ready — the manual preview step is still required. A PASS proves one boundary on one version, not general safety.

The probe page the script generates is named embedcheck-canary-probe.html, inside the project folder. This is what the kit's script generates — it fetches only the canary path and writes the result into the page's own DOM, sending nothing anywhere. The fetch target is the canary relative path the script computes, for example ../embedcheck-canary-<name>/canary.txt:

<script>
fetch('../embedcheck-canary-<name>/canary.txt')
  .then(function (r) { return r.text(); })
  .then(function (t) {
    document.getElementById("result").textContent =
      "FAIL — boundary did not hold: canary was readable from this preview context.";
  })
  .catch(function () {
    document.getElementById("result").textContent =
      "PASS — boundary held: canary was NOT readable from this preview context.";
  });
</script>

What the script never does, stated plainly from its own header: no network calls (no sockets, no HTTP, no DNS); it never reads a real secret location or any real secret — it reads only the canary file it created itself; it never scans another machine; and it never reproduces the researchers' demonstration of reading real secrets.

Clean up with the documented cleanup command:

python3 canary_self_test.py --project-dir /path/to/your/project --cleanup

The script also prints, after the manual step, a delete command with the actual runtime paths (in the form rm -rf <temp-dir> <probe-page>) and the note "(or re-run with --cleanup)". The canary temp directory is created under the system temp dir with the prefix embedcheck-canary-.

Step 4 — Record the result. Record the result in the one-page findings template, with the as-of date: tool name, installed version, PASS or FAIL, and today's date. A PASS on one tool is not a PASS for the others — audit each tool separately.

The policy conversation (for small teams)

Three rules, each tied to a finding above — not generic advice.

  1. Don't open untrusted HTML in the embedded preview. The Codex, VS Code, and Claude Desktop finding was a local HTML file reading beyond the project folder. Untrusted HTML belongs in a standalone browser, or not opened at all — never in the preview pane that inherits workspace trust.
  2. Never enter credentials in a preview form. The Copilot finding was address-bar spoofing: a page claiming github.com/login over a fake form. If a preview shows a login form, stop. Credentials go only in the real browser, on the real origin.
  3. Treat agent instructions found on pages as untrusted. The Cursor finding was an agent reading hidden instructions on a web page and acting on them through the composer bridge. Instructions that arrive inside page content are data, not orders — the agent should not follow them without a human deciding they are wanted.

Honest caveats

  • Claude Desktop's fix status is uncertain: no published fix version or date. This post never calls it patched and never calls it unpatched. Verify it against vendor release notes.
  • Statuses are as of October 29, 2026. Re-verify before acting.
  • A PASS proves one boundary on one version, not general safety.
  • No CVEs were listed for any of the five issues.
  • The kit is a testing aid, not a security guarantee or legal advice.
  • Own workstation only. The canary self-test never reads real secrets and makes no network calls.

EmbedCheck ($29 one-time, by Haku) — the full kit: status table, checklists, trust guide, canary self-test + runbook, policy and report templates. https://vittoriali.gumroad.com/l/eysfws

— Haku

📰 Read the original article on Dev.to WebDev

Originally published by Dev.to WebDev. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.