Inside real supply chain attacks: Bitwarden CLI, Axios, and Vercel

Why breach a well-defended corporate network when you can compromise an npm package with millions of weekly downloads and slip silently into thousands of those networks at once?

On April 22, 2026, a credential stealer shipped inside a package with 250,000 monthly downloads. It executed silently at install time, required no user interaction, and was pulled automatically by CI runners across dozens of pipelines. By the time security teams detected the compromise, real machines had already been compromised. Just a routine dependency update.

This is the core vulnerability of modern infrastructure: you are only as secure as your weakest dependency. When attackers can't breach your perimeter directly, they compromise something you already trust and ride it straight into your environment.

The 2026 supply chain campaigns prove this isn't theoretical. Three coordinated attacks across different vectors hit production systems within weeks of each other. Each one followed the same pattern: identify a trusted package, inject malicious code, wait for automation to do the work.

These aren't isolated incidents. They're proof that supply chain attacks have become industrialized, coordinated, and accelerating.

Key takeaways

• Supply chain attacks bypass your perimeter by weaponizing trust. Packages, CI workflows, and plugins execute in your environment with full privileges. No phishing link required. The attacker becomes part of your normal build process.
• The 2026 campaigns exposed three distinct attack surfaces simultaneously. CI/CD pipeline compromise (Bitwarden CLI), transitive dependency injection (Axios), and OAuth token theft (Vercel/Context.ai) demonstrate that attackers are no longer targeting single vectors.
• Transitive dependencies are your largest blind spot. Your application imports ten packages directly, but each pulls in dozens more. These invisible layers execute with the same privileges as your code, yet most teams never audit them. One compromised transitive dependency can propagate through hundreds of downstream projects.
• Secrets in CI/CD pipelines are the primary target. A single build job that harvests a GitHub token can propagate a compromise across every repository and pipeline that token can reach. The attacker doesn't need to break into your infrastructure. They just need to extract what's already there.
• Architecture beats process. A system designed so that compromising one component yields nothing useful is fundamentally more resilient than one that relies on every control holding simultaneously. Secrets should be encrypted, scoped, and rotated, not scattered across environment files and developer machines.
• Defence requires continuous controls, not periodic audits. Pinned dependencies, signed builds, SBOM tracking, scoped ephemeral tokens, and secrets rotation must run on every commit, not every quarter. The attack window is measured in hours. Your response window must be faster.

What is a supply chain attack

A supply chain attack occurs when an adversary compromises a trusted third-party vendor, open-source package, or software component to deliver a malicious payload to downstream organizations. Instead of attacking your infrastructure directly, the attacker inserts malicious code into something you already trust, and your own systems pull it in automatically.

The attack exploits a fundamental asymmetry: you audit your own code rigorously, but you install third-party dependencies with minimal scrutiny. The attacker knows this. They know that compromising a single trusted package reaches thousands of organizations in parallel, through their own build pipelines, with their own credentials.

Why transitive dependencies make the attack surface exponential

Modern software is built on layers of dependencies. Your application may directly import ten packages, but each of those imports dozens more. These transitive dependencies execute in your environment with the same privileges as first-party code, yet they are rarely audited at all.

A single compromised transitive dependency can propagate through hundreds of downstream projects without any of them knowing they've imported it. The attacker doesn't need to compromise the packages you explicitly depend on. They can compromise something three or four layers deep in your dependency tree, and the malicious code still executes in your CI/CD pipeline.

Supply chain attack vectors

The scale of the threat in 2025–2026

Supply chain attacks are no longer rare incidents. They are now an industrialized threat.

• Over 70% of organizations experienced at least one material third-party cybersecurity incident in the past year (SecurityScorecard, 2025).
• 454,600+ new malicious packages were identified in registries in 2025, representing a 75% year-over-year increase. These packages were cumulatively downloaded 9.8 trillion times across npm, PyPI, Maven Central, NuGet, and Hugging Face (Sonatype, 2026).
• $60 billion estimated global cost of software supply chain attacks in 2025, projected to reach $138 billion by 2031 (Cybersecurity Ventures, 2025).
• 2.6 billion weekly downloads affected by the Shai-Hulud worm campaign targeting npm packages (Trend Micro, 2025).

