Dependency Confusion Attacks: New Research Into Which Businesses are At Risk

Dependency confusion is becoming a serious cybersecurity threat. Learn which organizations are at risk and how to protect systems against these attacks.

Application development often requires the integration of third-party or open-source dependencies for efficient functionality and support of other features. However, there is now a reason for security professionals to be concerned about dependencies, as attackers can introduce malicious codes into applications through them.

Dependency confusion attacks are relatively new, though these cybersecurity threats have already shown they can cause a great deal of havoc to organizations. We share specifics from new security research about dependency confusion attacks, as well as explain how these attacks work, who is most at risk and how to mitigate them.

Jump to:

The state of dependency confusion attacks

New research from OX Security, a DevOps software supply chain security company, revealed that almost all applications with more than one billion users and more than 50% of applications with 30 million users are using dependencies that are vulnerable to dependency confusion attacks. The research also showed that organizations at risk are more likely to have 73% of their assets exposed to dependency confusion attacks.

The OX Security report’s findings are similar to a report earlier this year from Orca Security that found about 49% of organizations are vulnerable to a dependency confusion attack.

Examples of dependency confusion attacks

One notable example of a dependency confusion attack is the PyTorch malicious dependency package reported by PyTorch in December 2022. The organization warned users of a possible compromise of their Python Package Index code repository. In this incident, attackers installed a malicious dependency on their PyPI code repository and ran a malicious binary to enable them to launch a supply chain attack.

Another related incident occurred in 2022 when an attacker injected malicious code into the popular open-source package node-ipc. Within the period of this incident, millions of files were wiped from computers located in Russia and Belarus.

What is a dependency confusion attack?

In a dependency confusion attack, the attacker uploads a software package with the same name as an authentic one in your private repository to a public package repository. Having a software package with the same name in both private and public repositories can trick developers into using a malicious version of the package. When developers mistakenly fall for this or their package managers search the public repositories for dependency packages, their legitimate app could install malicious code that the hacker can exploit to launch an attack.

Dependency confusion is a form of supply chain issue. This topic attracted attention in 2021 when security researcher Alex Birsan disclosed in a Medium post that he breached more than 35 major companies, including Apple, Microsoft, Yelp and PayPal, using dependency confusion techniques.

Technical details of how dependency confusion attacks work

For dependency confusion to work, the hacker first identifies a package name in the private repository and registers the same package name in the public repository so that when a new update to the application is installed, it hooks with the malicious version on the public registry instead of the safe one in the private registry.

Speaking to TechRepublic, OX Security CEO and Co-Founder Neatsun Ziv explained that because hackers understand that most application package managers, such as npm, pip and RubyGems, check for dependencies on the public code repository before the private registry, they try to register the same package names in your private registry on the public registry. For instance, if a developer wants to install a package hosted on their private or internal repository but can’t reach the private repository where it’s stored, the developer’s dependency manager will attempt to find a similarly named package on a public registry and use that instead.

Figure A

Who might be impacted by dependency confusion attacks?

OX Security’s study, which examined more than 54,000 repositories in over 1,000 organizations across a wide range of sectors, including fintech, media and SaaS companies, found that organizations of all sizes are exposed to dependency confusion attacks. Ziv explained that most organizations are at risk because they use vulnerable packages or free-to-register public registries, which are vulnerable to dependency confusion attacks.

“These findings of our latest research are deeply disturbing, as these types of attacks not only compromise the integrity and security of organizational assets, but they potentially impact those organizations’ employees and users globally. Moreover, the fact that when an organization is at risk, a staggering 73% of their assets are vulnerable really sheds light on just how exposed many organizations, regardless of size or industry, really are,” said Ziv.

How to prevent dependency confusion attacks

According to Ziv, the most effective means to prevent dependency confusion is to reserve private package names in the public registry so nobody can register them in the public registry. Software developers can do this by going to package manager sites such as npm, if they’re using JavaScript, and then creating their account and registering the package name. By doing this, developers can prevent the attack at the source (i.e., the public repository) while also limiting the number of human error risks that expose their projects to dependency confusion attacks. Some of these human error risks include the lack of adequate code review, misconfigured build systems, lack of security best practices and unvalidated external dependencies.

Another way developers can deal with dependency confusion is by validating the package source before installing new packages or updating to an updated version. Fortunately, many package managers allow you to view a package before installing it.

Software developers can also prevent dependency confusion by using package managers that allow the use of prefixes, IDs or namespaces when naming their packages. This practice ensures that internal dependencies are fetched from private repositories.