Stolen credentials bypass npm provenance, AI assistants auto-execute malicious code

Sigstore was supposed to be npm's answer to supply chain trust. Instead, it became a credential-laundering service. When the system works perfectly while attackers use it to distribute malware, the problem isn't the technology. It's the assumption that automation can replace human accountability.

Trust systems fail when they stop asking who is actually in control

The May 2026 npm attacks exposed something uncomfortable about how we've built developer security infrastructure. Sigstore did exactly what it was designed to do. It verified that packages came from a legitimate build environment, that valid certificates were issued, and that everything was logged transparently. The system performed flawlessly. The attacker won anyway because Sigstore cannot tell whether the person holding the credentials actually authorized the publish. That gap—that single point where human intent matters—turned the strongest automated trust signal in the ecosystem into a false positive machine.

This is not a flaw in Sigstore's implementation. It is a flaw in how we've come to think about trust in software. We've spent years automating verification while assuming the credentials themselves would remain secure. That assumption was always fragile. It is now broken.

How attackers turned stolen accounts into legitimate-looking packages

In 48 hours, attackers compromised maintainer accounts and published 633 malicious package versions that passed Sigstore verification. The Nx Console attack on May 18 showed the speed: a stolen credential published a malicious VS Code extension that harvested API keys, tokens, and vault contents from 6,000 developer machines in under 40 minutes. The Mini Shai-Hulud campaign hit 502 packages across npm, PyPI, and Composer. Researchers at Endor Labs, Socket, and StepSecurity documented seven distinct attack surfaces that failed in parallel—credential theft, MCP server auto-execution, unprotected API key storage in development tools.

The real problem is verification divorced from ownership

We built Sigstore to solve a real problem, but we solved it in isolation. The system verifies the mechanics of how a package was created without addressing the prior question: does the person publishing this package still control their own account? That is not a technical question. Cryptography cannot answer it alone.

What makes this worse is that the attacks exploited not just Sigstore but the entire stack of developer tools that have normalized auto-trust. Claude Code, Gemini CLI, Cursor, and Copilot all default to executing project-defined MCP servers the moment a developer accepts a folder trust prompt. On CI runners, there is no prompt at all. Johns Hopkins researchers demonstrated that a malicious GitHub PR title could trick Claude Code into posting its own API key as a comment. The system worked as designed. The designer's assumption—that a developer would notice and stop the process—was wrong.

Sigstore is caught in the same trap. It verifies the package. It does not verify the person. When credentials are stolen, verification becomes indistinguishable from legitimacy.

The gap between what we audit and what attackers actually hunt

The Verizon 2026 Data Breach Investigations Report found that 67% of employees access AI services from non-corporate accounts on corporate devices. Source code is now the leading data type submitted to unauthorized AI platforms, which is exactly what these attacks targeted. CrowdStrike documented STARDUST CHOLLIMA tripling its operational tempo against financial services, using AI-generated recruiter personas and fake technical assessments to harvest GitHub PATs, npm tokens, AWS keys, and CI/CD secrets.

The audit grid that researchers published maps seven attack surfaces, and no vendor framework currently scopes all of them. We have built verification systems that work perfectly within their narrow scope while remaining blind to the credential theft that happens outside that scope. Sigstore cannot see that an npm token was stolen from a developer's unprotected storage. It can only verify that the token was used correctly.

Automation cannot replace the question of who authorized this

The path forward is not to make Sigstore smarter or to add more layers of verification. The path forward is to accept that some questions cannot be answered by machines. When a maintainer's account publishes a package, someone needs to verify that the maintainer actually intended it. That might mean rate limiting, anomaly detection, or human review for high-impact packages. It definitely means stopping the assumption that a valid certificate is the same as a valid decision.

The developers using these tools need to know that their credentials are the weakest link in the chain, and that no verification system can compensate for compromised accounts. The vendors building these tools need to stop defaulting to trust and start asking for explicit human consent at every privilege boundary. And the maintainers publishing packages need to understand that Sigstore verified the package, not the decision to publish it.

Original reporting from VentureBeat AI. Read the original article.