The NPM (Node Package Manager) registry suffers from a security flaw called “manifest confusion”, which undermines the reliability of packages and allows attackers to hide malware in dependencies or execute malicious scripts when facility.

NPM is a package manager for the JavaScript programming language and the default for the widely used Node.js environment. The Package Manager helps project owners automate the installation, upgrade, and configuration of software packages hosted on the “npm Registry” database at npmjs.com.

In 2020, the platform was acquired by Microsoft via GitHub, and today it is estimated that more than 17 million software developers worldwide use it, downloading 208 billion packages per month.

Darcy Clarke, a former GitHub engineer, pointed out the obvious problem of confusion in an article on his blogexplaining that although his former employer has been aware of the issue since at least November 2022, little has been done to address the associated risks.

The NPM registry is also extremely popular among developers because it contains a wide assortment of packages that can be used to extend an application’s functionality without requiring additional development work.

However, its popularity makes it a prime target for threat actors to distribute malicious packages to take control of developer computers, steal credentialsor even deploy ransomware.

Obvious confusion

Clear confusion occurs, there is an inconsistency between a package’s manifest information presented on the npm registry and the actual ‘package.json’ file in the published npm package tarball used when installing the package .

The manifest data submitted to NPM when publishing a package and the package.json contains information about the package name, version, and other metadata, such as scripts used in the deployment, build dependencies, etc

Both are submitted separately to the npm registry, and the platform does not validate if they match, so their data could differ, and no one would know unless they looked at their contents.

This allows a threat actor to modify submitted manifest data with a new package to remove dependencies and scripts so that they do not appear in the NPM registry. However, these scripts and dependencies still exist in the package.json file and will be executed when installing the package.

This “obvious confusion” is illustrated in the image below, showing that there are no dependencies listed on NPM for Clarke’s proof-of-concept package, even though there are dependencies listed in the package. json.

Risks that arise from the “obvious confusion” inconsistency include cache poisoning, installation of unknown dependencies, execution of unknown scripts, and potentially also downgrade attacks.

“And to be clear, it’s not just about hidden dependencies,” Socket CEO Feross Aboukhadijeh warned BleepingComputer, who said their tools are not affected by this issue.

“The obvious confusion also allows an attacker to include hidden install scripts as well. These hidden scripts and dependencies will not appear on the npm website or in most security tools, even if installed by the npm CLI.”

Unfortunately, the npm community and all major package managers, including npm@6, npm@9, yarn@1, and pnpm@7, are impacted by this issue.

Unfortunately, this leads to a lack of trust in the NPM registry as dependencies, version numbers, and even package names may not be accurate.

Instead, developers must manually read the package.json to determine version numbers, dependencies that will be installed, and scripts that will be run.

Issue still unresolved

Clarke says GitHub has been aware of the obvious confusion issues since at least 2022, and a bug report filed on the npm CLI GitHub repository regarding the node-canvas package seems to confirm this.

The engineer submitted a detailed HackerOne report that featured examples of the issue on March 9, 2023.

On March 21, 2023, GitHub closed the ticket, responding that they were handling the issue internally. Yet they have yet to address the risks and communicate them to the npm community.

Clarke mentions that due to the sheer size of npm and the fact that it has been following this dangerous practice for many years, solving this problem is far from trivial.

Until GitHub develops a plan to deal with the manifest confusion over npm, Clarke suggests that package authors and maintainers remove dependency on manifest data and instead source all metadata except the name and the version of the ‘package.json’ files which are less prone to manipulation.

Another protective measure would be to use a registry proxy between the package database and the npm client, which could implement additional checks and validations to ensure consistency between the data in the manifest and the information in the package tarball.

BleepingComputer has contacted GitHub about the issue, and we’ll update this post as soon as we receive a response.