Home / Knowledge hub / Malicious package
Knowledge hub
Malicious package
A published library built to steal data or run code on whoever installs it.
What it means
A malicious package is a library published to a public registry, such as npm or PyPI, with the purpose of harming the people who install it. It may steal environment variables and tokens, open a back door, or install other software.
Anyone can publish to these registries. The package may be new, with a name chosen to be mistaken for a popular one. Or it may be a real package whose account was taken over, and a bad version published.
Why it matters
Installing a package runs code on a developer's laptop or a build server, both of which hold valuable credentials: cloud keys, signing keys, repository tokens. One bad install can hand those over without any visible sign.
It is a major route in software supply chain security. MITRE lists compromising software dependencies as an initial access technique. The damage often lands far from the bad library itself.
How it shows up
The tricks repeat: typosquatting, dependency confusion, install scripts that run on install, and hijacked maintainer accounts. Signals include a very new package, a name close to a popular one, few downloads and unexplained install scripts.
Reduce the chance by using a private registry or proxy, pinning versions with a lockfile, disabling install scripts where you can, reviewing new dependencies and watching for odd behaviour in builds. Keep secrets out of build environments that do not need them.
Questions people ask
Malicious package, answered
How do malicious packages get on registries?
Anyone can publish. Attackers either create new packages with tempting names or take over an existing maintainer's account.
What do they usually do?
Common aims are stealing credentials and tokens from the environment, installing a back door, or mining cryptocurrency.
Does scanning find them?
Sometimes. Known bad packages are listed in advisory databases, but new ones may not be listed yet. Treat scanning as one layer.
Does a lockfile protect us?
It stops a surprise newer version from being pulled in. It does not help if the version you locked was already bad.
What should we check before adding a package?
Who maintains it, how old it is, how widely used, whether it has install scripts, and whether you need it at all.
Related
Terms that sit next to this one
Typosquatting
Publishing a package with a near-identical name, hoping a developer installs it by mistake.
Dependency confusion
Tricking a build into fetching a public package that shares a private package's name.
Install script risk
Code a package runs automatically the moment you install it.
Supply chain attack
Reaching you through a library, a build tool or a vendor you trust.
Private registry
An internal package store that keeps your private code off public indexes.
What ran when you installed it?
A bad library shows up as behaviour in your running app. We test that, and report only what we exploited. Ask us to run it on one of your applications.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.