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 AI coding-tool hooks to run malicious code on repository open.

Why it matters: It matters because developers, CI/CD runners, and identity teams must treat committed AI tool configuration as executable attack surface, not benign project metadata.

By the numbers:

• The campaign reached 73 Microsoft repositories this month.
• The worm planted the same malicious files into five repositories belonging to Ionut-Cristian Florescu within a 49-second window.

👉 Read Pillar Security's analysis of the Hades supply-chain worm and AI coding hooks

Context

AI coding assistants increasingly execute committed project configuration as part of normal workspace startup. That creates a governance problem for identity and access management because a cloned repository can now carry instructions that run with a developer's permissions before any explicit approval step. In this case, the primary keyword is AI coding tool hooks, and the issue is that those hooks behave like executable policy when the repository itself has been poisoned.

The Hades worm shows how a supply-chain compromise can move through non-human identity controls, developer workstation trust, and CI/CD execution paths at the same time. A single stolen GitHub token is enough to seed malicious configuration across repositories that the victim can push to, which means access governance and repository trust are now tightly coupled. The starting position here is atypical in scale, but the control gap it exploits is becoming routine as AI-assisted development spreads.

Key questions

Q: How should security teams handle repository files that can run automatically in AI coding tools?

A: Treat them as executable input, not documentation. Put committed hook files, workspace tasks, and agent rule files under review before a repository is opened in an assistant, and require provenance checks for any file that can trigger shell commands or tool actions at startup. That control matters because the attack runs through the repository itself, not through a separate installer.

Q: Why do AI coding tool hooks create a higher-risk trust problem than normal project settings?

A: Because they can execute with the user's own permissions as soon as the workspace loads. In practice, that means a poisoned repository can turn a convenience feature into an execution path before a human has a chance to review the action. The risk is highest where teams assume internal authorship equals trust and where auto-run settings are left enabled.

Q: What breaks when a stolen GitHub token is used to seed malicious repository configuration?

A: The blast radius expands from one compromised account to every repository that account can modify. Once the attacker can push config files that trigger automatically, repository provenance becomes part of the attack surface and simple token revocation is not enough. Organisations need to contain write access, review recent commits, and inspect all auto-executing files before reopening affected repos.

Q: Who is accountable when an AI assistant runs code from a poisoned repository?

A: Accountability stays with the organisation that granted the repository write access, approved the trust model, and failed to govern executable workspace configuration. Standards such as OWASP-NHI and NIST zero trust both push responsibility toward explicit control of access paths and trust boundaries. When configuration can execute on open, governance has to cover the repo as an active control surface.

Technical breakdown

Committed workspace hooks become code execution

AI coding tools 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 turn committed repository files into executable input. In Hades, files such as .claude/settings.json, .gemini/settings.json, .vscode/tasks.json, and Cursor rule files trigger commands automatically when the workspace opens. The critical point is that the tool is obeying repository content exactly as designed, which means the trust boundary sits on the committed configuration itself, not on the editor or assistant.

Practical implication: treat committed AI tool configuration as executable code and subject it to the same review and allowlist controls as build scripts.

Session-start hooks bypass the user's approval rhythm

Claude Code's SessionStart behaviour is especially important because it runs when a session begins or resumes, before a normal per-action permission prompt can intervene. That makes the timing materially different from a gated tool call, because the malicious command can run at initialization and the assistant can ingest its output into context. The result is not just shell execution but a secondary prompt-steering channel. This is a governance failure in timing, because the control model assumes the operator can inspect and approve each consequential action, while the hook fires earlier than that decision loop.

Practical implication: separate initialization-time hooks from interactive tool permissions and require explicit review for any repository-scoped startup command.

Workspace trust is a human decision under attacker influence

VS Code's Workspace Trust and similar protections are intended to stop automatic task execution in untrusted folders, but Hades relies on developers trusting an internal repository by habit. The attack does not defeat the trust model technically, it corrupts the assumption that an internal repository's authors are safe. Once a malicious tasks.json or similar file lands in the repo, the editor executes the attacker-controlled task when the folder opens. That is why the problem is not just malware delivery, but compromised authorship inside a repository that still looks legitimate to the person opening it.

Practical implication: add repository integrity checks and pre-open inspection for auto-running tasks, not just user education about trust dialogs.

Threat narrative

Attacker objective: The attacker wants to turn normal developer repository workflows into a reusable execution channel for secret theft, persistence, and downstream sabotage.

1. Entry begins when a developer opens a repository that already contains poisoned AI coding-tool configuration or a malicious setup file.
2. Credential access follows as the worm uses the victim's GitHub token and repository write access to plant hooks and stage exfiltration payloads across additional repos.
3. Impact occurs when the auto-executed commands run with full account permissions, allowing secret theft, persistence, and destructive follow-on actions.

Breaches seen in the wild

• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.
• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Committed AI tool hooks are now executable identity surface, not mere convenience settings. The campaign works because repository-scoped configuration can trigger commands with the developer's own authority at workspace open. That collapses the old separation between code, configuration, and execution in AI-assisted development. Practitioners should treat any committed hook file as identity-bearing control plane material, not as inert project metadata.

