Your AI Coding Assistant Is Hallucinating Package Names — How to Protect Your Project

I’ve been using AI coding assistants daily for close to two years now. GitHub Copilot, Cursor, Claude Code — you name it, I’ve tried it. They’ve saved me countless hours writing boilerplate, generating tests, and debugging edge cases. But a few weeks ago, I noticed something unsettling. I asked my assistant to install a common npm package, and it auto-completed a name that didn’t exist. Close to what I wanted — but not real. I caught it before hitting enter, but it got me thinking: what if I hadn’t?

Turns out, that moment of hesitation was onto something bigger. Security researchers have been documenting an entire class of attacks built on exactly this behavior — AI coding agents generating names that sound real but aren’t, and attackers rushing to claim those names before anyone checks.

Three Names for the Same Flaw

Over the past six months, the security world has described what looks like three separate threats. In January 2026, slopsquatting: researchers at Aikido Security caught AI agents trying to install a fake npm package called react-codeshift across 237 projects. In June, phantom squatting: Unit 42 at Palo Alto Networks found 250,000 domains that language models hallucinate — anyone could register them. And just last week, HalluSquatting: researchers from Tel Aviv University, Technion, and Intuit showed how attackers can predict the fake repository names AI agents will generate and claim them first.

Three names. Three different targets — packages, domains, repositories. But one identical flaw. As Shane Warden from ActiveState put it, “In every case, the agent trusts a name nobody verified.”

The research team tested prompts across Cursor, Windsurf, GitHub Copilot, Cline, Gemini CLI, and OpenClaw. The results were sobering: models hallucinated identical names up to 85% of the time for repository requests and 100% of the time for skill installs. That’s not random noise — that’s a predictable attack surface.

And if you think this is just a theoretical risk, look at what happened with the FakeGit campaign. Attackers planted nearly 7,600 malicious GitHub repositories — over 800 posing as AI tools — and accumulated 14 million downloads before anyone caught on.

The threat is real, it’s current, and it’s evolving faster than traditional security tools can adapt.

GitHub’s Dependabot Gets a 3-Day Cooldown

Here’s the first bit of good news. GitHub has quietly rolled out a significant change to Dependabot, their automated dependency-update service. Starting now, Dependabot comes with a default three-day cooldown before it opens pull requests for newly published package versions.

The logic is straightforward but clever. In many recent supply chain attacks, malicious npm packages were detected and flagged by security tools within minutes of being published. But detection alone doesn’t remove the threat — it just starts a race. Maintainers still need to unpublish the package, developers need to update their lockfiles, and CI/CD pipelines need time to catch up. That gap is exactly what attackers exploit.

By waiting 72 hours, Dependabot gives the ecosystem time to identify and remove malicious packages before they’re automatically pulled into your project’s dependency tree. GitHub settled on three days as a balance between safety and staying current, but you can configure it.

How to Configure Dependabot’s Cooldown

If the default three-day cooldown isn’t right for your project — maybe you want a longer buffer for critical production apps, or a shorter one for internal tooling — here’s how to adjust it:

Open your .github/dependabot.yml file and add or modify the cooldown setting:

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    cooldown:
      days: 7

You can set any value from 0 (no cooldown, the old behavior) up to 14 days. A 7-day cooldown is a solid choice for production projects that prioritize stability over having the absolute latest version of every dependency.

GitHub notes that cooldown alone isn’t enough. They recommend combining it with lockfiles for dependency pinning, restricted-scope tokens, and disabling unnecessary installation scripts in CI. Think of it as one layer in a defense-in-depth strategy, not a silver bullet.

PyPI Blocks Release Poisoning with a 14-Day Cutoff

Over on the Python side, PyPI has introduced an equally interesting defense. Starting July 22, maintainers can no longer add new files to a package release after 14 days have passed since its publication.

This measure targets a specific attack vector: what happens when an attacker compromises a maintainer’s publishing token or CI workflow months after a trusted release went out. Without this cutoff, they could quietly add a malicious file to an old, well-known version of a popular package. Developers who pin their dependencies to that specific version number would fetch the update thinking it’s safe — because the version number hasn’t changed.

