Nine CVEs in the Tools Your Developers Run All Day: Cursor, Claude Code, Gemini CLI and the MCP Reference Server

A defender's reading of the 2026 AI coding assistant advisories: what the failure mode actually is, which version floors to enforce, what your CI should stop trusting, and what a penetration test now needs to cover.

Between December 2025 and July 2026, nine CVE records were published against four AI coding tools that are probably running on your engineers' laptops and inside your pull request pipeline right now: two against Cursor, three against Claude Code, one against Google's Gemini CLI and its GitHub Action, and three against mcp-server-git, a reference implementation in the Model Context Protocol servers repository.

Every one is patched. Not one is a breach of Anthropic, Google, Anysphere or xAI, and no primary source in this set reports exploitation in the wild. What makes them worth an hour of your time is that they are not nine unrelated bugs but nine instances of one pattern, and that pattern sits exactly where most organisations have no test coverage.

One root pattern, four vendors: workspace files as trusted configuration

Every record below works the same way, in two stages.

Stage one: something writes a file into the working directory. In the advisories the write comes from prompt injection: untrusted content the agent read from a repository, an issue, a pull request or a dependency, which caused it to write where it should not have. Cursor's advisory for CVE-2026-26268 names the mechanism directly: "A malicious agent (ie prompt injection) could write to improperly protected .git settings, including git hooks."

Stage two: something ordinary executes that file later. Not the agent, and not the user. Git runs a hook. The tool restarts and reads its settings file. The CI job loads an environment file. This defeats the control most teams already have: if your policy is "an engineer reviews every command the agent proposes," stage two shows the engineer nothing, because by then the agent is no longer involved. Cursor puts it in one sentence that should not be paraphrased away: "No user interaction was required as Git executes these commands automatically."

That is the whole class. A workspace is data. These tools treated parts of it as configuration. The classification first, because headlines here blur five very different things:

Category E is a label this research had to introduce because A through D do not describe a 2026 pattern in which a model, not an adversary, was the actor. Nothing here is an E or a D. Every record is a plain C: someone found a bug, reported it, the vendor fixed it, a CVE published. Eight of the nine advisories name a finder, a research team or a researcher account; none credits an autonomous system as the discoverer.

Cursor CVE-2026-26268 and CVE-2026-48124: why the .claude/ filename does not make it an Anthropic bug

CVE-2026-26268 is the clearest statement of the class. Cursor's advisory, titled "Sandbox escape via Git hooks," says writing to improperly protected .git settings including git hooks "may cause out-of-sandbox RCE next time they are triggered," and that no user interaction was required (Cursor advisory GHSA-8pcm-8jpx-hv8r). Fixed in 2.5. It credits the Novee Security Research Team, Daniel Teixeira of the Nvidia AI Red Team, and Philip Tsukerman. NVD classifies it CWE-862, missing authorization (NVD).

CVE-2026-48124 is the one people misfile. Cursor's advisory states that "Cursor Desktop could execute workspace-defined Claude hook commands from .claude/settings.local.json without dedicated user approval," and that a malicious workspace or agent-created file "could allow sandbox escape, persistence across turns, local data access, or follow-on compromise" (Cursor advisory GHSA-pc9j-3qc2-95wv). NVD's record lists the affected vendor as Cursor, versions prior to 3.0.0, fixed in 3.0.0.

The .claude/ directory name is a file format, not an owner. The defect is that Cursor read hook definitions out of a workspace file and ran them without dedicated approval. If your asset inventory routes this record to Anthropic it will be closed as not-applicable and the actual fix, a Cursor upgrade, will not happen. Cursor's remediation text is explicit: "Workspace-sourced hook commands now require appropriate approval and are subject to the same execution policy controls as other agent shell commands."

Claude Code CVE-2026-55607, CVE-2026-39861 and CVE-2026-25725: escalation and persistence, not initial access

Claude Code's three records are all sandbox escapes, and all three state their own precondition plainly, which is what should drive your ranking.

CVE-2026-25725 (fixed in 2.1.2, February 2026) is the persistence variant. The bubblewrap sandbox protected .claude/settings.local.json with read-only constraints but did not protect .claude/settings.json when that file did not exist at startup, so code inside the sandbox could create it and inject hooks that "would execute with host privileges when Claude Code was restarted" (Anthropic advisory GHSA-ff64-7w26-62rf). The gap was a missing file, not a weak permission.