The regulatory dimension compounds the financial exposure. Organizations operating under GDPR, HIPAA, SOC 2, or ISO 27001 face mandatory breach notification requirements and potential fines when supply chain incidents result in unauthorized access to personal or regulated data.

The anatomy of a modern supply chain attack

A supply chain attack follows a predictable lifecycle:

• Phase 1: Reconnaissance. Attackers scan public repositories, package registries, and CI/CD configurations for weak links: unprotected GitHub tokens in workflow logs, packages with high download counts and minimal maintainers, Actions workflows with excessive permissions.
• Phase 2: Upstream compromise. The attacker gains write access to a trusted artifact by stealing maintainer credentials, submitting a malicious pull request that passes code review, or compromising a CI/CD pipeline.
• Phase 3: Dormancy. The compromised artifact is published and waits. Automated systems pull the update without human review.
• Phase 4: Downstream delivery. Developers and pipelines install the infected version through normal, trusted channels. The credential stealer executes as part of the standard build process.
• Phase 5: Privilege escalation and propagation. With initial access established, the attacker harvests secrets: API tokens, SSH keys, environment variables, cloud credentials. GitHub tokens are particularly valuable because they can be weaponized to inject malicious workflows into every repository the token can reach.

Unprotected secrets in CI/CD pipelines are exactly what attackers harvest in phase five. Passwork centralizes credential management and audit logging, so you can track which secrets were accessed, when, and by whom. This turns CI/CD from a blind spot into a controlled environment. Try Passwork free

Three major supply chain attacks of 2026

The 2026 campaigns demonstrate a coordinated shift in attack sophistication. Rather than isolated package hijacks, threat actors targeted three distinct vectors simultaneously, each exposing different layers of the software supply chain.

Bitwarden CLI compromise (April 2026)

On April 22, 2026, a malicious version of the Bitwarden CLI (@bitwarden/[email protected]) was published to the npm registry. The package has over 250,000 monthly downloads. The malicious code was embedded in bw1.js and triggered via a preinstall hook in package.json (OX Security).

The attackers didn't breach Bitwarden directly. They compromised a third-party GitHub Action used in Bitwarden's CI/CD pipeline, gained access to workflow secrets including an npm token, and used it to publish the malicious package. The string "Shai-Hulud: The Third Coming" embedded in the package confirmed this was the third iteration of an ongoing, organized campaign.

What the malware did

The malicious payload performed the following sequence:

• Russian-language check. Before doing anything else, the malware checked whether the host machine had Russian language configured. If so, it exited immediately. This is a standard self-protection technique: the authors avoid infecting their own development machines, and it points strongly to a Russian-speaking threat actor.
• Credential harvesting. It targeted GitHub and npm tokens, .ssh directories and private keys, .env files and shell history, GitHub Actions environment variables, and AWS, GCP, and Azure credentials. Configuration files for AI coding assistants (Claude, Cursor, Aider, Codex CLI, and Kiro) were explicitly targeted, reflecting how deeply these tools are now embedded in developer workflows and how much sensitive context they store locally.
• Encrypted exfiltration via GitHub. All stolen data was encrypted with AES-256-GCM using asymmetric encryption, meaning only the threat actor's private key can decrypt it. The data was uploaded to a newly created public GitHub repository on the victim's own account, with files named results-TIMESTAMP-ID.json. A secondary channel exfiltrated data to audit.checkmarx[.]cx, a domain impersonating the legitimate Checkmarx platform. Using GitHub as a C2 server is deliberate: traffic to github.com is rarely flagged by security tools and cannot be traced to a threat-actor-controlled domain.
• Self-propagation. This is what makes Shai-Hulud a worm, not just a stealer. If valid npm tokens were found, the malware downloaded one of the victim's own npm packages, injected malicious code into it, and republished a new version, spreading the infection to the victim's downstream users automatically.
• Pipeline propagation. If GitHub tokens were found, the malware injected malicious Actions workflows into accessible repositories, extracting CI/CD secrets and extending the compromise to every pipeline the developer's token could reach.