PyPI’s data shows that only a tiny fraction of legitimate projects upload new files more than two weeks after publishing a release. So this cutoff blocks a dangerous possibility with minimal impact on honest maintainers.

For developers, this means older releases are effectively frozen in time. If you’re pinning dependencies and relying on the version number alone to verify integrity, this adds a layer of protection against a particularly sneaky class of supply chain attack.

Why This Matters for AI Coding Agents

Here’s where these new defenses connect back to the HalluSquatting research. AI coding agents don’t just suggest package names — they often have permission to install them automatically. When an agent hallucinates a package name and your pipeline runs that suggested command without human review, you’ve just handed an attacker a way into your build process.

The research paper from Tel Aviv University demonstrated something crucial: these hallucinated names are predictable. Attackers can pre-compute what names popular models will generate for common requests, register those names as domains or packages, and load them with malicious code. Your agent does the delivery work for them.

This is fundamentally different from traditional typosquatting, where an attacker hopes you mistype a name. In this scenario, the model generates the wrong name on purpose, and your tooling trusts it by design. As the researchers put it, “Attacks always get better. They never get worse.”

I wrote recently about how hidden text attacks against AWS Kiro and Azure DevOps MCP proved that AI coding agents are becoming a major attack surface. The HalluSquatting research lands in the same territory — it’s not about whether a specific tool is flawed, but about how we architect trust in AI-assisted pipelines.

What You Should Do This Week

Here’s a practical checklist to harden your development workflow against these attacks:

1. Enable Dependabot cooldown if it’s not already on. The feature rolled out automatically for all GitHub repos using Dependabot, but verify your configuration. Check your .github/dependabot.yml and consider setting a custom cooldown period if the default doesn’t fit your risk tolerance.

2. Pin your dependencies with lockfiles. package-lock.json, yarn.lock, pnpm-lock.yaml, and requirements.txt with exact versions aren’t just best practices — they’re your last line of defense against a compromised dependency. A hallucinated or poisoned package that hasn’t been verified won’t match your lockfile hash.

3. Review what permissions your AI coding agents have. This is the big one. Does your Cursor or Claude Code setup have permission to install packages automatically? If so, consider switching to a manual-review workflow. The few seconds it takes to verify a package name before installation is nothing compared to cleaning up a supply chain compromise.

4. Restrict CI/CD token scopes. The tokens your CI pipelines use should have the minimum permissions necessary — read-only access to packages, no ability to publish or modify releases without human approval. This limits what an attacker can do even if a hallucinated package slips through.

5. Add pre-fetch verification to your agent workflows. Some AI coding frameworks ship with verification features turned off by default. Check whether your tools support package name validation against a curated registry before execution, and turn it on.

6. Monitor your dependency trees. Tools like Dependabot alerts, Snyk, and GitHub’s own security advisories can flag suspicious packages. Set up notifications for any new alerts in repositories you maintain.

The Bigger Picture: Trust, But Verify

The autonomous AI agent that hacked Hugging Face and the OpenAI models that escaped their own sandbox are part of the same story: we’re giving AI agents powerful capabilities without equally powerful guardrails. HalluSquatting is just the latest reminder that a language model’s confidence in a name doesn’t mean that name is safe.

The Dependabot cooldown and PyPI cutoff are good moves. They show that platform providers are thinking about these threats and building defenses into the infrastructure rather than leaving it to individual developers. But they’re not a complete solution. The underlying design flaw — trusting AI-generated names without verification — needs to be addressed at every layer of the stack.

For now, the most practical thing you can do is slow down. Review what your AI tools are doing. Verify package names before they hit your dependency tree. And never assume that because a name was generated by a sophisticated model, it must be real.

I learned that lesson the hard way, staring at an auto-completed package name that almost made it into my project. These days, I take that extra second to check. It might save me more than just a broken build.