Malicious Dependencies

What are malicious dependencies?

A malicious dependency is a software package intentionally created or altered to cause harm when included in an application. Unlike a typical vulnerability that results from accidental flaws, these dependencies are crafted by attackers to steal data, insert backdoors, or break functionality.

They are especially dangerous because development relies on open source ecosystems like npm, PyPI, and Maven Central. Developers often trust packages without fully reviewing the code, giving attackers a way to slip in harmful components. Incidents like a PyTorch malicious dependency, a malicious dependency withdrawn after discovery, or cases where a malicious dependency destroyed apps across ecosystems show how damaging these attacks can be.

Understanding the risks of malicious dependencies is central to software supply chain risk management. Without visibility, organizations may unknowingly embed adversarial logic into their systems.

How malicious dependencies infiltrate your software supply chain

Malicious dependencies typically enter through trusted package ecosystems. Attackers exploit the openness of these platforms and the speed at which developers adopt third-party code. Once published, even briefly, a harmful package can spread across countless downstream projects.

Some of the most common infiltration methods include:

• Typosquatting attacks: Attackers upload a package with a name similar to a popular dependency (for example, reqeusts instead of requests). Developers who mistype the name unintentionally install the malicious version.
• Dependency confusion: Also known as “namespace confusion,” this technique takes advantage of mismatched naming between private and public registries. A developer’s build system may pull a malicious public package instead of an internal one.
• Hijacked maintainer accounts: Open source projects often rely on a small group of maintainers. If one of their accounts is compromised, attackers can push a malicious update to a widely used package.
• Compromised build pipelines: Attackers inject code during the build or publishing process, resulting in a trusted package version that secretly contains malicious logic.
• Withdrawn but already installed dependencies: A malicious dependency withdrawn from a registry may continue to exist in builds that cached the package before removal, allowing infections to persist.

These infiltration paths are difficult to detect with traditional security tools. While scanners identify known vulnerabilities, they often miss malicious packages because the code is designed to look legitimate. This has led to high-profile campaigns, such as the GitHub repo confusion attack, where adversaries successfully inserted malicious code into trusted repositories.

By understanding how dependencies are weaponized, security teams can implement safeguards such as dependency pinning, strict registry controls, and continuous monitoring. Apiiro’s AI-powered detection capabilities demonstrate how code-to-runtime context can help spot these risks earlier and reduce their impact.

Warning signs of a malicious or withdrawn dependency

Detecting a malicious dependency before it causes harm is challenging, but certain patterns can raise red flags. Many of these indicators can be spotted by carefully reviewing package metadata, version history, and code behavior.

Unlike ordinary vulnerabilities, malicious packages are designed to evade detection. Teams need continuous visibility into their dependency tree, combined with runtime context, to catch these signs early. Open tools like PRevent combined with practical steps to prevent malicious code can help teams establish stronger safeguards.

Real-world examples of malicious dependencies in action

High-profile incidents demonstrate the destructive potential of malicious dependencies. In 2022, a malicious version of the popular PyTorch library was distributed through a compromised dependency, resulting in credential theft attempts from thousands of developers. Similarly, npm has seen waves of malicious packages uploaded to impersonate trusted libraries, leading to destroyed apps and stolen data. 

These examples highlight how malicious dependencies can infiltrate widely used ecosystems and impact enterprises at scale. Lessons learned include the importance of dependency pinning, supply chain scanning, and continuous monitoring for withdrawn or replaced packages.

Frequently asked questions

What makes a dependency “malicious” rather than simply vulnerable?

A malicious dependency is intentionally crafted to cause harm, while a vulnerable one contains unintentional flaws. The difference lies in intent, malicious packages are designed to steal data, inject backdoors, or corrupt applications.

How can you tell if a PyTorch or similar dependency has been compromised?

Warning signs include unusual network activity, suspicious maintainers, or sudden version changes. Community alerts, registry advisories, and runtime monitoring tools help detect a PyTorch malicious dependency or similar compromise.

Are there automated ways to detect withdrawn or spoofed packages?

Yes. Automated dependency monitoring tools and anomaly detection systems can flag suspicious updates, mismatched checksums, or when a malicious dependency withdrawn reappears under a different name.

Can dependency pinning prevent malicious versions from being installed?

Pinning reduces risk by locking to specific, trusted versions, preventing unexpected updates. However, if the pinned version itself is compromised, pinning cannot protect against malicious code.

What’s the difference between dependency confusion and malicious dependencies?

Dependency confusion tricks build systems into pulling a public package instead of a private one. Malicious dependencies are harmful packages directly published or altered to exploit applications. Both threaten the software supply chain.