One CVE Hit Claude Code, Cursor, Codex, and Gemini CLI. Four Different Responses.

One Windows config flaw hit four AI coding tools. Claude Code fixed it and earned a CVE. Cursor, Codex CLI, and Gemini CLI did not.

Four AI coding tools carried the exact same security hole, and their vendors responded four different ways. Cymulate researchers Ilan Kalendarov, Ben Zamir, and Elad Beber found that Claude Code, Cursor, OpenAI's Codex CLI, and Google's Gemini CLI all loaded machine-wide configuration from a Windows folder that any low-privileged local user can write to, with no check on who put the file there. Anthropic fixed it, moved the setting to a safer location, emailed enterprise customers, and the flaw now carries a public record: CVE-2026-35603. Cursor, OpenAI, and Google never shipped a code fix, and one of them called the problem a documentation update.

The mechanism is identical across all four tools. Each one reads a system-wide settings file from a subfolder under Windows' ProgramData directory every time it runs, and ProgramData is writable by any standard user account by default. None of the four vendors pre-created their tool's subfolder with restricted permissions, so an attacker with an ordinary, unprivileged account on a shared Windows machine, a build server, a jump box, a lab workstation, can create the missing folder and drop a configuration file wired to run a command automatically. The next person who launches that tool on the same machine runs the attacker's command under their own account, with nothing on screen to warn them. If that next person is a local or domain administrator, the attacker just escalated privilege without a single exploit, without touching memory corruption, and without a single prompt.

This argument favors a category we build in, so read it with that disclosed: we make TLM Forge, a process layer that gates AI-driven changes before they ship. It has nothing to say about the security posture of the tool doing the writing, but tool selection is exactly the kind of governed decision that same discipline is supposed to produce. The vendor-neutral claim underneath it stands on its own: four vendors got the identical report, and their four responses were not close to equal.

What CVE-2026-35603 actually is

CVE-2026-35603 is the official identifier for the Claude Code half of this bug, filed through GitHub's security advisory process on April 17, 2026, once Anthropic had a fix ready. The advisory classifies it as CWE-426, an untrusted search path: Claude Code on Windows loaded its default configuration from ClaudeCode/managed-settings.json under ProgramData without checking who owned that folder or who could write to it. GitHub's own advisory rates the flaw 5.4 out of 10, moderate, on the newer CVSS v4 scale. The older, more widely deployed CVSS 3.1 scale rates the identical flaw 7.3, high, because it weighs the impact of a full session takeover more heavily than the fact that the attacker needs local access to start. Every version of the Claude Code npm package before 2.1.75 shipped with the hole open.

Sources: GHSA-5cwg-9f6j-9jvx: Insecure System-Wide Configuration Loading (GitHub Security Advisory), CVE-2026-35603 Detail (NVD)

The exploit chain needs nothing exotic. An attacker with a standard, unprivileged Windows account creates the missing configuration folder, since none of the four tools created and locked it down on install. They write a settings file containing a hook, or in Codex CLI's case a notify command, the same automation feature vendors ship so teams can wire up their own tooling. Then they wait. Cymulate's researchers put it plainly: "a low-privileged attacker can have their commands run inside the session of any other user on the machine (including a local / domain administrator) with no prompt, no warning and no elevated access of their own." The hook fires again on every future launch, so the access persists until someone finds and deletes the planted file.

Sources: CVE-2026-35603: One Writable Folder, Every User Compromised (Cymulate)

The same bug, four different front doors

Cymulate did not stop at Claude Code. The team found the identical pattern, a machine-wide settings file read from a ProgramData subfolder open to any standard user, wired to a different trigger in each of the other three tools:

• Claude Code: managed-settings.json under ProgramData/ClaudeCode/, run through a hook that fires when a session starts.
• Cursor: hooks.json under ProgramData/Cursor/, run through a hook that fires when a prompt is submitted.
• Codex CLI: config.toml under ProgramData/openai/codex/, run through a notify command that fires on every agent turn, and able to also switch off the tool's own sandbox and approval prompts.
• Gemini CLI: system-defaults.json under ProgramData/gemini-cli/, run through a hook that fires when a session starts.

One CVE, three tools with no paper trail

Here is the detail that matters for anyone running a vulnerability scanner against a CVE feed: CVE-2026-35603 formally exists only for Claude Code. Anthropic requested it through GitHub's advisory process when the fix shipped, so the affected version range, the patched version, and the severity score are all on the public record. Cursor, Codex CLI, and Gemini CLI carry the identical design flaw and, as of Cymulate's report, none of the three has a CVE of its own. A scanner that matches installed software against known CVE identifiers will flag an old Claude Code install and stay silent on the other three, not because they are safer, but because nobody filed the paperwork.

