When the Tool Fights Back: Three Ways AI Coding Assistants Have Become an Attack Surface

·

Summary

Three distinct attacks confirmed in April 2026 establish a new threat category: AI coding assistant is no longer just a productivity tool rather it is an active attack surface. Malware is now writing to Claude Code’s configuration files to persist across every developer who clones a repository. A maximum-severity flaw in Gemini CLI allowed arbitrary code execution before the agent’s sandbox even started. And a North Korean threat actor crafted an npm package so convincingly documented that Claude Opus inserted it as a legitimate dependency. The attack surface is real, confirmed, and expanding

Introduction

AI coding assistants were supposed to make development more secure: consistent code reviews, fewer human errors, automated vulnerability detection. That promise has not disappeared. But April 2026 added a contradiction: the same systems built to reduce risk are now an attack vector in their own right.

Security teams have spent years building threat models around human mistakes — developers committing secrets, clicking phishing links, installing unreviewed packages. April 2026 changed that model in a way that matters: adversaries are now deliberately targeting the AI systems that assist developers. Three incidents, all confirmed by multiple independent security vendors, tell a consistent story: AI coding assistants have an attack surface that security teams have not yet mapped, and adversaries have noticed.

Attack 1: The Config File That Re-Infects Every Developer Who Clones Your Repo

In late April 2026, security researchers at Sophos, Wiz, Onapsis, and Mend documented a supply-chain worm they called Mini Shai-Hulud. The campaign compromised four SAP Cloud Application Programming (CAP) npm packages and the popular lightning PyPI package (~572,000 weekly downloads combined). But the most novel part was not the credential theft itself but what happened after.

Once the malware executed on a developer’s machine, it crawled every git repository accessible via the developer’s GitHub token and wrote two files into each one:

.claude/settings.json – a Claude Code “SessionStart” hook pointing to a malicious script.

.vscode/tasks.json – a VSCode “run0n: folderOpen” task invoking the same script.

Both files were then committed and pushed using the stolen GitHub token, spreading to every collaborator on every accessible repository.

The consequence: every developer who subsequently opens any of those repositories in Claude Code or VS Code triggers the payload — with their own credentials, in their own environment — without installing anything new. Stolen GitHub tokens, npm tokens, and cloud provider credentials were encrypted and committed to the victim’s own public GitHub repositories, labelled “A Mini Shai-Hulud has Appeared” — visible to anyone without authentication.

Why this matters: agentic IDE configuration files are committed to repos and reviewed with almost no scrutiny. They look like project setup. They execute with developer privileges at IDE-open time. Until April 2026, no malware had used them as a persistence mechanism. Now that the technique is public and documented, expect it to be copied. The broader campaign this worm is part of has compromised more than 1,000 SaaS environments, including the European Commission’s AWS infrastructure.

Why this matters: agentic IDE configuration files are committed to repos and reviewed with almost no scrutiny. They look like project setup. They execute with developer privileges at IDE-open time. Until April 2026, no malware had used them as a persistence mechanism. Now that the technique is public and documented, expect it to be copied. The broader campaign this worm is part of has compromised more than 1,000 SaaS environments, including the European Commission’s AWS infrastructure.

What I would do:

  • Review .claude/settings.json and .vscode/tasks.json files files in repos for SessionStart hooks or run0n: folderOpen tasks that point outside the repository root.
  • Set up alerts for these files being modified by non-human commit authors
  • Treat unexplained hooks in these files with the same scrutiny you would give a new CI/CD pipeline change
  • Search repository for “A Mini Shai-Hulud Appeared” – their presence confirms prior compromise (this may not be present in all cases).
Attack 2: The Agentic Tool That Ran Code Before Its Sandbox Started

On April 30, 2026, Google patched a vulnerability in Gemini CLI — the @google/gemini-cli npm package used in CI/CD pipelines via the google-github-actions/run-gemini-cli GitHub Actions workflow. The vulnerability carried a CVSS score of 10.0 — the maximum possible rating. It was discovered by Novee Security and reported across The Hacker News, The Register, and CSO Online.

