- La colaboración entre Seguridad y FinOps puede generar beneficios ocultos en la nube
- El papel del CIO en 2024: una retrospectiva del año en clave TI
- How control rooms help organizations and security management
- ITDM 2025 전망 | “효율경영 시대의 핵심 동력 ‘데이터 조직’··· 내년도 활약 무대 더 커진다” 쏘카 김상우 본부장
- 세일포인트 기고 | 2025년을 맞이하며… 머신 아이덴티티의 부상이 울리는 경종
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.”