CVE-2026-39861 (fixed in 2.1.64, April 2026) is the composition variant. A sandboxed process could create a symlink pointing outside the workspace; the unsandboxed process later followed it and wrote to the target without prompting. Anthropic's framing is the useful part: "neither the sandboxed command nor the unsandboxed app could independently write outside the workspace, but their combination could" (Anthropic advisory GHSA-vp62-r36r-9xqp). It is an arbitrary file write that the vendor describes as "potentially leading to code execution outside the sandbox," so calling it a mere file-write issue undersells it and calling it clean remote code execution oversells it.

CVE-2026-55607 (affects 2.1.38 up to but not including 2.1.163, fixed in 2.1.163, July 2026) is git worktree path confusion: worktree handling allowed worktrees named .git and navigation outside the sandbox context, and overwrites of home-directory files such as .zshenv led to execution outside the seatbelt sandbox restrictions (Anthropic advisory GHSA-7835-87q9-rgvv).

The precondition is the ranking signal. CVE-2026-55607 states that reliable exploitation "required the user to clone a malicious repository containing prompt injection content and run Claude Code against it." CVE-2026-39861 required "the ability to add untrusted content into a Claude Code context window." Neither is initial access. Both are what an attacker does after getting text in front of your agent, which is why the untrusted-repository policy below is the control that removes the precondition.

Gemini CLI in headless CI: one advisory, two records, and why published timelines disagree

Google's advisory covers two hardening changes, both scoped to untrusted CI. First, folder trust: in previous versions Gemini CLI in headless mode "automatically trusted workspace folders for the purpose of loading configuration and environment variables," which "could lead to remote code execution via malicious environment variables in the local .gemini/ directory." Second, tool allowlisting: under --yolo the CLI ignored the fine-grained allowlist in its settings file, so an allowlist meant to permit one narrow command permitted everything, which "could lead to remote code execution via prompt injection" (Google advisory GHSA-wpqr-6v78-jr5g).

The impact line is unusually blunt for a vendor advisory: "This affects all Gemini CLI GitHub Actions." Patched in @google/gemini-cli 0.39.1 (and 0.40.0-preview.3 on the preview line) and in the run-gemini-cli Action 0.1.22, with maintainers told to set an explicit workspace-trust variable where input is trusted and to follow the repository's hardening guidance where it is not.

Now the record-keeping trap. The vendor advisory published on 24 April 2026 and carries no CVE identifier in its GitHub record. CVE-2026-12537 published on 24 June 2026, two months later, and its sole non-NVD reference points back at that same vendor advisory (NVD). A second GitHub record, GHSA-jj69-4grx-fqj5, mirrors the CVE. Same vulnerability, two records, two months apart, and a "no known CVE" string on the record most people read first. If your vulnerability management deduplicates by identifier, this arrives as one item or three depending on which feed reached you, and a team that patched in April may still show an unremediated CVE in June. Treat the advisory and the CVE as one item and close both.

mcp-server-git: three flaws in a reference implementation everyone copied

mcp-server-git lives in the modelcontextprotocol/servers repository, the reference implementation set for the protocol. That is the point: reference code gets copied, vendored and adapted, so its defects propagate into servers carrying no advisory of their own.

Two of the three carry a version conflict between primary sources, worth showing rather than resolving. For CVE-2025-68144 and CVE-2025-68145 the GitHub advisory records list 2025.12.18 as first patched, while NVD's description text says versions prior to 2025.12.17 and advises upgrading to 2025.12.17, adding "upon release" for CVE-2025-68145 (NVD). Both are primary, and the published package index lists a 2025.12.18 release and no 2025.12.17. A floor of 2025.12.18 or later satisfies both records, so enforce that rather than arguing about which is authoritative.

CVE-2025-68145 is the one that generalises: a scope-restriction flag that did not restrict scope. If you deployed an MCP server and reasoned "it is confined to this repository because we passed the confinement flag," that is the assumption the record breaks. We cover testing that boundary in our guide to an MCP server security assessment.

The other direction: what your coding agent sends home

Everything above is about code arriving. The Grok Build CLI matter is about code leaving, and it belongs in a different bucket: a Category C product data-handling defect, with no CVE, no vendor advisory and no attacker anywhere in the story. The data went to the vendor, not to an adversary.

The only substantive account is an independent researcher's wire-level capture of Grok Build CLI version 0.2.93 in July 2026 (cereblab gist). Its central measured claim is that the CLI uploaded the whole tracked repository, file contents plus git history, as a git bundle, independently of what the model actually read, and that with the "Improve the model" setting turned off the upload still occurred and the server still reported upload as enabled. The researcher's conclusion is the quotable one: "Opting out does not stop your repository from leaving the machine." The same document carries an update note saying the vendor later disabled the upload server-side; deletion of previously uploaded data is not confirmed, and no vendor advisory exists.

