A typical React or Next.js project pulls in hundreds of packages, and each one is code written by someone else. That convenience is also a risk. A 2026 web development report cited by industry writers claims that npm supply chain attacks rose by around 150% between 2024 and 2026. We cannot verify that figure independently, but security teams broadly agree that attacks on package ecosystems are a growing problem.
How these attacks work
- Malicious packages: attackers publish a package with a name close to a popular one (typosquatting) and wait for someone to install it.
- Account takeover: a maintainer's account is compromised and a bad version of a legitimate package is published.
- Dependency confusion: a public package is given the same name as a private internal one.
- Install scripts: code that runs automatically when a package is installed and can steal secrets from developer machines or build servers.
- Abandoned packages: a package that is no longer maintained is taken over by someone else.
The damage can include stolen API keys, cloud credentials, customer data and code injected into your production site.
Habits that reduce risk
In your project
- Commit your lockfile (package-lock.json or equivalent) and install with
npm ciin builds so versions are exact. - Pin and review upgrades. Update on purpose, read the changes for important packages and avoid blindly accepting "latest".
- Add fewer dependencies. Ask whether you really need a package for a small task.
- Check before installing: age, maintainers, download history and repository activity.
- Consider a short delay before adopting brand-new versions, because malicious releases are often found and removed within days.
- Run audits with
npm auditand a service such as Dependabot, Renovate or Snyk, and act on serious findings. - Limit install scripts where you can, for example with
--ignore-scriptsfor packages that do not need them.
On your machines and servers
- Keep secrets out of the repository and out of build logs.
- Use short-lived, least-privilege tokens in CI.
- Turn on two-factor authentication for npm, GitHub and your cloud accounts.
- Build in clean, isolated environments.
- Use a secret scanner to catch leaked keys early.
For production
- Add a Content Security Policy to limit what scripts can run in the browser.
- Monitor for unusual outbound traffic and unexpected file changes.
- Keep backups and a rollback plan.
- Keep an inventory of your dependencies (an SBOM) so you can respond quickly when a package is reported as compromised.
If you think you installed something bad
- Stop the build and isolate the machine.
- Rotate every secret that could have been exposed.
- Remove the package, reinstall from a clean lockfile and review recent changes.
- Check logs for signs of misuse.
Security is part of delivery
We build web apps with locked dependencies, automated checks and secure deployment pipelines. Talk to KalzTech if you would like a dependency and pipeline review.
Frequently asked questions
What is an npm supply chain attack?+
It is an attack that targets the packages your project depends on, for example through a malicious package, a hijacked maintainer account or a compromised update, so bad code reaches your app.
Does npm audit protect me completely?+
No. It reports known vulnerabilities but may miss newly published malicious packages. Combine it with lockfiles, careful updates, least-privilege tokens and monitoring.
What should I do first if a package I use is reported as compromised?+
Check whether you installed an affected version, rotate any secrets that could have been exposed, reinstall from a clean lockfile and review logs for misuse.
Have a project in mind?
Tell us what you're building and we'll reply within one business day.
- +91 86259 45569
- info@kalztech.in
- Chat on WhatsApp
- Pune, Maharashtra, India
