Notifications
Clear all
Topic starter
22/06/2026 10:17 am
TL;DR: Hades turns committed AI coding-tool configuration into an execution path, triggering credential theft and payload delivery when a cloned repository opens in Claude Code, Gemini, Cursor, or VS Code, according to Pillar Security. The campaign shows that repo-open trust assumptions, not just package installs, now define the attack surface for developer AI workflows.
NHIMG editorial — based on content published by Pillar Security: Your agents answer to Hades: how one commit hijacks 4 AI coding tools
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.
Questions worth separating out
Q: How should security teams handle repository files that can run automatically in AI coding tools?
A: Treat them as executable input, not documentation.
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.
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.
Practitioner guidance
- 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.
- 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.
What's in the full article
Pillar Security's full research covers the operational detail this post intentionally leaves for the source:
- The exact malicious file set used to trigger Claude Code, Gemini, Cursor, and VS Code at workspace start.
- The loader and persistence behaviour behind the Bun-based payload, including how it reacts to token revocation.
- The recovered indicators of compromise from the samuelrizerio/setup dropper and the forged commit patterns seen in the campaign.
- The defensive handling sequence for suspected infected hosts, including the order of isolation, cleanup, and token revocation.
👉 Read Pillar Security's analysis of the Hades supply-chain worm and AI coding hooks →
AI coding tool hooks and repo-open attacks: are your controls ready?
Explore further
22/06/2026 11:06 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Hades supply-chain worm shows AI coding tool hooks are executable risk
