~/f4n6 $ grep -r "AI agent plugins pose supply chain risk to developer machines and repos" ./investigations/ --include="*.md"

AI agent plugins pose supply chain risk to developer machines and repos

Jeff Davies 27 Oct 2026 6 min read

1. Executive summary

StepSecurity has released inventory tooling for AI coding agent plugins, covering both plugins installed on developer machines (Claude Code and Codex) and plugins published or enabled by GitHub repositories. The product announcement is not a report of an active compromise: no malicious plugin campaign is documented, and the three prior campaigns the vendor cites (Miasma, the JetBrains Marketplace plugin set, GhostAction) each used a mechanism a malicious plugin would depend on but none used a plugin. The exposure is structural. A plugin is a bundle that runs hooks and MCP servers as the developer, outside the agent's sandbox, on machines holding SSH keys, cloud credentials and publishing tokens, and its manifest identity is self-declared. For EMEA financial services the risk lands on engineering estates that hold production deployment credentials, which is most of them. No CVE has been assigned and no exploitation is recorded.

2. Regulatory framing

No specific DORA/NIS2 article is directly engaged by this item.

3. Technical analysis & attack chain

No attack chain is confirmed. The source describes a supply chain surface and cites three prior campaigns that used adjacent mechanisms; it states explicitly that none of them used an agent plugin. What follows separates the confirmed mechanics of the plugin surface from the prior incidents the vendor uses as precedent.

What a plugin is. A plugin is a folder containing a manifest, either .claude-plugin/plugin.json for Claude Code or .codex-plugin/plugin.json for Codex. One install can add skills, commands, subagents, hooks, MCP servers and LSP servers. A repository can publish several plugins, since any folder holding a manifest directory counts as a plugin folder (for example plugins/devtools/), and a folder with both manifests appears once with both agents.

Execution context. Per the Claude Code documentation cited by StepSecurity, an installed plugin can execute arbitrary code with the developer's user privileges. Hooks run as shell commands at lifecycle points such as before or after a tool call. A stdio MCP server runs as a process the agent starts on the machine. Claude Code adds a plugin's bin/ directory to the PATH of its Bash tool, and it runs hooks and MCP servers outside its sandbox. The same machine holds the developer's SSH keys, cloud credentials and publishing tokens.

Identity is self-declared. The publisher, homepage and repository fields in a manifest are typed by whoever wrote the manifest. Nothing verifies that a plugin claiming to come from a platform team was published by that team. StepSecurity's inventory flags publisher, description and homepage as self-declared metadata and treats a mismatch between the manifest's declared author or repository and the observed publishing repository and folder as the first thing to investigate.

Repository-level distribution. Claude Code can require plugins per repository through extraKnownMarketplaces and enabledPlugins in the repository's .claude/settings.json; the marketplace registers once a contributor accepts the workspace trust dialog for that folder. With auto-update enabled, marketplaces keep plugins refreshing in the background, so a change merged into a published plugin reaches developers without anyone running an install command. Publishing a plugin and enabling one are separate acts: publishing determines what developers install, enabling configures it for everyone working in a repository.

Prior campaigns cited as precedent (not plugin campaigns).

  1. Miasma, June: a compromised contributor account planted a .claude/settings.json file with a SessionStart hook in a Microsoft repository. The hook ran a credential-harvesting payload whenever a Claude Code session started there. Plugins can declare hooks, and .claude/settings.json is also where a repository enables plugins.
  2. Fifteen malicious JetBrains plugins posing as AI developer tools across seven publisher accounts on the JetBrains Marketplace collected roughly 70,000 installations over eight months and exfiltrated AI provider API keys developers entered.
  3. GhostAction, returning in October: two compromised maintainer accounts pushed a credential-stealing workflow to 345 repositories in automated windows lasting minutes.

Confidence caveats. The three campaign summaries are single-sourced to this StepSecurity post; the underlying incident reports were not reviewed for this advisory and the figures (70,000 installations, 345 repositories) should be verified against the original disclosures before use in client reporting. No indicators are given for any of the three. The plugin execution properties rest on StepSecurity's reading of Claude Code documentation, which is a secondary citation.

Detection surface the vendor exposes. Dev Machine Guard reads each agent's record of installed plugins and configured marketplaces at user and project scope, plus plugin manifests and declared components. The scan does not run any plugin, hook, script or agent CLI and makes no network requests; skill and command bodies, credentials and complete settings files stay on the device. Plugin metadata and definition hashes are reported. Old plugin files left in a cache directory are not counted as installations. A plugin installed but disabled remains on the device and can be re-enabled without a new install, so it stays in inventory. Source kinds recorded are github, local, npm, account and command; a plugin installed without a marketplace shows "No catalog". The Dev Machine Guard inventory requires agent v1.17.0 or later.