Sources: CVE-2026-35603 Vulnerability Record (SentinelOne)

That gap is not unique to this bug. A CVE record generally needs a vendor, or a CVE Numbering Authority acting on its behalf, to request one, so an issue nobody has fixed and nobody has escalated often never gets a formal identifier at all, no matter how real the risk behind it is.

Four vendors, one report card

Cymulate laid out what each vendor did once notified, and the four responses do not cluster anywhere close together.

Sources: CVE-2026-35603: One Writable Folder, Every User Compromised (Cymulate)

Three of four vendors got the same report and chose not to change their code. That is not automatically a security failure, since any vendor has to triage and prioritize somehow. It is a transparency failure: a team running Cursor, Codex CLI, or Gemini CLI on a shared Windows machine today has no patched version to move to, and without reading a third-party security blog, no way to know the exposure exists at all.

What to do while you wait on a vendor

Cymulate's own recommendations point the same direction the tip above does: find out which of these tools are actually installed, then close the folder rather than waiting on a patch that may not come.

Sources: CVE-2026-35603: One Writable Folder, Every User Compromised (Cymulate)

A short checklist that does not depend on any vendor

• Inventory which of the four tools, and anything else that reads a machine-wide config file, run on shared or multi-user Windows machines: build servers, jump boxes, VDI images, lab workstations.
• Pre-create and lock down each tool's ProgramData subfolder with Group Policy or your endpoint management platform, so a standard user account cannot write there.
• Treat auto-update as the patch channel for Claude Code specifically. The fix is version 2.1.75 and later; anything older still has the hole open.
• Write down, for every tool your team keeps running unpatched, who made that call, when, and what the vendor said when asked. That record is what turns a known risk into a managed one instead of a forgotten one.

Hardening the folder fixes this specific bug. It does not fix the pattern behind it, which is that four vendors selling into the same market got the same disclosure and treated it as four different priorities. Anthropic emailed customers directly to ship a fix fast. Google routed a code-execution bug into a documentation ticket. If an engineering org runs more than one of these tools, and most now do, that gap is a fact about its risk surface, not a footnote.

The usual instinct is to demand secure defaults from the code a coding agent writes: secure defaults for AI code covers why an assistant reaches for insecure patterns unless someone changes what it reaches for first. CVE-2026-35603 is the same argument aimed at the tool itself instead of its output. A configuration loader that trusts any file sitting in a world-writable folder is an insecure default no different from a database query built with string concatenation, and it shipped in four separate products before anyone caught it.

Most AI coding policies say nothing about any of this. They cover what an agent may touch and how its pull request gets reviewed, not whether the tool generating that pull request is itself running with a known, unpatched local privilege escalation. Your AI coding policy template enforces nothing if it never asks that question, because a document with no named mechanism for tracking vendor security posture is a position statement, not a control.

TLM Forge does not reach this specific bug. Its convergence gate reviews the diff an agent proposes, not the binary that proposed it, so a hole in Claude Code's or Cursor's own configuration loader sits below where that gate looks. What the gate does enforce is the habit this vulnerability rewards: nothing ships and nothing gets trusted until an independent check closes the open questions instead of assuming good faith. Applied to tool selection instead of code review, that habit is what turns a security blog someone happened to read into a tracked, owned decision that survives the next hire.

That kind of decision decays fast in practice, because the reasoning lives in one engineer's memory of a blog post from months back. Which tools a team vetted, what each vendor said when notified, and why Cursor is still allowed despite an open, vendor-acknowledged hole are exactly the facts that vanish between one engineer and the next. That record needs to be attached to the decision itself, in a vetting doc or ticket, not to whoever happened to make the call. MemX, from the same team behind TLM Forge, is built for an individual's version of that same durability problem: a private, persistent memory layer for personal photos, documents, voice notes, and messages, not a team's tool-vetting history.

CVE-2026-35603 will look, inside a vulnerability database, like a single Claude Code fix with a moderate severity score. The more useful way to read it is as a controlled experiment: the same disclosure, run against four vendors within a couple of months of each other, in the same market, selling to the same engineering teams. Anthropic answered with a real fix and a customer email. Google answered with a documentation ticket. Nothing about the underlying flaw explains that gap. The gap is the vendor, and it is now part of what an engineering team is actually buying when it picks one of these tools.