Safety Academy · Story 15 · Look-alike npm packages

Two letters. Too much access.

A misspelled software package nearly joins Ken’s payment demo.

Estimated 4 min read

LOOK-ALIKE NPM PACKAGES6 scenes

Ken adds a payment helper to a demo.

Ken is building a café payment demo. The verified project docs name @demo/payments, but his proposed dependency says @demo/paymetns. These illustrative package names differ by two transposed letters.

Ken

“One dependency. Ten minutes saved.”

Illustration: Ken adds a payment helper to a demo.

These package names are invented. The risk is confusing two different packages.

The look-alike has a convincing description.

The registry page repeats the expected description, but the publisher is different. The scammer has copied the shop window and replaced what is inside.

The Scammer

“Five stars. All from my imagination.”

Illustration: The look-alike has a convincing description.

Popularity claims and familiar text do not authenticate a package.

The package can run more than the demo.

Before installing, Ken reviews the package change and finds an install script. His work computer contains credentials. Installing a dependency can execute code with the access available to his user.

Ken

“Why does a payment helper have an install script?”

Illustration: The package can run more than the demo.

Installed code may run with access available to your user or build process.

Capitano Ritas compares the exact package identity.

Capitano Ritas compares the exact package name with the project’s official docs, then checks publisher, source and new scripts. Reading a familiar description would have missed the substitution.

Capitano Ritas

“Two letters changed. Apparently that includes who gets your secrets.”

Checking only the package description misses the substitution.

Ken rejects the typo and reviews the intended package.

Ken rejects the lookalike before it runs. He evaluates the intended dependency separately without valuable secrets, reviews its version and records the choice.

Ken

“Two letters nearly became a security incident.”

Illustration: Ken rejects the typo and reviews the intended package.

Disabling install scripts can reduce one risk. It does not make runtime code trustworthy.

The project never runs the impostor.

The demo never executes the impostor. Disabling install scripts can reduce one risk, but later runtime code still needs trust. Autocomplete has been demoted from security reviewer.

Ken

“Autocomplete needs adult supervision.”

Illustration: The project never runs the impostor.

Treat a new dependency as new code you are choosing to trust.

The useful bit

One misspelled dependency can put an attacker’s code in your project.

Copy package names from the official docs and compare them letter by letter. Check the publisher and the source.
Read install scripts and dependencies before you install. Try unknown code on a machine with no credentials.
Pin the versions you reviewed. Blocking install scripts helps, but it does not vet what runs later.

OWASP: npm security ↗

I already did this

If the package ran, stop using that machine for secrets and alert your security team. Review what it could access; revoke and replace exposed service credentials from a clean setup. Removing the dependency does not invalidate stolen credentials. Wallet-key exposure needs a separate wallet response.