Malicious npm Package Caught Stealing Files From Developers’ Machines

A malicious npm package discovered in the wild was silently stealing sensitive files from developers’ machines — the latest in a growing wave of supply chain attacks targeting the JavaScript ecosystem and the millions of developers who depend on it.

What Happened?

Researchers identified a malicious package published to the npm registry — the world’s largest software package repository, used by JavaScript and Node.js developers globally — that contained hidden code designed to exfiltrate files from any machine that installed it. The package was crafted to appear legitimate, using a name designed to either mimic a popular trusted package (typosquatting) or fill a plausible gap in the ecosystem.

Once installed, the malicious code ran silently in the background, scanning the developer’s filesystem for sensitive files and transmitting them to attacker-controlled infrastructure. The package accumulated downloads before being discovered and removed from the registry — meaning an unknown number of developers may have had their systems compromised without any indication that anything was wrong.

What Data Was Targeted?

File-stealing malware targeting developers is particularly damaging because developer machines tend to hold an unusually high concentration of sensitive material:

• Source code and intellectual property — proprietary codebases, unreleased features, and internal tools
• Configuration files — .env files, config.json, and similar files often containing API keys, database credentials, and service account details
• SSH private keys — granting access to servers, cloud infrastructure, and Git repositories
• AWS, GCP, and Azure credentials — cloud provider configuration files (e.g. ~/.aws/credentials) can give attackers full access to cloud environments
• Browser-stored passwords and session cookies — enabling account takeover without needing passwords
• npm authentication tokens — allowing the attacker to publish further malicious packages as if they were the compromised developer, extending the supply chain attack

How npm Supply Chain Attacks Work

The npm registry operates on a model of trust: any registered account can publish packages, and once a package gains downloads and dependents, it acquires a reputation that later versions inherit. Attackers exploit this in several ways:

Typosquatting

Publishing packages with names almost identical to popular legitimate packages — for example, lodahs instead of lodash, or cros-env instead of cross-env. Developers who mistype a package name install the malicious version instead.

Dependency Confusion

If an organisation uses internal packages with names that don’t exist on the public npm registry, an attacker can publish a public package with the same name. npm’s default resolution logic may resolve the public (malicious) version over the private internal one.

Account Takeover

If a legitimate package maintainer’s npm account is compromised — through credential stuffing, phishing, or reused passwords — the attacker can publish a malicious update to an existing, trusted package. This is particularly dangerous for packages with millions of weekly downloads.

Malicious Pull Requests

Attackers submit legitimate-looking contributions to open-source packages, building trust over time before eventually submitting a pull request containing malicious code.

The Scale of the Problem

The npm registry hosts over 2.5 million packages and serves billions of downloads per week. The sheer volume of packages makes comprehensive security review impossible through manual means alone. Security researchers and automated scanning tools identify thousands of suspicious packages each year — but the registry’s scale means some inevitably slip through before detection.

The JavaScript supply chain is particularly complex because of the deep dependency trees common in modern Node.js projects. A typical application may directly depend on 50 packages but have hundreds or thousands of transitive dependencies — packages that your packages depend on. Each one is a potential attack surface.

How to Protect Your Development Environment

1. Audit your dependencies regularly — Run npm audit to check for known vulnerabilities, and consider tools like Socket.dev or Snyk that specifically look for suspicious package behaviour beyond known CVEs
2. Use lockfiles and pin versions — package-lock.json or yarn.lock ensure you install the exact version you tested with, rather than automatically pulling in new versions that may contain malicious code
3. Enable npm’s security features — Configure two-factor authentication on your npm account and enable publish notifications so you are alerted to any new versions published under your account
4. Scan for secrets before committing — Use pre-commit hooks with tools like detect-secrets or git-secrets to prevent credentials from ending up in repositories
5. Treat developer machines as high-value targets — Apply the same endpoint security standards to developer workstations as to servers: EDR, full-disk encryption, restricted outbound connections, and regular patching
6. Review package provenance before installing — Before installing a new package, check: when was it published? How many downloads does it have? Is there a legitimate GitHub repository? Are there recent issues or reports? A package with 15 downloads and no GitHub presence deserves extra scrutiny
7. Rotate any credentials that may have been exposed — If you have installed packages you didn’t fully vet, treat any credentials stored in your development environment as potentially compromised and rotate them

BIT Tech and Developer Security

Software supply chain security is increasingly a concern for businesses of all sizes that have development teams or commission software development. BIT Tech IT Solutions can help you assess your development environment security and implement controls to reduce supply chain risk. Contact our team to discuss your needs.