Mind Blowing Facts

Valid certificates, stolen accounts: how attackers broke npm's last trust signal

Featured visual

The Illusion of Trust: How Valid Certificates Became a Weapon in the npm Supply Chain

In the world of software development, trust is everything. For years, the npm ecosystem has relied on cryptographic signatures and provenance verification as its last line of defense against malicious code. But on May 19, that defense was turned against itself. Over 633 malicious npm package versions passed Sigstore’s provenance verification—not because the system failed, but because it worked exactly as designed. The attacker had valid signing certificates, issued from a compromised maintainer account. The result? A chilling paradox: the very tools meant to signal trust became the perfect camouflage for one of the most sophisticated supply chain attacks in recent memory.

This wasn’t a flaw in Sigstore. It was a flaw in the assumption that valid credentials equate to legitimate intent. The system verified the package was built in a CI environment, confirmed a valid certificate was issued, and logged everything in the transparency log. But it couldn’t determine whether the person holding the credentials had actually authorized the publish. In cybersecurity, this is known as the authorization gap—a chasm between authentication and intent that attackers are increasingly exploiting.

💡Did You Know?
Sigstore was co-founded by Google, Red Hat, and Purdue University to make software supply chains more transparent. It uses a public, immutable ledger called Rekor to log every signing event, making tampering detectable. Yet, as this attack shows, transparency alone can’t stop misuse when credentials are stolen.

The Nx Console Breach: A 40-Minute Heist with Global Reach

Just one day before the npm onslaught, a quieter but equally devastating attack unfolded in the Visual Studio Code extension ecosystem. On May 18, version 18.95.0 of the Nx Console extension—a tool used by over 2.2 million developers—was published using stolen credentials. The update went live and stayed active for less than 40 minutes before being pulled. But in that brief window, telemetry data revealed a staggering 6,000 activations, most triggered automatically by VS Code’s update mechanism.

This wasn’t just a numbers game. The payload was meticulously designed to harvest sensitive developer secrets: Claude Code configuration files, AWS keys, GitHub tokens, npm tokens, 1Password vault contents, and Kubernetes service account tokens. These aren’t just login details—they’re digital keys to entire development infrastructures. With access to AWS keys, an attacker could spin up cloud resources, mine cryptocurrency, or exfiltrate data. GitHub tokens could grant write access to private repositories. The scope of potential damage is enormous.

What makes this attack particularly insidious is the auto-update behavior of modern development tools. Most developers never manually check extension updates. They trust the ecosystem to deliver safe, incremental improvements. But when that trust is weaponized, even a 40-minute window can become a global breach vector.

💡Did You Know?
Auto-updates are a double-edged sword. While they patch vulnerabilities quickly, they also allow malicious code to spread silently. In 2020, the CodeCov breach exploited a similar mechanism, affecting over 10,000 organizations through a compromised bash uploader script.

The Mini Shai-Hulud Campaign: A Worm in the npm Ecosystem

At 01:39 UTC on May 19, a new threat emerged: the Mini Shai-Hulud campaign, named after the sandworms from Dune for its ability to burrow through dependencies. Attributed by researchers to TeamPCP, a financially motivated threat actor, the attack began with two long-dormant packages: `jest-canvas-mock` and `size-sensor`. Neither had seen an update in over three years. Their sudden revival with a 498KB obfuscated Bun script was a red flag—but only if your tooling was watching.

By 02:06 UTC, the worm had spread across the `@antv` data visualization ecosystem and dozens of unscoped packages, including `echarts-for-react`, which boasts over 1.1 million weekly downloads. Endor Labs and Socket Security tracked the fallout: 639 compromised versions across 323 unique packages in this single wave. Across npm, PyPI, and Composer, the total reached 1,055 malicious versions across 502 packages.

The attacker didn’t just inject malware—they embedded full Sigstore integration into their payload. This meant every malicious package carried a valid provenance attestation, making it appear trustworthy to automated scanners and developers alike. It was a masterclass in abusing trust infrastructure.

🏛️Historical Fact
633 malicious npm versions passed Sigstore verification on May 19

6,000+ activations of the compromised Nx Console extension in under 40 minutes

1,055 malicious package versions across npm, PyPI, and Composer

502 unique packages compromised in the Mini Shai-Hulud campaign

3+ years since last update for initial compromised packages


Why Sigstore Worked—And Why That’s a Problem

Sigstore is a groundbreaking tool. It was designed to solve a critical problem: proving that a piece of software was built from a specific source code repository, in a trusted environment, by a verified identity. It does this through short-lived certificates issued by Fulcio, a certificate authority that validates GitHub or GitLab identities, and logs all events in Rekor, a public transparency ledger.

In this attack, Sigstore performed flawlessly. The malicious packages were built in a CI environment (likely GitHub Actions), the attacker had valid GitHub credentials, and the certificates were issued correctly. The system couldn’t distinguish between a legitimate maintainer and a compromised one. This is not a bug—it’s a fundamental limitation of identity-based trust models.