Treat those specifics as researcher-reported and single-sourced, and the control question as settled regardless of this one tool: for every AI coding assistant your engineers install, get a documented answer to what leaves the machine, whether a privacy toggle changes it, and whether it covers files the agent never opened.

Reading the scores honestly: where the advisory and NVD disagree

Severity here is not a single number, and a policy keyed to one source drops findings.

Three readings, all checkable against the records.

The gap is real but mostly not apples to apples. Most publishing advisories here score with CVSS 4.0 while NVD's primary scores are CVSS 3.1, and the frameworks are not interchangeable. The one row where both use CVSS 3.1 is CVE-2026-26268, where the advisory says 8.0 High and NVD says 9.9 Critical: nearly two full points on the same scale, driven by NVD rating attack complexity and privileges required as low where the advisory rated both high.

The direction is not systematic. NVD is higher in seven of the eight records carrying both scores. CVE-2026-12537 reverses it, with Google's CNA at 10.0 Critical and NVD at 7.8 High, because the CNA scored a network-reachable CI compromise and NVD a local issue requiring user interaction. "Take the higher source" is not a workable rule.

One record has no NVD primary score at all. CVE-2026-48124 sits in Deferred status, so the only score is the advisory's 8.5. If your policy is "patch anything NVD rates 7.0 or above," this record is invisible to you, and it is the Cursor Desktop hook-execution bug.

The conclusion is not that one source is wrong, but that a severity threshold is a bad trigger for this class: the exploitability the frameworks argue about turns on a local fact neither can see, namely whether your engineers point these tools at repositories they did not write.

Version floors, CI hardening and the untrusted-repository policy

Hand this to engineering: three controls and a floor.

Two rules behind that table: an allowlist bypassed in one mode is not an allowlist, so test it in the mode you actually run; and a runner that can reach the whole internet is a runner that can be told to.

Detection, at the level of what to look for. Alert on creation or modification of git hook files and git configuration inside repositories checked out by an agent session, because normal development rarely rewrites those mid-session. Alert on agent settings files present on disk but not tracked in the repository, the signature of stage one. Alert on writes to shell startup files in a home directory by a process whose working directory is a cloned repository. On CI runners, alert on processes spawned inside an agent step that are not on the expected list, and on outbound connections to hosts outside the allowlist. None of this needs new tooling; it needs a decision that the developer endpoint and the runner are monitored assets.

What a pentest should now cover: developer endpoints, CI runners and the workspace trust boundary

Here is the uncomfortable part for scoping. Not one of these nine records is reachable through your production web application. They land on the laptop and in the pipeline, so a web application penetration test will not find them and neither will an external network test.

The scope additions that follow are specific:

• The developer endpoint as a target. Can a repository the organisation did not write cause writes outside its own directory when an agent is pointed at it? That is what all five endpoint-side records reduce to.

• The CI runner as a target. Does an agent step inherit trust from the checkout? Does the allowlist hold in the mode the pipeline actually uses? What credentials sit on the runner? Our CI/CD pipeline penetration testing scope guide covers scoping that as a distinct engagement.

• The workspace trust boundary itself. Every file the tooling reads from the workspace and treats as instruction rather than data: hooks, settings, environment files, tool arguments.

• The MCP layer, where you run one. Scope-restriction flags that do not restrict, tools accepting arbitrary paths, and arguments passed to a shell without validation are the exact defects the reference implementation shipped.

A note on where our own tooling stops, because the distinction matters. Stingrai's autonomous agent Snipe tests web applications, hunting complex classes such as IDOR, broken authorization and business-logic flaws. It does not test laptops or build pipelines, and no autonomous web-application agent does. Developer endpoints, CI runners and MCP connector layers are human-led work, and our Hybrid engagements put a senior penetration tester on every finding. Stingrai has worked this way since 2021 from Toronto and London, is a CREST-accredited penetration testing service provider at firm level, holds 18 published CVEs, and carries 5.0 out of 5.0 across 19 Clutch reviews; scoping and pricing are published. Whether the applications your agents write need testing is a separate question, answered in do AI-coded apps need penetration testing.

The summary a board will accept: nine patched product vulnerabilities, no vendor breach, one root cause, and a scope gap where the assets carrying the risk were never in scope.

Frequently Asked Questions

Is Cursor safe to use on untrusted repositories?

