The hallucinated dependency attack: a new supply chain surface AI created

In March 2024, Lasso Security published the first quantitative study of package hallucinations in LLM-generated code. They prompted four major models with 2,500 programming queries and measured how often the generated code imported a package that did not exist. The aggregate hallucination rate was 5.2% for GPT-4 and 21.7% for open models. More than 200,000 distinct hallucinated package names appeared across the runs. The follow-up work in 2025 and 2026 has only confirmed the pattern: every coding agent in production today produces some fraction of imports that reference packages with no corresponding entity on the registry.

The attack vector is straightforward. An attacker monitors public hallucinations or generates them at scale by prompting models. They identify package names that are hallucinated frequently enough that any moderately-sized engineering team will eventually have one suggested. The attacker registers those names on npm, PyPI, RubyGems, or crates.io with a malicious payload, typically a post-install script that exfiltrates environment variables, drops a backdoor, or scans the host. The attacker waits. Engineers prompt their coding agents. The agent suggests an import. The engineer accepts. The install runs. The payload runs.

This is the same threat model as typosquatting attacks, with one important difference. In typosquatting, the attacker bets that a human will mistype urllib3 as urlib3 and the typo lands on the malicious package. In hallucination attacks, the AI does the typing. The volume of typing is much higher, the variation in mistakes is much wider, and the developer doing the install never typed the package name themselves, which removes the usual cognitive check.

Socket.dev and other supply chain security trackers have documented dozens of confirmed cases in 2025 and 2026 where malicious packages were planted against hallucinated names that LLMs were observed to suggest. The most public was the npm package node-srvexec which was suggested by Copilot in development contexts, registered by an unknown party in mid-2025, and contained a child process spawn that scraped process.env and posted it to a Discord webhook. It survived on npm for six weeks before being delisted. Downloads in that window numbered in the thousands.

The OWASP Top 10 for LLM Applications, in its 2025 revision, named this category LLM03 Supply Chain Vulnerabilities. The threat is recognized at the standards level. The mitigation pattern at the standards level remains vague. This post is the mitigation pattern.

What makes the attack reliable#

Three properties of the modern dev environment converge to make hallucinated dependency attacks effective.

Install commands run with shell privileges. npm install, pip install, cargo build, and equivalent commands run scripts in the package author's control as part of the install. postinstall hooks in JavaScript, setup.py in Python, build.rs in Rust. The payload does not need to wait for the imported function to be called. It runs the moment the dependency is fetched.

Developers paste install commands without reading them. The agent suggests npm install some-package. The developer copies the command and runs it. The shell does not flag that some-package is a new entity. The output of npm install does not flag that the package has zero prior downloads, was published yesterday, has no maintainer history, or has unusual permissions in its postinstall script.

CI pipelines mirror the developer behavior. The CI runner pulls the manifest, runs install, and ships the build. The install step has shell access to whatever secrets the runner has access to. If the runner has access to production deploy keys, the malicious package has access to production deploy keys. The blast radius is the entire trust boundary of the build environment.

The combination is the supply chain version of a phishing attack at the package level. The lure is plausibility. The payload is whatever the install hook does.

Three pre-install checks that block the attack#

The mitigation is to interrupt the install at the point where new dependencies are being added, verify them against signals the attacker cannot easily fake, and block the install if the signals look wrong.

Check 1. Registry existence and metadata signals. Before the install runs, scan the diff against the lockfile for new packages. For each new package, query the registry directly for the package metadata. Block the install if any of these signals are present: package was published less than 30 days ago, package has fewer than 100 historical downloads, package has no associated GitHub repository, package was first published by a maintainer account that has only published this one package. None of these signals on their own confirms an attack. The combination is rare for legitimate dependencies and common for planted ones.

- name: New-dependency signal scan
  run: |
    new_pkgs=$(git diff origin/main -- package-lock.json \
              | grep '^+.*"version"' \
              | grep -oP '"\K[^"]+(?=")' \
              | sort -u)
    for pkg in $new_pkgs; do
      meta=$(npm view "$pkg" --json 2>/dev/null || true)
      if [ -z "$meta" ]; then
        echo "Hallucinated or unregistered: $pkg"
        exit 1
      fi
      created=$(echo "$meta" | jq -r '.time.created')
      age_days=$(( ( $(date +%s) - $(date -d "$created" +%s) ) / 86400 ))
      if [ "$age_days" -lt 30 ]; then
        echo "Suspicious new package: $pkg created $age_days days ago"
        exit 1
      fi
    done

Adapt the registry queries for Python (pip index versions), Rust (cargo info), or Ruby (gem info).

Check 2. Signature and provenance verification. npm supports package provenance attestations via Sigstore as of 2023, and adoption has accelerated through 2025 and 2026. Reject any new dependency that does not have a valid provenance attestation if it was published after the date the team enabled the policy. Most legitimate widely-used packages now publish attestations. Most planted packages do not. The bar is easy to set, and the false positive rate is manageable.

Check 3. Manifest-restricted human review on transitive expansion. When a new direct dependency adds more than a small number of transitive dependencies, route the PR to a human for a manifest-only review before the install runs. The reviewer does not have to audit the code. They have to confirm the package and its dependency expansion is something the team wanted. This catches the case where the agent suggests a legitimate-looking name and the dependency it pulls in is itself a vector. A threshold of 5 new transitive packages per direct addition is a starting point. Tune to the stack.

What this is not#

These checks do not catch every supply chain attack. They do not protect against compromise of a legitimate package. They do not protect against compromise of the registry itself. They do not protect against a maintainer who legitimately publishes a malicious update after gaining trust.

What they catch is the specific failure mode AI coding agents enable: the hallucinated name that does not exist, gets registered, and ships an attack to teams whose install pipelines are not configured to notice that the package being installed is new and suspicious.

What to do this week#

Audit the last 90 days of new direct dependencies added to the repos. For each, check the package's age and download count at the time it was added. Flag anything that was less than 30 days old or had fewer than 100 downloads at install time. If the list is empty, the team's review process caught the risk through other means. If it has anything on it, add at least the registry existence check to CI before next week.

The attack surface is documented. The mitigations are short. The tradeoff is a few seconds of additional CI time against a class of attack the standard pipeline does not see.