Ostorlab detects Dependency Confusion

Dependency Confusion is a new attack with high severity impact. This article is an overview of the vulnerability as well as other supply chain attacks.

Wed 03 March 2021


Alex Birsen published novel research showcasing how he could compromise build environments, CI/D pipelines, and developers’ workstations leveraging leaked private package names.

The new vulnerability is another supply chain attack commonly referred to as Dependency Confusion or Substitution Attack.

The root cause is linked to external package management systems, these usually offer the possibility to deploy private repositories to host internal-only packages.

During the build process, the package manager does not prioritize the private repositories, but the ones with the highest version.

This behavior can be leveraged by an attacker by creating a malicious package on the public repository and using a high enough version to ensure the malicious package is the one used during build time.

Sonatype has reported detecting a 430% increase in new packages exploiting the vulnerability with malicious payloads within a few days of the vulnerability announcement.

Dependency hijacking affects all pieces of software and particularly mobile applications, as they often leak private package names.

Ostorlab has added support for detecting leaked dependency names and reports the ones vulnerable to Dependency Confusion on NPM.

Ostorlab team is investigating the exploitability and detectability of other package managers, namely Cocoapods, Maven, Gradle, Cordova, Xamarin Nuget, and Flutter.

I am vulnerable, what should I do?

NPM packages offer the possibility to set the scope to packages. Scoped packages on the public npm registry may only be published by the user or organization associated with it, and packages within that scope may be made private. Also, scope names can be linked to a given registry.

  "name": "@ostorlab/dep1",
  "version": "1.2.3",
  "description": "Scoped dependency 1",
  "dependencies": {
    "@ostorlab/dep2": "1.2.3"

The used scope must be created beforehand to ensure an attacker can't take it over. To create a public scope, apply the following instructions:

The scoped registry can be configured by including a similar line in the .npmrc file:

@ostorlab:registry = https://reg.ostorlab.internal/

More Dependencies, More Vulnerabilities

Ostorlab detects other forms of supply chain and dependency vulnerabilities.

It lists compiled dependencies from Gradle, Maven, Cocoapods, Xamarin, Cordova, and Javascript. Listing compiled dependencies addresses limitations of source code dependencies, like identifying transitive dependencies; these are dependencies of dependencies, and which versions are some not explicit and are only determined at build time.


Ostorlab detects statically compiled dependencies, commonly vulnerable to high severity vulnerabilities, like memory corruption. For mobile applications, common dependencies are image parsing and image compression libraries, like libpng, libjpeg and libtiff. Ostorlab can also detect over 70 native libraries like libxslt, zlib, openssl, libcurl and many more.

Ostorlab can detect known vulnerabilities affecting these packages and it maintains its own curated database of unreported vulnerabilities. Ostorlab vulnerability database contains 1.3 Million entries and is continuously getting updating.


These classes of vulnerabilities are all covered by the community scanner.