⚠️Important
Fulcio, Sigstore’s certificate authority, issues certificates that expire after 12 hours. This reduces the window of misuse, but if an attacker gains access during that window, they can sign as many packages as they want. It’s like having a time-limited key to a vault—if stolen, it’s still dangerous.

The deeper issue is that trust signals are being gamed. Just as HTTPS certificates once gave users a false sense of security (“the padlock means it’s safe”), provenance attestations are becoming a new form of social proof. Attackers know that a package with a valid Sigstore signature is less likely to be scrutinized. They’re exploiting the psychology of trust.

Article visual

The Rise of Credential Theft in Developer Tooling

This attack underscores a growing trend: credential theft is the new frontier of supply chain attacks. Unlike traditional malware that exploits software vulnerabilities, these campaigns target the humans behind the code. Maintainer accounts are goldmines—once compromised, they can publish malicious updates that appear legitimate.

The methods are varied: phishing, session hijacking, insecure storage of API keys, and even insider threats. In the Nx Console case, the attacker likely obtained long-lived tokens or reused passwords. Many developers still use personal accounts for work-related publishing, blurring the lines between identity and access.

🤯Amazing Fact
Historical Fact

In 2021, the CodeCov breach exposed how a single compromised script in a CI pipeline could lead to widespread credential theft. Over 10,000 organizations were affected, including major tech firms. The attack went undetected for months, showing how stealthy these campaigns can be.

The Mini Shai-Hulud campaign took this a step further by targeting dormant packages. These are often overlooked in security audits, making them ideal entry points. Once compromised, they can be used to inject malware into active projects through dependency chains—a technique known as dependency confusion.


The Broader Implications for Open Source Security

These incidents are not isolated. They are symptoms of a systemic issue: open source ecosystems are under-resourced and overburdened. Maintainers are often unpaid volunteers juggling dozens of packages. Security is an afterthought, not a priority. Meanwhile, attackers are becoming more organized, using automation and reconnaissance to identify weak links.

The npm registry alone hosts over 2.2 million packages, with thousands of new ones published daily. No human team can manually review them all. Automated tools like Socket and StepSecurity help, but they can’t catch everything—especially when attackers use valid credentials and obfuscation.

🤯Amazing Fact
Health Fact

A 2023 study by the Linux Foundation found that 70% of open source maintainers report burnout, and 40% have experienced security incidents. The human factor is the weakest link in the chain.

The solution isn’t just better tooling—it’s a cultural shift. Projects need funding, security training, and multi-factor authentication (MFA) enforcement. Registries must implement stricter publishing controls, such as requiring MFA for new versions or limiting publishing rights based on activity.


What Developers Can Do Right Now

While the ecosystem evolves, developers aren’t powerless. Here are actionable steps to reduce risk:

  • Enable MFA on all publishing accounts — This is the single most effective defense against credential theft.
  • Audit dependencies regularly — Use tools like `npm audit`, Socket, or Snyk to detect suspicious packages.
  • Pin dependencies — Avoid automatic updates for critical packages. Use lockfiles and review changes.
  • Monitor for dormant package activity — A sudden update to a rarely maintained package should raise alarms.
  • Use private registries for internal packages — This prevents dependency confusion attacks.
  • 📊By The Numbers
    Over 60% of npm packages have not been updated in the last year.

    Only 30% of npm maintainers use MFA.

    The average npm package has 12 dependencies.

    A single compromised package can affect thousands of downstream projects.

    Sigstore adoption has grown by 400% in the last two years, but misuse is rising.


    The Future of Trust in Software Supply Chains

    The May 2024 attacks mark a turning point. We can no longer rely on cryptographic signatures alone to signal trust. The next generation of security must incorporate behavioral analysis, anomaly detection, and decentralized identity.

    Projects like in-toto and SPIFFE are exploring ways to verify not just who signed a package, but how it was built and what it does. Machine learning models are being trained to detect obfuscated code and unusual publishing patterns. And initiatives like the OpenSSF’s Alpha-Omega project aim to fund security audits for critical open source components.

    But technology alone won’t fix this. We need shared responsibility. Registries, maintainers, enterprises, and governments must collaborate to create a safer ecosystem. That means funding, education, and enforcement.

    The illusion of trust has been shattered. But from its ashes, a more resilient model of software security can emerge—one that doesn’t just verify identity, but understands intent.

    This article was curated from Valid certificates, stolen accounts: how attackers broke npm's last trust signal via VentureBeat


    Discover more from GTFyi.com

    Subscribe to get the latest posts sent to your email.

    Alex Hayes is the founder and lead editor of GTFyi.com. Believing that knowledge should be accessible to everyone, Alex created this site to serve as...

    Leave a Reply

    Your email address will not be published. Required fields are marked *