Only on a current version, and only with a policy behind it. Cursor's own advisory for CVE-2026-26268 states that prompt injection could write to improperly protected .git settings including git hooks, and that "No user interaction was required as Git executes these commands automatically," which means human review of agent commands does not catch it. Both Cursor records are fixed, with CVE-2026-26268 in version 2.5 and CVE-2026-48124 in version 3.0.0, so 3.0.0 is the floor. The durable control is not running an agent with elevated autonomy against code your organisation did not write.

What is CVE-2026-26268 and which Cursor version fixes it?

CVE-2026-26268 is a sandbox escape in Cursor in which a malicious agent, meaning prompt injection, could write to improperly protected .git settings including git hooks, which the vendor says "may cause out-of-sandbox RCE next time they are triggered." It is fixed in Cursor version 2.5. Severity is disputed between primary sources: the publishing advisory scores it 8.0 High and NVD's primary score is 9.9 Critical, both on CVSS 3.1. It is a Category C product vulnerability, not a breach of Cursor's maker Anysphere.

Was Claude Code hacked?

No. Claude Code has three published CVEs from 2026 (CVE-2026-25725, CVE-2026-39861 and CVE-2026-55607), and all three are Category C product vulnerabilities: locally exploitable sandbox escapes in a developer command-line tool, reported by outside researchers and patched. Each advisory describes a flaw in the shipped CLI and the version that fixes it; none describes any compromise of Anthropic's own infrastructure, so none is a Category D corporate breach. A CVE in a product is not a breach of the company that makes it.

Which Claude Code version patches the sandbox escape?

There are three separate sandbox-escape records, so the answer depends which one you mean: CVE-2026-25725 is fixed in 2.1.2, CVE-2026-39861 in 2.1.64, and CVE-2026-55607 in 2.1.163. Version 2.1.163 or later clears all three, so that is the floor to enforce. Anthropic's advisories note that users on standard auto-update received the fixes automatically, so the exposure sits with pinned or manually updated installations, which is where an inventory check is worth the effort.

Is Gemini CLI safe to run in GitHub Actions?

Only on version 0.39.1 or later with run-gemini-cli 0.1.22 or later, and only with workspace trust set explicitly. Google's advisory states that in previous versions Gemini CLI in headless mode automatically trusted workspace folders when loading configuration and environment variables, and that its impact "affects all Gemini CLI GitHub Actions." The advisory also fixed a second issue where a fine-grained tool allowlist was ignored under --yolo mode. The corresponding CVE, CVE-2026-12537, published two months after the advisory, so patch by advisory and close the CVE against the same work.

Are MCP servers a security risk?

They are ordinary software with an unusual amount of reach, and the reference implementation proves the point. Three CVEs against mcp-server-git cover a tool that created repositories at arbitrary filesystem paths (CVE-2025-68143), arguments passed to the git command line without sanitisation enabling arbitrary file overwrites (CVE-2025-68144), and a repository-restriction flag that did not actually restrict later tool calls to that repository (CVE-2025-68145). Because reference code gets copied and vendored, the same defects reach servers that have no advisory of their own. Inventory the MCP servers you run, enforce a floor of 2025.12.18 for mcp-server-git, and test the connector layer directly.

Does my AI coding assistant upload my source code?

Assume it sends something and get a documented answer for each tool, because at least one 2026 case shows the answer can be broader than what the agent read. An independent researcher's wire-level capture of Grok Build CLI 0.2.93 reported that the tool uploaded the entire tracked repository including git history as a git bundle, independently of which files the model opened, and that turning off the "Improve the model" setting did not stop it. That account is researcher-reported and single-sourced, with no vendor advisory, and it is a product data-handling defect rather than an attack or a breach. The general control is procurement plus egress monitoring: ask what leaves the machine, whether a privacy toggle changes it, and whether it covers files the agent never read.

How do I secure AI coding agents in CI/CD?

Four controls cover this record set. Enforce version floors (Cursor 3.0.0, Claude Code 2.1.163, Gemini CLI 0.39.1 with run-gemini-cli 0.1.22, mcp-server-git 2025.12.18). Require explicit workspace trust rather than implicit headless trust, so an agent step never loads settings or environment files out of an unverified checkout. Verify that tool allowlists are enforced in the mode the pipeline actually runs, not just in interactive mode. Gate agent steps triggered by pull requests from outside collaborators behind an approval, and monitor runners for unexpected child processes and outbound connections to hosts outside the allowlist.

References

1. Cursor. Sandbox escape via Git hooks (GHSA-8pcm-8jpx-hv8r, CVE-2026-26268). https://github.com/cursor/cursor/security/advisories/GHSA-8pcm-8jpx-hv8r. Vendor advisory stating that prompt injection could write to improperly protected .git settings including git hooks, that no user interaction was required, and that the issue is fixed in version 2.5.

