- Join BJ's Wholesale Club for $20, and get a $20 gift card: Deal
- Delivering better business outcomes for CIOs
- Docker Desktop 4.35: Organization Access Tokens, Docker Home, Volumes Export, and Terminal in Docker Desktop | Docker
- Cybercriminals Exploit DocuSign APIs to Send Fake Invoices
- Your iPhone's next iOS 18.2 update may come earlier than usual - with these AI features
New Tool Helps Devs Check For Manifest Confusion Mismatches
A security researcher has released a new tool designed to help developers check npm packages impacted by the recently discovered manifest confusion issue in the registry.
System administration and self-confessed hacker, Felix Pankratz, published the tool to GitHub on Monday, claiming the Python script can check npm packages for manifest mismatches, and also check all package dependencies recursively.
Read more on manifest confusion: Manifest Confusion Threat Undermines Trust in Entire Npm Registry
Manifest confusion came to light last week after former npm and GitHub manager, Darcy Clarke, revealed an issue with the npm registry that could potentially enable threat actors to hide malicious activity, as well as introducing other risks.
The issue itself arises from the fact that npm doesn’t validate manifest information (metadata) displayed in the registry with the actual contents of an associated package or “tarball.”
This means a malicious package publisher could conceal important information such as which dependencies it has and which scripts the package runs.
Manifest confusion could therefore be used by threat actors to install unknown/unlisted dependencies, execute unknown scripts and launch downgrade attacks. Developers could also be exposed to the risk of cache poisoning, where a saved package doesn’t match the name and version of the one in the registry, Clarke argued.
Pankratz has stepped up with a simple-to-use script for developers, in the absence of a formal response from npm or its owner, GitHub.
It was their six-month silence on the issue that first persuaded Clarke to go public with his findings.
“I believed the potential impact/risk of this issue was actually far greater than originally understood and I submitted a HackerOne report with my findings on March 9. GitHub closed that ticket and said they were dealing with the issue ‘internally’ on March 21st,” he explained last week.
“To my knowledge, they have not made any significant headway, nor have they made this issue public.”