As StepSecurity noted: "A single developer with @bitwarden/[email protected] installed can become the entry point for a broader supply chain compromise, with the attacker gaining persistent workflow injection access to every CI/CD pipeline the developer's token can reach."

OX Security confirmed that encrypted exfiltration data was already present in public GitHub repositories at the time of discovery. Real machines had been compromised before the package was pulled.

The architectural lesson

The Bitwarden incident reflects a pattern the industry keeps relearning: process-level security controls can be bypassed. Architectural constraints cannot. A system designed so that compromising one component yields nothing useful is fundamentally more resilient than one that relies on every control holding simultaneously.

Passwork is built on this principle. Credentials are encrypted client-side before they ever reach the server. The server stores ciphertext. A database breach, a compromised server, or a rogue administrator yields nothing without the client-side keys. Passwork CLI publishing to PyPI follows a semi-manual process from trusted machines — CI/CD compromise cannot trigger an automated release of a malicious artifact.

Axios (March 2026)

On March 31, 2026, the widely used Axios npm package (100+ million weekly downloads) was compromised when an attacker hijacked the maintainer's credentials and published malicious versions. But the attack's true sophistication lay in how it exploited transitive dependencies.

Instead of embedding malware directly in Axios, the attackers created a fake npm package named [email protected], designed to appear legitimate and similar to the real crypto-js library. They then modified Axios to import plain-crypto-js as a dependency.

When developers installed the compromised Axios version, npm automatically resolved and installed plain-crypto-js. The fake package contained a post-install script that executed before any other code ran, downloading and executing a Remote Access Trojan (RAT) payload.

Transitive dependencies are your largest unaudited attack surface. Security teams often audit direct dependencies carefully, but transitive dependencies are rarely inspected. The plain-crypto-js attack exploited this blind spot by combining typosquatting, automated execution, transitive insertion, and ephemeral distribution. The attack was attributed to Sapphire Sleet, a threat actor group known for supply chain targeting.

Vercel and Context.ai (February–April 2026)

The Vercel breach began not at Vercel, but at Context.ai, a small AI startup that provides AI-powered development tools. In February 2026, an employee at Context.ai was infected with Lumma Stealer, an infostealer malware that harvested credentials and OAuth tokens from the infected machine.

With access to Context.ai's OAuth tokens, the attacker could access Vercel's internal systems, retrieve OAuth tokens that Vercel customers had granted to Context.ai, exfiltrate environment variables containing deployment secrets, and access customer AWS and Google Workspace credentials.

The breach remained undetected for approximately two months. By the time Vercel discovered the compromise in April 2026, OAuth tokens from multiple customers had been stolen.

Why OAuth trust is a critical vulnerability

OAuth tokens are designed to delegate access without sharing passwords. If the application is compromised, the token is compromised. The token looks legitimate because it is legitimate. It's just being used by an attacker instead of the intended application. OAuth provides no mechanism to distinguish between authorized and unauthorized use of a valid token once it's been stolen.

What makes the Vercel incident significant is the speed of the attack chain. From initial infection at Context.ai to full compromise of Vercel customers took approximately two months, faster than many organizations' quarterly security review cycles. The attack demonstrates how a single compromised third-party application can weaponize trust relationships between platforms, turning OAuth delegation into a supply chain vector.

Historical context: Notable supply chain attacks (2017–2025)

Each incident shares a structural pattern: attackers found a trusted, automated delivery mechanism and inserted their payload where it would execute without scrutiny.

How to defend against supply chain attacks

Preventing supply chain attacks requires controls at every layer of the software delivery process.

Level 1: Dependency control

• Pin exact versions and verify checksums. Never use floating version ranges in production. Pin exact versions and validate checksums against a known-good state. This won't prevent a maintainer account compromise, but it eliminates automatic exposure to newly published malicious versions.
• Generate and maintain a software bill of materials (SBOM). An SBOM gives you a complete inventory of every component in your software, including transitive dependencies. When a vulnerability or malicious package is disclosed, you can immediately determine whether you're affected without manual auditing.
• Run continuous software composition analysis (SCA). SCA tools should run on every pull request and every dependency update, flagging new packages and their provenance, unusual preinstall hooks or post-install scripts, unexpected network calls in package scripts, and known malicious packages.

