Malicious Package.

What Is a Malicious Package?

A package is a bundle of reusable code that developers add to their projects. Open-source packages are shared through public registries, and the tools that fetch them include npm and pip. A malicious package carries harmful code. The harmful code may come from a package made to look useful, or from a real package that an attacker altered.

MITRE ATT&CK describes this under compromising software dependencies and development tools. It says adversaries may manipulate software dependencies and development tools before the user receives them. It lists compromising popular open-source packages, typosquatting, and targeting CI/CD pipelines such as GitHub Actions. CI/CD pipelines are the automated steps that build and deliver software.

How Do Poisoned Packages Reach Developers?

MITRE describes dependency poisoning of widely used packages in registries such as npm and pip. It also describes re-registering removed or abandoned packages to distribute malware, and using names similar to legitimate libraries to deceive developers.

For detection, MITRE points to suspicious package manager activity, such as unexpected file writes to dependency directories and unusual network connections to unfamiliar registries after install lifecycle hooks run. Lifecycle hooks are scripts that run automatically around an install.

What Does a Real Case Look Like?

CISA published an alert about a self-replicating worm in the npm ecosystem that compromised over 500 packages. CISA says the malware scanned environments for sensitive credentials, including GitHub personal access tokens and API keys for AWS, GCP and Microsoft Azure. It says the worm used an automated process to spread by authenticating to the npm registry as the compromised developer and injecting code into other packages.

How Does a Poisoned Package Spread?

This flow follows the npm worm that CISA described in its September 2025 alert. Other cases can differ. See also the Shai-Hulud incident page and valid accounts, since stolen tokens act as logins.

Why Does a Trusted Channel Make It Worse?

A malicious package arrives through a channel developers already trust, so it may not look like an attack. One package can be a dependency of many applications, so a single change can reach many users. In the case CISA described, the stolen credentials were also used to spread the code further. This is a reason to treat dependencies as part of your attack surface.

How Do You Pin and Audit Dependencies?

These steps come from MITRE and CISA.

• Lock dependencies to specific versions instead of pulling the latest release, and pin GitHub Actions to a specific commit hash rather than a tag or branch.
• Require developers to pull from internal repositories of verified and approved packages rather than external ones.
• Keep software updated and monitor vulnerability sources, with automated code review tools.
• Audit dependencies through lock files, rotate developer credentials and enforce phishing-resistant multifactor authentication on developer accounts, as CISA advised in the npm alert.

Is a Malicious Package the Same as a Vulnerable Package?

No. A vulnerable package has an honest flaw that could be abused. A malicious package has been built or changed to cause harm.

Is It the Same as a Supply Chain Attack?

Not exactly. A supply chain attack is the wider idea of attacking through a supplier or a component. A malicious package is one common way it can happen. Related terms are supply chain attack, typosquatting and SBOM.

Related Pages in the Knowledge Hub

• Shai-Hulud npm worm
• Supply chain and vendor risk

Sources

• MITRE ATT&CK: MITRE ATT&CK says adversaries may manipulate dependencies and development tools before users receive them, including open-source packages, typosquatting and CI/CD pipelines.
• CISA: CISA alert on a self-replicating npm worm that harvested credentials and injected code into other packages, with recommendations to pin versions, rotate credentials and require phishing-resistant MFA.