The flaw: an attacker could place malicious content in a .gemini/ configuration directory that Gemini CLI would load and execute as configuration. The code ran before the agent’s sandbox initialised. An unprivileged attacker — including anyone who could submit a pull request to a public repository — could trigger arbitrary command execution on the CI runner.

This is not a theoretical attack. CI runners typically have access to repository secrets, deployment credentials, and cloud provider tokens. A compromised CI runner is a compromised deployment pipeline.

The vulnerability has been patched in Gemini CLI v0.39.1 and v0.40.0-preview.3. 

Why this matters: this is now the third confirmed case of an AI coding tool’s workspace configuration becoming an arbitrary code execution path — alongside Mini Shai-Hulud’s Claude Code hooks and a separately disclosed Cursor IDE flaw (CVE-2026-26268) discovered by researcher Assaf Levkovich. In CVE-2026-26268, a planted AGENTS.md file directs the Cursor agent into a bare git repository with a malicious post-checkout hook that fires silently outside the agent’s approval flow. Three vendors, three attack mechanisms, one pattern: every agentic tool that reads local configuration and executes based on it has a variant of this attack surface.

What I would do:

  • Update  @google/gemini-cli to ≥ v0.39.1 immediately
  • Pin the google-github-actions/run-gemini-cli action to a SHA commit reference rather than a mutable version tag
  • Update Cursor IDE to ≥ 2.2.5 (patches CVE-2026-26268)
  • Review any CI pipeline that runs an AI agent against pull request code from forks
Attack 3 — The Package That Looked Real Enough to Fool an AI

North Korean threat actors (tracked as Famous Chollima by researchers) have been running a campaign called PromptMink in which malicious npm packages are crafted specifically to deceive AI coding agents — not human developers.

The technique, coined “LLM Optimization abuse” by ReversingLabs, involves publishing packages with detailed, coherent documentation, plausible version histories, and standard utility branding — the signals an AI agent uses to judge whether a package is legitimate. The specific package, @validate-sdk/v2, was inserted into a real codebase by Claude Opus in February 2026. The AI was not compromised rather it was deceived: the package looked, to an AI evaluating it, like a legitimate hashing and validation utility. Details were also reported by The Hacker News.

The payload, once installed, exfiltrated developer credentials and cryptocurrency wallet data. The campaign has since evolved from JavaScript infostealers through large executables to compiled Rust payloads designed to evade detection.

Why this matters: developers are already using AI agents to suggest and install dependencies. If adversaries can craft packages that pass AI scrutiny — not just linting and malware scanners, but the model’s contextual judgment — then every AI-assisted dependency addition is a potential supply chain attack vector. The human reviewing the PR may see only the AI’s confident recommendation, not the package itself.

What I would do:

  • Treat any dependency added or suggested by an AI agent with the same scrutiny you would apply to a manual dependency addition — read the source, check the publisher history, verify the download count and community trust signals
  • Require AppSec sign-off for any new production dependency regardless of how it was suggested
  • Watch for packages that have disproportionately polished documentation relative to their download count and contributor history — this is a deliberate PromptMink signal
  • Extend your existing dependency scanning (Snyk, Socket, Dependabot) to flag newly introduced packages added via AI-agent commits

The Bigger Picture

These three attacks share a common thread: they all target the trust boundary between the AI tool and the developer environment. Agentic systems, by design, have broad access — they read files, execute commands, access environment variables, make API calls, commit code. That broad access is what makes them productive. It is also what makes them dangerous when the trust model is subverted.

Security teams built their threat models when developers were the decision-makers. AI agents are now co-decision-makers in many codebases. The threat model needs to catch up.