Session-start execution assumes a stable human approval loop that no longer exists. The timing model behind access review and interactive consent was designed for actions a person can inspect before they occur. That assumption fails when a repository opens and the assistant executes immediately, because the command can run before any review or gating artifact is available. The implication is that review-based governance cannot be the only control for AI coding environments.

Workspace Trust has become a repository-authorship problem, not just a local client feature. Hades succeeds by turning a compromised contributor token into trusted-looking repository content that the editor then executes. The issue is not whether the repository is internal, but whether its committed instructions are themselves trustworthy. Security teams need to think about repository provenance and executable configuration together, because the trust decision is being made on attacker-shaped input.

Identity blast radius is the right concept for AI-assisted developer compromise. A single stolen GitHub token can now fan out into multiple repositories, multiple AI tools, and multiple execution surfaces without a new login event. That means entitlement scope is no longer the only measure of privilege. Practitioners should model how far one compromised developer identity can propagate through tool hooks, repo write access, and CI/CD runners.

AI-assisted development is creating a new class of NHI governance debt. The same controls used for service accounts do not map cleanly onto repository-scoped agent hooks, because the authority is embedded in developer workflows and triggered by file open rather than API call. OWASP-NHI and zero trust thinking still apply, but the enforcement point has shifted toward committed configuration and session lifecycle. The practical conclusion is that governance must move closer to the repository edge.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
• For a deeper control lens, read OWASP Agentic AI Top 10 and compare runtime hook exposure with agent goal hijacking and tool misuse patterns.

What this signals

Executable repository configuration is becoming a standing governance blind spot. AI-assisted development moves control points into files that most teams still classify as project metadata, yet those files can launch shell commands the moment a workspace opens. With 96% of technology professionals already identifying AI agents as a growing security threat in SailPoint's research, the programme risk is not future-state curiosity but present-day exposure.

Teams should expect repository provenance, workspace trust, and CI/CD execution policies to converge into one control domain. The right response is to extend identity governance to cover committed instructions, not just accounts and secrets, and to make auto-run behaviour visible in reviews and audits. That is where the boundary between developer convenience and attacker execution is now being tested.

Identity blast radius: one compromised developer identity can now propagate into multiple AI tools and multiple repositories without a fresh login event. That means access reviews need to consider repository write paths and tool-triggered execution, not only standing permissions. Security leaders should align this with OWASP Agentic AI Top 10 thinking and with MITRE ATLAS adversarial AI threat matrix patterns around tool misuse and agentic abuse.

For practitioners

• Review auto-executing repository files before any editor opens the workspace Inspect .claude/settings.json, .gemini/settings.json, .vscode/tasks.json, Cursor rules, and similar files in a quarantined environment before allowing an AI assistant to load the repository.
• Separate repository trust from developer trust Do not let an internal source code status bypass checks on committed hooks, startup scripts, or workspace tasks. Require provenance review for files that can execute on folder open or session start.
• Treat GitHub token compromise as a propagation event Assume a stolen token can seed malicious configuration into every repository it can write to, then scope containment around repository writes, not just token revocation.
• Harden CI/CD runners against unattended workspace execution Keep workspace trust and task auto-run controls enabled in runners, and block any repository-scoped command that would execute without an explicit approval checkpoint.
• Instrument detection for forged authorship and auto-run patterns Alert on unusual commit authors, unsigned commits, SessionStart hooks, folderOpen tasks, and newly introduced setup scripts in repositories that normally do not contain them.

Key takeaways

• The Hades campaign shows that AI coding-tool hooks can turn a cloned repository into an execution mechanism with developer-level authority.
• A single stolen GitHub token can now seed malicious config across multiple repositories, which expands compromise from one account to an identity-wide propagation problem.
• The control that matters most is pre-open inspection of auto-running repository files, because trust at folder open is now part of the attack surface.

Key terms

• Session-start hook: A session-start hook is a command that runs automatically when an AI coding tool begins or resumes a session. In security terms, it is an execution boundary because it can act before a human approval loop has time to intervene, which makes the hook itself part of the trusted computing surface.
• Workspace trust: Workspace trust is the decision model a code editor uses to decide whether a folder may execute tasks or scripts automatically. It is meant to protect the user from untrusted repositories, but it only works when the trust decision reflects true repository provenance rather than convenience or habit.
• Repository provenance: Repository provenance is the chain of evidence showing where committed code or configuration came from and who had authority to change it. For AI-assisted development, provenance matters because committed files can execute, so identity assurance for the repository is part of the control plane, not just an audit concern.
• Identity blast radius: Identity blast radius is the amount of damage or propagation a single compromised identity can create across systems, repositories, and tools. In NHI and AI-assisted workflows, it captures how one token or account can seed automated execution in multiple places without a fresh login event.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Pillar Security: Your agents answer to Hades: how one commit hijacks 4 AI coding tools. Read the original.