2. Cursor. Cursor Desktop sandbox escape via Claude hook configuration (GHSA-pc9j-3qc2-95wv, CVE-2026-48124). https://github.com/cursor/cursor/security/advisories/GHSA-pc9j-3qc2-95wv. Vendor advisory on execution of workspace-defined hook commands from .claude/settings.local.json without dedicated user approval, patched in 3.0.0.

3. NIST National Vulnerability Database. CVE-2026-26268. https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-26268. NVD primary CVSS 3.1 score of 9.9 Critical against the publishing advisory's 8.0 High, CWE-862, affected versions prior to 2.5.

4. NIST National Vulnerability Database. CVE-2026-48124. https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-48124. Record in Deferred status with no NVD primary score; CNA CVSS 4.0 score of 8.5 High, affected versions prior to 3.0.0.

5. Anthropic. Claude Code: Sandbox Escape via Persistent Configuration Injection in settings.json (GHSA-ff64-7w26-62rf, CVE-2026-25725). https://github.com/anthropics/claude-code/security/advisories/GHSA-ff64-7w26-62rf. Bubblewrap sandbox did not protect .claude/settings.json when absent at startup; patched in 2.1.2.

6. Anthropic. Claude Code: Sandbox Escape via Symlink Following Allows Arbitrary File Write Outside Workspace (GHSA-vp62-r36r-9xqp, CVE-2026-39861). https://github.com/anthropics/claude-code/security/advisories/GHSA-vp62-r36r-9xqp. Arbitrary file write outside the workspace, potentially leading to code execution outside the sandbox; patched in 2.1.64.

7. Anthropic. Claude Code: Sandbox Escape via Git Worktree Path Confusion Allows Unsandboxed Code Execution (GHSA-7835-87q9-rgvv, CVE-2026-55607). https://github.com/anthropics/claude-code/security/advisories/GHSA-7835-87q9-rgvv. Affects 2.1.38 up to but not including 2.1.163; requires cloning a malicious repository containing prompt injection content.

8. Google. Gemini CLI: Remote Code Execution via workspace trust and tool allowlisting bypasses (GHSA-wpqr-6v78-jr5g). https://github.com/google-github-actions/run-gemini-cli/security/advisories/GHSA-wpqr-6v78-jr5g. Vendor advisory covering headless folder trust and --yolo allowlist bypass; patched in Gemini CLI 0.39.1 and run-gemini-cli 0.1.22.

9. GitHub Advisory Database. GHSA-jj69-4grx-fqj5 (CVE-2026-12537). https://github.com/advisories/GHSA-jj69-4grx-fqj5. The CVE record mirroring the Gemini CLI advisory, published two months later.

10. NIST National Vulnerability Database. CVE-2026-12537. https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-12537. CNA CVSS 4.0 score of 10.0 Critical against NVD's primary CVSS 3.1 score of 7.8 High; sole non-NVD reference is the Google advisory.

11. Model Context Protocol. mcp-server-git unrestricted git_init tool (GHSA-5cgr-j3jf-jw3v, CVE-2025-68143). https://github.com/modelcontextprotocol/servers/security/advisories/GHSA-5cgr-j3jf-jw3v. Tool removed entirely; patched in 2025.9.25.

12. Model Context Protocol. mcp-server-git argument injection in git_diff and git_checkout (GHSA-9xwc-hfwc-8w59, CVE-2025-68144). https://github.com/modelcontextprotocol/servers/security/advisories/GHSA-9xwc-hfwc-8w59. Arbitrary file overwrites via flag-like arguments; advisory lists 2025.12.18 as first patched version.

13. Model Context Protocol. mcp-server-git missing path validation when using --repository flag (GHSA-j22h-9j4x-23w5, CVE-2025-68145). https://github.com/modelcontextprotocol/servers/security/advisories/GHSA-j22h-9j4x-23w5. Repository restriction not enforced on later tool calls; advisory lists 2025.12.18 as first patched version.

14. NIST National Vulnerability Database. CVE-2025-68145. https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2025-68145. NVD primary CVSS 3.1 score of 9.1 Critical against the CNA's 6.4 Medium; description text names 2025.12.17 as the fix version, conflicting with the advisory record.

15. cereblab. What xAI Grok Build CLI actually sends to xAI: a wire-level analysis (grok 0.2.93). July 2026. https://gist.github.com/cereblab/dc9a40bc26120f4540e4e09b75ffb547. Independent researcher wire capture reporting whole-repository upload independent of files read, and that the model-improvement opt-out did not stop it. No xAI advisory exists; treat as researcher-reported and single-sourced.