The practical response is not to stop using AI coding tools. It is to extend the same security controls that apply to human developers to the outputs and actions of AI agents. For security leaders, this means updating three programme areas that were never designed with AI agents in mind:

  1. Code review and CI/CD Policy: .claude/settings.json, .vscode/tasks.json, .gemini/, and equivalent files for other tools should be treated like CI/CD pipeline configuration — reviewed on every change, not merged silently. If your AppSec team reviews Jenkinsfiles and GitHub Actions workflows, they should review these files too. The attack surface is identical.
  2. Identity and commit attribution: Commits authored by an AI agent — identifiable by author name or email — modifying sensitive files are detectable in SIEM. Establishing a baseline of expected AI-agent commit patterns and alerting on deviations is a low-cost, high-signal control. This matters especially for detecting the Mini Shai-Hulud pattern, where a compromised developer token creates new commits that look like project maintenance.
  3. Dependency governance: The same process that governs a developer manually adding a production dependency should govern an AI agent doing the same. AI-introduced packages should trigger the same AppSec review as any other new dependency. If your organisation doesn’t have that process yet, PromptMink is the reason to build it.

Key Takeaways

  • Configuration files are now execution vectors. .claude/settings.json, .vscode/tasks.json, and .gemini/ directories can execute arbitrary code at IDE-open or CI-run time. Audit them like you audit CI pipelines.
  • Agentic tools in CI need the same scrutiny as production code. A CVSS 10.0 flaw in Gemini CLI executed before the sandbox started. Pin versions to SHAs, not mutable tags.
  • Adversaries are crafting packages to fool AI agents, not just humans. Review AI-suggested dependencies with the same rigour you apply to manual additions — and define who is accountable when an AI-introduced package causes a breach.
  • This is a confirmed pattern across three vendors. Mini Shai-Hulud (Claude Code), Gemini CLI CVSS 10.0, and Cursor IDE CVE-2026-26268 all exploit the same attack surface independently. Detection and response capabilities need to reflect this.

References

  1. Sophos — “‘Mini Shai-Hulud’ supply chain attack targets SAP npm packages” — https://www.sophos.com/en-us/blog/-mini-shai-hulud-supply-chain-attack-targets-sap-npm-packages
  2. Wiz — “Supply Chain Campaign Targets SAP npm Packages” — https://www.wiz.io/blog/mini-shai-hulud-supply-chain-sap-npm
  3. Onapsis — “Mini Shai-Hulud Supply Chain Attack on SAP CAP” — https://onapsis.com/blog/sap-cap-mini-shai-hulud-supply-chain-attack/
  4. Mend — “Shai-Hulud Strikes SAP: Supply Chain Worm Weaponized Claude Code” — https://www.mend.io/blog/shai-hulud-sap-cap-supply-chain-attack-claude-code/
  5. The Register — “Supply chain attacks worm into SAP npm packages, other dev tools” — https://www.theregister.com/2026/04/30/supply_chain_attacks_sap_npm_packages/
  6. The Hacker News — “SAP-Related npm Packages Compromised in Credential-Stealing Supply Chain Attack” — https://thehackernews.com/2026/04/sap-npm-packages-compromised-by-mini.html
  7. Novee Security — “Google Gemini CLI RCE Vulnerability: CVSS 10.0 Critical Security Advisory” — https://novee.security/blog/google-gemini-cli-rce-vulnerability-cvss-10-critical-security-advisory/
  8. The Hacker News — “Google Fixes CVSS 10 Gemini CLI CI/CD RCE (also covers CVE-2026-26268 / CursorJacking)” — https://thehackernews.com/2026/04/google-fixes-cvss-10-gemini-cli-ci-rce.html
  9. The Register — “Google’s fix for critical Gemini CLI vulnerability” — https://www.theregister.com/2026/04/30/googles_fix_for_critical_gemini
  10. CSO Online — “Max-severity RCE flaw found in Google Gemini CLI” — https://www.csoonline.com/article/4165470/max-severity-rce-flaw-found-in-google-gemini-cli.html
  11. ReversingLabs — “PromptMink: DPRK malware inserted into codebase via Claude” — https://www.reversinglabs.com/blog/claude-promptmink-malware-crypto
  12. The Hacker News — “New Wave of DPRK Attacks Uses AI-Optimized npm Malware” — https://thehackernews.com/2026/04/new-wave-of-dprk-attacks-uses-ai.html