Level 2: Artifact integrity

• Enforce signed builds and provenance attestation. A signed artifact with a verifiable build chain is significantly harder to tamper with undetected. Use tools like Sigstore to sign and verify build artifacts.
• Verify package signatures at install time. npm, PyPI, and other registries support package signing. Verify signatures before installing dependencies.

Level 3: CI/CD infrastructure protection

• Apply zero-trust principles to CI/CD workflows. GitHub Actions workflows should operate with minimum permissions required: use ephemeral tokens scoped to individual jobs, not long-lived personal access tokens; pin third-party Actions to specific commit SHAs, not mutable tags; and use OIDC tokens instead of static credentials where possible.
• Rotate CI/CD secrets regularly and after every incident. Treat secrets in CI/CD environments as short-lived credentials. Any token, API key, or SSH key that could have been exposed should be rotated immediately.
• Monitor for anomalous exfiltration behavior. Allowlist expected outbound destinations for build environments and alert on deviations.

Level 4: Developer perimeter defense

• Audit AI coding tool configurations. The 2026 campaign explicitly targeted configuration files for Claude, Cursor, and Aider. Treat them as sensitive artifacts and include them in your secrets scanning scope.
• Audit OAuth applications and grants. Review which third-party applications have OAuth access to your GitHub, Vercel, and cloud accounts. Revoke access for applications no longer in use.
• Implement secrets scanning in your development environment. Scan developer workstations, local Git repositories, and IDE configurations for exposed credentials.

Centralized secrets management as the foundation

All of these controls depend on one critical principle: secrets must be stored securely, accessed with minimal privilege, and rotated rapidly.

Process controls fail without architectural constraints. A developer who needs to rotate a GitHub token shouldn't have to manually update it in five different .env files, three CI/CD platforms, and two deployment tools. That friction creates incentives to skip rotation or reuse tokens across environments.

Centralized secrets management solves this. A structured vault provides a single source of truth for all credentials, role-based access control so developers only access the secrets they need, audit logging of every access and modification, and rapid rotation of secrets across all systems that use them.

When a supply chain incident occurs and you need to rotate every GitHub token, npm token, and cloud credential that could have been exposed, a centralized vault makes this operationally feasible. Without it, rotation becomes a manual, error-prone scramble, and incomplete rotations leave attack vectors open.

Conclusion

Supply chain attacks work because they exploit the one thing organizations can't easily audit: the trust embedded in automated systems. Every dependency your pipeline pulls, every GitHub Action your workflow references, every plugin your IDE loads — each is a potential entry point.

The 2026 Bitwarden CLI, Axios, and Vercel campaigns make the threat concrete. A single compromised package, installed silently by a CI runner, can expose every secret in a developer's environment and propagate through every pipeline that token can reach. The attack doesn't announce itself. It executes as part of your normal build process.

Defending against this requires zero-trust architecture applied to the software supply chain: pinned dependencies, signed artifacts, SBOM tracking, continuous SCA, and short-lived scoped credentials. Secrets must be treated as perishable — rotated regularly, stored securely, and never embedded in code or environment files without governance.

Robust secrets management is a foundational control here. When credentials are stored in a structured, access-controlled vault like Passwork rather than scattered across .env files and developer workstations, the blast radius of a supply chain compromise shrinks significantly. Attackers can steal what they can reach. Make it nothing.

Ready to reduce your blast radius? Passwork gives your team a structured secrets vault with role-based access, full audit logging, and a self-hosted deployment that keeps credentials off third-party infrastructure. Teams migrating from a another password manager receive a 10% migration discount. Try Passwork free

FAQ: Supply chain attacks

What is a supply chain attack in cybersecurity?

A supply chain attack is a cyberattack that compromises a trusted third-party vendor, open-source package, or software component to gain access to downstream targets. Instead of attacking an organization directly, adversaries insert malicious payloads into software updates, build pipelines, or dependencies that the target installs automatically.

