AI coding assistants can suggest typosquatted npm packages

When your AI assistant recommends a package that doesn't exist yet

I ran into something unsettling a few months ago. A colleague pasted a ChatGPT response into Slack, asking if I'd heard of a utility package it had recommended. The name sounded plausible. Hyphenated, npm-idiomatic, exactly the kind of thing you'd expect to exist. I hadn't heard of it. Neither had npm.

That package has since been registered. We have no idea by whom.

This is the hallucination-to-hijack pipeline, and it's more systematic than most developers realize. Large language models are trained on snapshot data. They invent package names, sometimes because a package they half-remember has a slightly different name, sometimes because they're completing a plausible-sounding pattern. The names they generate are often just credible enough to install without checking.

Attackers have noticed.

How the attack works

The mechanics are straightforward. An attacker monitors npm for newly registered packages with names that pattern-match to what AI assistants commonly hallucinate. They can also take a more targeted approach: prompt a model repeatedly with the same kind of task, collect the invented package names, and register the ones that aren't taken.

Then they wait.

A developer asks their AI assistant how to parse an edge-case date format, or validate an obscure file type, and the model produces something like:

npm install date-utils-extended

The developer copies it. Doesn't check npmjs.com. Doesn't look at the package's publish date or who maintains it. They run the install, it works (because the attacker made it work, at least on the surface), and a malicious postinstall script runs silently in the background.

This is not a theoretical attack. Typosquatting on npm has caused real incidents for years. The AI-hallucination variant is just a new source for the same vector, and it's more dangerous because the developer has been told the package name by something that sounds authoritative.

The postinstall problem

The postinstall lifecycle hook is the standard delivery mechanism. A package.json like this is all it takes:

{
  "name": "date-utils-extended",
  "version": "1.0.0",
  "scripts": {
    "postinstall": "node steal.js"
  }
}

The steal.js file runs at install time, before you've read a single line of source. It has access to your environment variables, your filesystem, and anything else readable by your current user, including ~/.npmrc which may contain auth tokens. By the time you notice something is wrong, the damage is done.

This is not a warning about bad packages in general. It's a warning that your AI tool is actively generating package names that don't exist, and attackers are registering them.

What you should actually do

Check before you install. That sounds obvious, but the friction of copying a terminal command is so low that most people don't pause. Make it a habit to open the npm registry page for any package you haven't used before.

# Before running this:
npm install date-utils-extended

# Check the registry first:
open https://www.npmjs.com/package/date-utils-extended
# Look at: publish date and weekly download count

A package published last week with near-zero downloads is worth scrutinizing closely. That's not proof of malice, but it's a signal.

You can also audit a package after install:

npm ls date-utils-extended
cat node_modules/date-utils-extended/package.json | grep -A5 '"scripts"'

If there's a postinstall script you weren't expecting, remove the package and investigate.

For teams, adding ignore-scripts=true to your .npmrc as a default prevents lifecycle scripts from running during install. This breaks some legitimate packages, but it's a reasonable trade-off in a security-sensitive environment.

# .npmrc
ignore-scripts=true

You can then audit packages and re-enable scripts explicitly where needed.

The verification gap

The real problem is that AI assistants have no mechanism to verify that a package exists, let alone that it's safe. They're language models. They generate plausible text. "Plausible" and "correct" are not the same thing, and in the context of supply chain security, the gap between them is exploitable.

I'm not saying stop using AI assistants. I'm saying treat every package name they generate as unverified until you've checked it yourself. The model doesn't know whether that package exists. It doesn't know who registered it or why. That responsibility stays with you.

Most developers I've spoken to haven't thought about this attack specifically. They've considered typosquatting in the abstract, but not the fact that their AI tool is a hallucination engine producing new typosquatting targets on demand, multiple times per day, for every developer using it. That's a fundamentally different threat model from someone typo-ing a package name manually.

Seaworthy flags suspicious and unverified dependencies as part of its dependency hygiene checks.