Hades supply-chain worm shows AI coding tool hooks are executable risk

At a glance

What this is: This is an analysis of the Hades supply-chain worm and its use of committed AI coding-tool hooks to execute payloads when a repository opens.

Why it matters: It matters because developer AI workflows are becoming an identity and execution boundary, and committed configuration can now run with ambient permissions at repo-open time.

By the numbers:

• The campaign reached 73 Microsoft repositories this month.
• Between them the worm had staged on the order of 55 exfiltration repositories holding roughly 88 encrypted credential dumps.

Context

AI coding tools can execute project-scoped configuration when a session starts or a folder opens, which turns committed repo content into active instructions. In this case, that means the trust boundary is no longer just source code and build scripts, but also editor and assistant hooks that can run with the developer's permissions.

The governance gap is that teams often treat committed workspace settings as collaboration aids rather than executable input. Once an attacker controls those files, the same mechanism that standardises developer workflows can become a supply-chain detonator for non-human identity and agent-assisted development environments.

Hades is the current example, but the control problem is broader: any environment that automatically consumes committed configuration needs to distinguish between trusted policy and attacker-supplied instructions before execution starts.

Key questions

Q: What breaks when AI-generated code is only checked after commit?

A: Post-commit controls miss the moment when risky code is created, so secrets, insecure patterns, and policy violations can enter the repository before security ever sees them. That makes audit evidence incomplete and weakens defensibility. The practical failure is timing, because detection after commit cannot prove that policy was enforced at generation time.

Q: Why do repository-open attacks matter more than install-time supply-chain attacks?

A: Because they fire earlier in the workflow and need less user intent. A clone can detonate as soon as the assistant or editor loads the repo, so the attack surface includes trust decisions made before package installation or build execution ever happens.

Q: What signs indicate malicious AI assistant configuration in a codebase?

A: Look for newly added SessionStart hooks, folderOpen tasks, always-apply rules, or repository-scoped files that launch shell commands without user confirmation. Repetition of the same hook pattern across multiple repos is a strong indicator of propagation rather than routine setup.

Q: How should security teams contain a poisoned repository after discovery?

A: Freeze the repository, isolate affected runners or workstations, and remove any auto-executing assistant configuration before restoring trust. If a stolen token may still be active, assume it can spread the same configuration into other writable repositories.

Technical breakdown

Why repo-open hooks are executable risk

AI coding assistants often support lifecycle hooks such as session start, folder open, or pre-tool execution. Those hooks are useful because they let teams enforce consistent setup, but they also create a path where repository content becomes code-like input. If a malicious commit can place commands in project-scoped configuration, the tool will execute them with the developer's ambient permissions. That is not a vulnerability in the editor alone. It is the combination of committed configuration, automatic execution, and broad workstation authority that turns a clone into an execution event.

Practical implication: treat committed AI-tool configuration as executable code and review it before the repository is opened in any assistant.

How Hades spreads through AI coding-tool configuration

The campaign uses a single stolen GitHub token to commit malicious files such as .claude/settings.json, .gemini/settings.json, .vscode/tasks.json, and Cursor rule files into repositories the victim can push to. Different tools trigger in different ways, but the pattern is the same: session start, folder open, or always-apply rules cause the payload to run automatically. That makes the malicious configuration portable across editors and assistants. The malicious payload is not dependent on package installation or a build step, which is why the attack survives controls that only watch dependency management.

Practical implication: inventory every project-scoped file that can auto-run commands and apply the same scrutiny you would apply to build scripts.

Why CI/CD runners magnify the blast radius

CI/CD runners are especially dangerous because workspace-trust prompts are frequently disabled and the runtime often has broad access to secrets, tokens, and deployment credentials. In that setting, a malicious repo-open action does not just run code. It can exfiltrate ambient credentials and move the attack from a developer endpoint into pipeline infrastructure. The important governance point is that the threat is not limited to the first machine that opens the repository. Any environment that opens the same poisoned repo and has richer permissions becomes part of the blast radius.

Practical implication: apply separate controls for CI/CD runner trust and secret exposure, not just workstation hardening.

Threat narrative

Attacker objective: The attacker aims to use trusted repository workflows as an execution path for credential theft, persistence, and downstream supply-chain propagation.

1. Entry occurs when the attacker gets a stolen GitHub token and commits malicious AI coding-tool configuration into a repository the victim can push to.
2. Credential access follows when the poisoned hook executes on repo open or session start and steals additional credentials from the developer or runner environment.
3. Escalation happens as the worm copies itself into more repositories and plants persistence that can trigger destructive behavior if the stolen token is revoked.
4. Impact is credential theft, payload delivery, and broader supply-chain spread across repositories and AI coding workflows.