4. Mitigation & containment

P1, within 24 hours:

  • Inventory installed plugins across the developer fleet. If StepSecurity Dev Machine Guard is deployed, upgrade the agent to v1.17.0 or later and export the Agent Plugins inventory (IDE & AI Agents) as CSV. Without the tool, collect each agent's own record of installed plugins and configured marketplaces at user and project scope from developer endpoints.
  • Inventory what repositories distribute. Review the Agent Plugins view under GitHub > AI Agents, or enumerate .claude-plugin/plugin.json and .codex-plugin/plugin.json across organisation repositories. For each plugin, compare the manifest's declared author and repository against the repository and folder actually publishing it; treat any mismatch as a finding.
  • Identify repositories that enable plugins for all contributors by searching for extraKnownMarketplaces and enabledPlugins in .claude/settings.json. Confirm each entry is owned by a team you can name.

P2, within 72 hours:

  • Review every hook a published or installed plugin declares, by lifecycle event, before reading its command. Hooks run as shell commands outside the sandbox; a hook on SessionStart in a repository settings file is the Miasma pattern.
  • Decide a policy on marketplace auto-update. Background refresh means a merged change reaches developers with no install action; disable auto-update for marketplaces you do not control, or pin plugin versions.
  • Remove plugins that are installed but disabled where they are not needed. They remain executable without a new install.

P3, within 7 days:

  • Require manifest identity to be corroborated against the publishing repository for any plugin enabled organisation-wide, and record the plugin key for each approved plugin.
  • Add review of plugin folders and .claude/settings.json changes to the code review path for repositories that publish plugins, given that a single compromised maintainer account can change what every installer receives.

5. Indicators of compromise

No indicators of compromise available in the source material. The source names no hashes, domains, IP addresses, file names of malicious artefacts or command lines. The three prior campaigns are described only at the level of mechanism.

Behavioural indicators:

behaviour where to observe confidence
Plugin installed from a marketplace whose source kind is local, npm, account or command rather than a known catalog Agent plugin inventory, source kind field high
Manifest publisher, homepage or declared repository does not match the repository and folder publishing the plugin Plugin detail panel, declared metadata against observed source high
Plugin installed but disabled, still present on device Agent plugin inventory, enablement state high
SessionStart or other lifecycle hook declared by a plugin or in .claude/settings.json Plugin components list by event; repository settings file high
Repository settings enabling plugins for all contributors via extraKnownMarketplaces or enabledPlugins .claude/settings.json in organisation repositories high
Plugin bin/ directory placed on the Bash tool PATH Agent plugin components and process environment on developer host medium

6. Detection

The source gives no malicious artefacts: no hashes, no command lines, no mutexes, no malicious file names. The strings it does provide (plugin.json, extraKnownMarketplaces, enabledPlugins, SessionStart, .claude/settings.json) are legitimate configuration of the agent platform, not artefacts of a threat, so a YARA or Sigma rule built on them would match normal developer activity. No detection rules are authored.

Insufficient indicators to author detection rules.

7. Sources

  • StepSecurity, "StepSecurity Now Inventories AI Agent Plugins in Your GitHub Repositories and on Developer Machines", https://www.stepsecurity.io/blog/stepsecurity-now-inventories-ai-agent-plugins-in-your-github-repositories-and-on-developer-machines, 2026-10-27.

8. Adverse Trace position

Adverse Trace assesses this as a supply chain exposure notice, not an incident. No CVE has been assigned, no exploitation is recorded, and the vendor states plainly that no agent plugin campaign has occurred; the three cited campaigns are precedent for the mechanisms, and those summaries are single-sourced to this post and should be verified against the original disclosures before they are quoted to a regulator or a board. The client impact is concentrated in engineering environments where developer machines hold production credentials and where repositories can push plugin changes to every contributor without an install step, which is a configuration decision most organisations have not made deliberately. We will track the first disclosed malicious plugin and any indicators published with it, and we will re-issue this note if a campaign is confirmed. Clients running Claude Code or Codex at scale should complete the P1 inventory of installed and published plugins and send us the CSV export for review.


Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.

Post this to LinkedIn
Formatting is converted automatically — headings, bullets, a link back & hashtags. Paste straight in.
J
Jeff Davies