
New research has found more than 800 software packages in the npm registry that differ from their registry entries, 18 of which were found to exploit a tool called obvious confusion.
The findings come from cybersecurity firm JFrog, which said threat actors could exploit the issue to trick developers into running malicious code.
Security researcher Andrey Polkovnichenko told The Hacker News: “This is a real threat because developers can be tricked into downloading innocent-looking software packages that hide ‘s dependencies are actually malicious.”

Manifest confusion was first documented in July 2023, when security researcher Darcy Clarke discovered that mismatches in manifests and package metadata could be weaponized to launch software supply chain attacks.
This issue stems from the fact that the npm registry does not verify that the manifest file contained in the tarball (package.json) matches the manifest data provided to the npm server during the publishing process via an HTTP PUT request to the package URI endpoint.
Threat actors could therefore exploit the lack of cross-validation by providing different manifests containing hidden dependencies that are processed during package installation to covertly install malicious dependencies onto a developer’s system.
“Visible or ‘fake’ manifests can mislead developers and even auditing tools that rely on data available in the npm registry repository,” JFrog said. “In fact, the installer fetches the file package.json from the tarball, which The file may differ from the visible file provided in the HTTP PUT request.”

The company said it discovered more than 800 packages where the manifest in the npm registry did not match the package.json file in the tarball.
While many of these mismatches are due to protocol specification differences or changes in script sections of the package files, 18 of them are said to be designed to exploit apparent confusion.
One problematic package of note is yatai-web-ui, which is designed to send an HTTP request to the server containing information about the IP address of the computer on which the package is installed.

The findings indicate that the attack vector appears to have never been used by threat actors. That said, it’s critical that developers take steps to ensure that packages don’t behave suspiciously.
“Since npm has not solved this problem, trusting packages solely by their appearance on the npm website can be risky,” Polkovnichenko said.
“Organizations should introduce procedures to verify that all packages coming into the organization or used by development teams are secure and trustworthy. Especially in cases of apparent confusion, each package needs to be analyzed to see if there are any hidden dependencies. “