What is the Shai-Hulud worm?

Shai-Hulud is a worm campaign that compromised the Bitwarden CLI npm package in April 2026. It's called a worm because it self-propagates: after harvesting credentials, it injects malicious code into the victim's own npm packages and republishes them, spreading the infection to downstream users automatically. The name "Shai-Hulud: The Third Coming" indicates this was the third iteration of an ongoing, organized campaign.

Why are OAuth tokens a dangerous attack vector?

OAuth tokens are designed to delegate access without sharing passwords. If an application (like Context.ai) is compromised, the OAuth tokens it holds are compromised. The token looks legitimate because it is legitimate — it's just being used by an attacker instead of the intended application. The victim has no way to know their OAuth grant has been weaponized until the damage is discovered.

What is a transitive dependency?

A transitive dependency is a software component that your code relies on indirectly — a library imported by your direct dependencies, which in turn imports others. Transitive dependencies are rarely audited with the same rigor as first-party code, yet they execute in your environment with the same privileges. The Axios attack exploited this by injecting a fake transitive dependency (plain-crypto-js) that was automatically installed when developers installed the compromised Axios package.

How did the Bitwarden CLI supply chain attack work?

The malicious @bitwarden/[email protected] package was published to npm on April 22, 2026, with a credential stealer embedded in bw1.js and executed via a preinstall hook. It harvested GitHub tokens, SSH keys, environment variables, cloud secrets, and AI coding tool configurations, then exfiltrated the data — encrypted with AES-256-GCM — to a domain impersonating Checkmarx.

What is the difference between a supply chain attack and a direct cyberattack?

A direct attack targets the victim's own systems — their network, credentials, or applications. A supply chain attack targets a trusted supplier or dependency instead, using that trust to bypass the victim's defenses. The victim installs or runs the compromised component voluntarily, through normal processes, which makes detection significantly harder.

What are transitive dependencies and why do they matter for security?

Transitive dependencies are software components that your code relies on indirectly — libraries imported by your direct dependencies, which in turn import others. They are rarely audited with the same rigor as first-party code, yet they execute in your environment with the same privileges. A compromise anywhere in that chain can affect your application.

What is an SBOM and how does it help prevent supply chain attacks?

A software bill of materials (SBOM) is a structured inventory of every component in a software product, including all direct and transitive dependencies. When a malicious package or vulnerability is disclosed, an SBOM lets security teams immediately determine whether their software is affected — without manually tracing dependency trees across every project.

What GitHub Actions security practices reduce supply chain risk?

Pin all third-party Actions to specific commit SHAs rather than mutable version tags. Use ephemeral, job-scoped tokens instead of long-lived personal access tokens. Restrict workflow permissions to the minimum required. Audit all workflow files for unexpected third-party references, and monitor CI runner egress traffic for anomalous outbound connections.

How should organizations respond if a compromised package was installed in their CI/CD pipeline?

Treat all secrets accessible during the affected build jobs as compromised. Rotate every token, API key, SSH key, and cloud credential that could have been exposed. Review GitHub Actions workflow files for unauthorized modifications. Audit repository access logs for unexpected commits or workflow runs. Report the incident per your regulatory obligations under GDPR, HIPAA, or applicable frameworks.

Brute force attacks in 2026: Types, examples & how to prevent them

GPU clusters, AI-assisted wordlists, botnets of 2.8M devices. Brute force has scaled. This guide covers six attack variants, real-world cases from 2025, and a layered defense strategy your team can implement today.

Passwork BlogAlex Muntyan

NIS2 latest news: What changed and what it means for EU businesses

84% of in-scope organizations admit they’re not ready. Belgium set the first conformity assessment deadline on April 18, 2026. The Netherlands is days away from enforcement. Here’s where the regulatory wave stands and what IT leaders need to act on now.

Passwork BlogAlex Muntyan

Password chaos: Why it’s a business problem and how to fix it

A forgotten password costs $70. A breach costs $4.44 million. Both start the same way — credentials shared over Slack, stored in spreadsheets, never rotated. Here’s what password chaos actually costs and how to eliminate it.

Passwork BlogAlex Muntyan