Breaches seen in the wild

• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Committed AI coding-tool configuration is now executable supply-chain input, not harmless workspace metadata. The attack works because project-scoped settings can trigger commands automatically when a repo opens or a session starts. That collapses the old assumption that only package managers and build scripts deserve execution scrutiny. Practitioners should treat editor and assistant configuration as part of the code execution boundary.

Repo-open trust is the new governance gap. Security teams have long focused on install-time compromise, but Hades shows that the opening of a cloned repository can be enough to detonate a payload. The problem is not just malicious code in the tree. It is the control assumption that an internal repository, once cloned, remains safe to trust before it is inspected.

Ambient developer authority amplifies machine-identity risk across the toolchain. The worm inherits the developer's permissions and then uses those permissions to write into additional repositories, which turns one stolen token into a multi-repository propagation event. That is a non-human identity problem, a workflow problem, and a governance problem at the same time. The implication is that repo-scoped automation needs the same containment model as any other privileged execution path.

AI coding workflows create a distinct identity blast radius. The named concept here is identity blast radius: the amount of access a poisoned assistant hook can reach once it is triggered. In this campaign, the blast radius spans local editor state, CI/CD runners, and downstream repositories because the tool executes in the user's context. Practitioners should measure where assistant-triggered execution can read, write, and persist before enabling it broadly.

The control failure is not visibility alone but trust placement. The campaign shows that scanning after the repo is opened is already late if the opening action itself triggers execution. That breaks the timing model many programmes rely on. The practical conclusion is that governance has to move upstream, to inspection of committed auto-executing configuration before first open.

From our research library:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• Read next: Shadow AI and AI Agent Discovery Guide

What this signals

Repo-open execution is now a governance boundary: teams should assume that committed assistant configuration can act before a developer has a chance to inspect it. That shifts policy from post-clone review to pre-open inspection for AI coding workflows.

The most useful control question is no longer whether the repository is trusted, but whether the files that control assistant behaviour are trusted enough to run. In practice, that means quarantine for new clones, strict handling for workspace-trust decisions, and tighter review of any file that can launch shell commands or agent actions.

A useful metric is how much of your developer and pipeline estate still accepts auto-running hooks from committed configuration without a human approval gate. Once that exists, the blast radius is no longer limited to source code.

For practitioners

• Review auto-executing AI tool files before first open Inspect .claude/settings.json, .gemini/settings.json, .vscode/tasks.json, Cursor rules, and similar project-scoped files before opening a cloned repository in any assistant or editor.
• Separate trusted workspaces from untrusted clones Use a quarantine workflow for newly cloned repositories so that workspace trust, auto-run hooks, and assistant initialization cannot execute before human review.
• Harden CI/CD runner permissions and secrets exposure Assume a poisoned repo can execute unattended in runners, and reduce ambient access so runner credentials, deployment tokens, and cloud secrets are not exposed to folder-open or session-start actions.
• Monitor for suspicious repo-scoped hook commits Watch for commits that add SessionStart hooks, folderOpen tasks, or always-apply agent rules, especially when the same change appears across multiple repositories.
• Treat stolen tokens as propagation tools, not isolated incidents If a GitHub token is compromised, assume it may be used to seed malicious configuration into every repository it can write to, and review downstream repos for copied hooks before restoring trust.

Key takeaways

• Committed AI coding-tool hooks turn repository content into executable input, which means repo-open can be the attack trigger rather than a harmless navigation step.
• The campaign reached 73 Microsoft repositories and staged dozens of exfiltration repositories, showing that a single stolen token can create a broad supply-chain footprint.
• The most effective containment point is before first open, by treating auto-executing assistant configuration as untrusted until it has been reviewed and isolated.

Key terms

• Repo-open execution debt: The gap between opening a repository for inspection and allowing content inside it to execute in the same session. In developer environments, this debt creates a hidden trust boundary where project files can act like commands before the user has granted explicit approval.
• Workspace Trust: A trust control in code editors that separates passive file viewing from active execution of project-defined tasks. When disabled or bypassed, the editor can run repository instructions in the user’s context, which turns source control content into an execution path.
• Assistant hook: An assistant hook is a lifecycle trigger that runs a command when a session starts, a tool is used, or a folder opens. In AI coding environments, hooks are powerful because they enforce workflow consistency, but they also create an execution surface that attackers can abuse through committed configuration.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.