Keyv npm Supply Chain Attack: GitHub Account Compromise Led to Credential-Stealing Malware Across the JavaScript Ecosystem

A large-scale software supply chain attack targeting the JavaScript ecosystem unfolded on 4 August 2026 after attackers compromised one or more maintainer accounts and published malicious versions of widely used npm packages. The incident initially appeared to affect only Keyv, a popular key-value storage library, but subsequent investigation revealed that it was part of a much broader campaign spanning multiple organizations, package maintainers, and hundreds of malicious package releases.

Security researchers from Wiz, SafeDep, JFrog, Upwind Security, and other organizations independently confirmed that the attackers distributed malware through compromised package updates rather than exploiting a vulnerability in npm itself. Instead, trusted maintainer identities and legitimate publishing workflows were abused to deliver malicious code directly to developers, CI/CD systems, and enterprise build pipelines.

The campaign rapidly expanded beyond the Keyv ecosystem. Packages maintained by organizations including Cacheable, HubSync, Qlik, OneReach, Ornikar, Deliveroo, ServiceTitan, Picsart, and others were also republished with malicious payloads. SafeDep’s investigation identified hundreds of poisoned package versions published within a remarkably short period, indicating that the attackers were operating at scale rather than targeting a single project.

Unlike traditional malware that waits until an application is executed, the malicious packages leveraged npm lifecycle hooks to run automatically during installation. In several cases, the attackers also modified repository configuration files associated with Visual Studio Code and Claude Code so that simply opening a cloned repository could trigger malicious code execution. This substantially increased the attack surface, placing developers who merely inspected source code at risk without necessarily installing a compromised dependency.

Once executed, the malware focused almost entirely on credential theft. Researchers observed attempts to collect GitHub and npm authentication tokens, cloud provider credentials from AWS, Azure and Google Cloud, HashiCorp Vault authentication data, Kubernetes service account tokens, SSH private keys, TLS certificates, cryptocurrency wallets, AI development configuration files, CI/CD secrets, and numerous additional credentials commonly present on developer workstations and build infrastructure. According to Wiz, the malware shares significant similarities with the Shai-Hulud malware family that has previously been associated with multiple npm supply chain attacks. The payload also introduced mechanisms for persistence, credential harvesting from GitHub Actions runners, encrypted exfiltration, and further propagation through compromised publishing credentials.

Because the malicious code executed during dependency installation rather than application runtime, any environment performing package installation—including developer laptops, self-hosted build servers, GitHub Actions runners, cloud CI platforms, and container image build pipelines—could potentially have been exposed. Organizations that installed affected package versions should therefore assume credential compromise until proven otherwise and investigate both developer endpoints and CI/CD infrastructure accordingly.

Understanding the Incident

Software supply chain attacks have become one of the fastest growing threats facing modern software development. Instead of attacking production systems directly, adversaries compromise software dependencies that thousands or even millions of downstream projects trust implicitly. The attacker only needs to compromise one sufficiently popular package to gain indirect access to an enormous number of environments.

Keyv illustrates precisely why these attacks are so effective.

Keyv is a lightweight JavaScript key-value storage library designed around a simple abstraction layer supporting numerous storage backends. It is widely used across the Node.js ecosystem because it allows applications to switch between Redis, SQLite, MongoDB, PostgreSQL, MySQL, in-memory stores, and other databases without changing application logic. Its modular design has made it a dependency of numerous open-source frameworks, SDKs, caching libraries, and enterprise applications.

Its popularity also makes it an attractive target. A malicious release of Keyv is not limited to projects that explicitly install it. Thousands of applications inherit the dependency transitively, meaning developers may never realize the package exists inside their dependency graph.

That characteristic dramatically amplifies the impact of any compromise.

In this incident, investigators found no evidence that npm itself had been breached. Instead, available evidence indicates that attackers obtained access to one or more trusted maintainer accounts before publishing malicious package versions under legitimate project ownership. Because these releases originated from authorized maintainers using normal publishing workflows, conventional trust assumptions surrounding package provenance no longer held.

This distinction is important. Organizations often focus on detecting unsigned packages or suspicious publishers. Here, the attacker published malware from legitimate package maintainers using trusted release mechanisms, making the packages appear authentic to automated tooling and downstream users.

Timeline of the Attack

Based on publicly available investigations, the compromise unfolded rapidly during the morning of 4 August 2026 (UTC).

Around 09:00 UTC, attackers first modified the Keyv GitHub repository, introducing malicious files into the project. Shortly afterward, malicious versions of keyv 6.0.0 were published to npm. Within the next hour, numerous related packages within the Cacheable ecosystem received similarly compromised releases.

The campaign then accelerated dramatically. As of now (15:30 UTC), more than 2,200 packages have been infected. The worm is spreading fiercely.

Researchers observed malicious publications affecting additional organizations in rapid succession, including HubSync, Ornikar, Qlik, OneReach, Deliveroo, ServiceTitan, and others. SafeDep documented an automated publishing pattern in which entire package namespaces were republished within minutes, strongly suggesting that the attackers were leveraging stolen publishing credentials rather than manually compromising each project individually.

The sheer publication rate distinguishes this incident from earlier npm compromises. Rather than targeting isolated packages over several days, the attackers appeared capable of republishing dozens of packages within seconds once access to a maintainer account had been obtained.

Although the precise propagation mechanism remains under investigation, the observed sequence strongly suggests automated expansion after initial credential theft. Researchers have emphasized that this conclusion is based on observed publishing behavior and timing rather than fully reversing every component responsible for propagation.

How the Malicious Packages Executed Code

The compromise relied on one of npm’s standard lifecycle features: installation scripts.

npm supports several lifecycle hooks that package authors legitimately use during installation, testing, packaging, and publishing. One of these is the preinstall script, which executes before the package itself is installed.

The attackers inserted a new preinstall entry into affected package manifests, instructing npm to execute a malicious loader during package installation. Because lifecycle hooks execute automatically unless explicitly disabled, developers did not need to import or execute the affected library for the malware to begin running. Simply installing a compromised version was sufficient.

This distinction significantly increased the campaign’s reach. Applications that never called Keyv functions at runtime could still become infected if their dependency manager downloaded the malicious release during installation.

Investigators further observed that the attackers intentionally minimized visible code changes. Rather than modifying the library’s primary functionality, they added only the malicious installer and supporting payload files while leaving the actual runtime implementation largely untouched. From the perspective of a casual code review, the package appeared almost identical to previous releases, making the malicious additions considerably easier to overlook.

This approach reflects an increasingly common tactic in software supply chain attacks: preserve expected application behavior while quietly introducing malicious functionality that activates before the application itself ever runs.

Beyond npm: Repository-Level Persistence

One of the most concerning aspects of this campaign was that installation was not always required.

Researchers discovered additional configuration files committed directly into the Keyv repository targeting both Visual Studio Code and Claude Code environments. These files were configured to execute JavaScript automatically when a developer opened the cloned repository.

The attacker deliberately distributed execution logic across multiple configuration files rather than placing everything in a single location. One configuration referenced another directory, which in turn referenced additional malicious files. This cross-referencing technique made the malicious behavior considerably harder to identify during manual inspection because reviewing either configuration independently did not reveal the complete execution chain.

This represents an important evolution in supply chain attacks.

Historically, developers assumed that cloning a repository for inspection was inherently safe provided they did not execute the contained software. In this campaign, that assumption no longer held. Repository configuration files themselves became an execution vector, expanding the attack surface beyond traditional package installation workflows.

Security teams should therefore consider repository configuration, IDE automation files, editor tasks, and AI assistant configuration files as part of software supply chain reviews rather than focusing exclusively on dependency manifests.

Trusted Publishing Wasn’t Enough

One of the most important lessons from this incident is that modern supply chain security mechanisms are not designed to protect against a compromised maintainer account.

Over the past several years, the JavaScript ecosystem has adopted stronger package publishing practices. npm introduced Trusted Publishing, allowing packages to be published directly from GitHub Actions using OpenID Connect (OIDC) instead of long-lived npm tokens. In parallel, projects increasingly began generating Software Level for Supply Chain Artifacts (SLSA) provenance, enabling consumers to verify where a package originated and how it was built.

These technologies significantly reduce the risk of stolen publishing tokens and unauthorized build infrastructure. However, they cannot distinguish between a legitimate maintainer intentionally publishing code and a legitimate maintainer account that has already been compromised.

According to SafeDep’s analysis, the malicious Keyv release was published through the project’s normal GitHub Actions release workflow and carried valid provenance. From a cryptographic perspective, the package appeared authentic because it genuinely originated from the project’s trusted build pipeline. The pipeline itself was not forged; rather, malicious source code entered the legitimate release process before publication.

This distinction matters because provenance answers one question only: “Where did this package come from?” It does not answer “Was the source code itself malicious?”

Organizations increasingly adopting SLSA, Sigstore, or Trusted Publishing should therefore avoid treating provenance as evidence that software is safe. Provenance establishes authenticity of the build process, not trustworthiness of the code being built.

The compromise also demonstrates why code review remains a critical component of software supply chain security. Even perfectly signed artifacts become dangerous when the trusted source repository itself has already been compromised.

From Loader to Malware Execution

The malicious code delivered through affected packages followed a staged execution model rather than embedding its entire functionality directly into the installation script.

Researchers found that the initial setup.mjs file acted primarily as a lightweight loader. Its responsibility was to establish an execution environment capable of running the main payload across different operating systems while minimizing dependencies on the victim’s machine.

If the Bun JavaScript runtime was already installed, the loader reused the existing installation. Otherwise, it automatically detected the operating system and processor architecture, downloaded an appropriate Bun release directly from the official GitHub releases repository, extracted it locally, executed the primary payload, and then removed the downloaded runtime from disk.

This approach offered several operational advantages for the attackers.

First, it eliminated assumptions about the victim’s environment. The malware no longer depended on the locally installed Node.js runtime or additional packages because it brought its own execution environment.

Second, network traffic generated during this stage appeared relatively benign. Rather than contacting an unfamiliar attacker-controlled server, the malware retrieved its runtime from GitHub’s official infrastructure. Organizations relying primarily on domain reputation or simple outbound filtering would therefore observe requests to a well-known, trusted service rather than an obviously malicious domain.

Finally, the temporary runtime was removed after execution, reducing forensic evidence left on disk and making post-incident investigation more difficult.

This reflects a broader trend in modern malware development. Rather than embedding every component inside a single executable, attackers increasingly rely on trusted cloud services, open-source infrastructure, and legitimate software distribution platforms to reduce suspicion while maximizing compatibility.

Obfuscation Designed to Delay Analysis

The second-stage payload was substantially more sophisticated than the initial loader.

Rather than storing readable JavaScript, researchers found that the malware consisted of a heavily obfuscated bundle containing multiple encrypted modules. Investigations by Upwind Security and SafeDep indicate that the payload employed several layers of protection, including string obfuscation, encrypted configuration data, and cryptographic routines based on PBKDF2 and AES-256-GCM before the underlying functionality became visible during dynamic analysis.

Importantly, these protections were not intended to make reverse engineering impossible. Given sufficient time, defenders can recover encrypted payloads.

Instead, the objective was to slow incident response during the most critical phase of the attack.

In software supply chain incidents, the first several hours often determine how many organizations become infected before malicious packages are identified and removed. Every additional hour spent reversing encrypted code provides attackers with more opportunities to harvest credentials, compromise build systems, and expand laterally.

This explains why many contemporary supply chain malware families emphasize operational delay rather than theoretical resistance to analysis.

A Broad Credential Harvesting Operation

Once execution reached the primary payload, the malware shifted its focus almost entirely toward credential theft.

Rather than targeting a single cloud provider or development platform, researchers observed an extensive collection strategy covering credentials commonly found across modern software engineering environments.

GitHub personal access tokens and GitHub Actions credentials were among the highest-priority targets because they could enable repository compromise, malicious commits, workflow modification, and potentially further software supply chain attacks. npm authentication tokens were similarly valuable because they provided a direct mechanism for publishing additional compromised package versions.

The malware also searched for cloud provider credentials associated with Amazon Web Services, Microsoft Azure, and Google Cloud Platform. These included locally stored configuration files, service account credentials, authentication secrets, and environment variables commonly present on developer workstations and CI runners.

HashiCorp Vault authentication material represented another significant target. Rather than stealing Vault itself, researchers observed attempts to obtain authentication responses and client tokens that could subsequently be exchanged for privileged infrastructure secrets.

Containerized workloads were not ignored either. The malware searched for Kubernetes service account tokens commonly mounted inside running containers, providing an opportunity to authenticate directly against Kubernetes clusters if workloads possessed elevated permissions.

Researchers additionally documented attempts to locate SSH private keys, TLS certificates, API credentials, cryptocurrency wallets, database connection strings, Stripe keys, and numerous additional developer secrets. The breadth of targeted material indicates that the attackers were interested in compromising software development environments as comprehensively as possible rather than pursuing a single objective.

Several targeted artifacts deserve particular attention because of their potential enterprise impact.

GitHub tokens can enable modification of source repositories, release pipelines, and Actions workflows.

Cloud credentials frequently provide direct access to production infrastructure.

Vault authentication tokens may expose thousands of additional secrets stored centrally.

Kubernetes service account tokens can facilitate lateral movement within clusters.

Collectively, these capabilities transform what initially appears to be a package compromise into a potential enterprise-wide credential exposure event.

Why CI/CD Systems Were Especially Vulnerable

Although developer laptops represented an obvious target, build infrastructure likely offered even greater value to the attackers.

Continuous Integration systems routinely possess elevated privileges unavailable on individual workstations. During software builds, these environments often receive temporary cloud credentials, repository access tokens, deployment keys, signing certificates, package publishing credentials, and production secrets required to automate releases.

The malware explicitly recognized this reality.

Investigators found functionality designed to identify GitHub Actions runner processes and extract secrets directly from runner memory rather than relying solely on configuration files stored on disk. Because GitHub Actions temporarily injects secrets into running jobs, malware capable of reading process memory may recover credentials that never appear inside repository files or environment configuration.

Researchers also identified functionality capable of deploying malicious GitHub Actions workflows that export repository secrets into workflow artifacts for later retrieval. Rather than exploiting vulnerabilities in GitHub Actions itself, the malware abused legitimate workflow functionality after obtaining sufficient repository privileges.

For organizations practicing modern DevSecOps, this significantly increases the scope of incident response.

Security teams cannot limit investigations to endpoints where developers installed compromised packages. Any build runner, ephemeral CI worker, self-hosted GitHub Actions runner, or automated release infrastructure that processed affected package versions during the exposure window should be treated as potentially compromised until verified otherwise.

GitHub as the Exfiltration Channel

One of the more unusual aspects of this campaign was how the stolen information left compromised systems. Rather than communicating with a traditional command-and-control (C2) server hosted on attacker-controlled infrastructure, researchers found that the malware abused trusted GitHub services for data exfiltration. According to Wiz, stolen information was encrypted and uploaded to GitHub repositories created under compromised identities, allowing the attackers to blend malicious traffic with legitimate developer activity. The repositories reportedly carried the description “Shai-Hulud: Here We Go Again,” further strengthening links between this campaign and the previously documented Shai-Hulud malware family.

Using GitHub in this manner provides several operational advantages. Connections to GitHub are routine within development environments, making outbound traffic significantly less suspicious than communication with newly registered domains or unfamiliar IP addresses. Corporate firewalls, proxy servers, and network monitoring platforms frequently permit unrestricted access to GitHub because it is essential to software development workflows. As a result, exfiltration through GitHub is far less likely to trigger alerts than communication with conventional malware infrastructure.

The campaign also included an intimidation string embedded within initial commits:

IfYouBlockThisAPIKeyItWillCrashTheLiveProductionServersOfAllThirdPartyClients

There is no evidence that this statement reflected an actual capability. Researchers currently regard it as psychological intimidation intended to discourage defenders from immediately revoking compromised credentials while incident response was still underway. Security teams should therefore treat the message as an attempt to influence defender behavior rather than as proof that revoking an API key would trigger destructive activity. Public analysis published so far does not demonstrate such functionality. This distinction is important because incident response decisions should always be based on verified technical evidence rather than attacker claims.

Relationship to the Shai-Hulud Malware Family

Although attribution remains ongoing, multiple independent researchers have concluded that the malware shares substantial similarities with the Shai-Hulud supply chain malware family.

Wiz describes the payload as a descendant of the “Mini” Shai-Hulud malware, while JFrog likewise identifies the campaign as a new evolution of the same malware family.

These similarities extend beyond individual code fragments. Investigators observed comparable credential harvesting objectives, GitHub-focused exfiltration techniques, persistence mechanisms, and operational tradecraft previously associated with earlier Shai-Hulud incidents. That said, researchers have deliberately avoided claiming with certainty that the same threat actor is responsible.

This distinction deserves emphasis.

Malware families frequently evolve, are modified by different operators, or become available to multiple threat groups after code leaks or public releases. Similar tooling does not necessarily prove identical attribution. At the time of writing, publicly available evidence supports describing this campaign as sharing significant similarities with Shai-Hulud, while definitive attribution to a specific threat actor remains unconfirmed.

Maintaining this distinction is essential for accurate incident reporting. Conflating malware lineage with threat actor attribution risks overstating available evidence and may lead to incorrect conclusions as investigations continue.

Why This Attack Was So Effective

Several characteristics combined to make this campaign unusually dangerous.

First, the attackers did not exploit vulnerabilities in npm itself. Instead, they abused the trust relationships that developers and automated systems naturally place in legitimate maintainers. Because packages originated from authentic publisher accounts, standard reputation checks offered little protection.

Second, the malicious code executed before applications were even installed. Traditional software reviews often focus on runtime behavior, but the payload activated during dependency installation through npm lifecycle hooks. In some repositories, simply opening the project inside supported development environments could trigger execution through malicious editor configuration files.

Third, the malware targeted the modern software development lifecycle rather than end-user systems. Instead of stealing browser cookies or banking credentials, it focused on GitHub access tokens, cloud authentication material, package publishing credentials, CI/CD secrets, Vault tokens, Kubernetes identities, and signing keys. These assets provide direct access to software supply chains, making them substantially more valuable than credentials stolen from ordinary desktop environments.

Finally, the campaign demonstrated how rapidly compromise can spread once trusted publishing credentials become available. SafeDep documented packages being republished across multiple organizations within minutes, suggesting a highly automated operation capable of abusing newly acquired credentials almost immediately after compromise.

Collectively, these characteristics distinguish the incident from isolated npm package compromises seen in previous years. Rather than affecting a single maintainer or library, the campaign propagated across multiple ecosystems, impacting organizations with entirely separate development teams and publishing infrastructure.

Confirmed Affected Packages

At the time of writing, researchers have confirmed malicious releases across multiple npm packages spanning several independent organizations. While the campaign ultimately affected hundreds of package versions, the following are among the most widely used and highest-impact packages confirmed to contain the malicious payload.

The campaign extended well beyond these packages. SafeDep identified 353 malicious package versions across 79 package names, while broader monitoring observed 442 compromised versions affecting 353 packages published under multiple organizations, including Ornikar, OneReach, ServiceTitan, Deliveroo, HubSync, Qlik, Picsart, and others. The complete package list is provided in Part 2, where each affected package and version is documented in full.

Initial Indicators of Compromise (IoCs)

Organizations should immediately investigate systems that installed affected package versions for the following indicators. These represent the most consistently observed artifacts across public analyses.

Suspicious Domains

File Artifacts

node_modules/keyv/Math_Symbol.js
/tmp/bun-dl-*
.claude/setup.mjs
.vscode/setup.mjs

Known File Hashes

Suspicious String

IfYouBlockThisAPIKeyItWillCrashTheLiveProductionServersOfAllThirdPartyClients

Immediate Actions for Security Teams

Organizations that installed any affected package versions should assume that sensitive credentials may have been exposed until investigations demonstrate otherwise. Simply uninstalling malicious packages is insufficient because any credentials harvested before removal remain potentially compromised.

The highest priority should be identifying every environment that installed affected versions. This includes developer workstations, CI/CD runners, container build systems, self-hosted GitHub Actions runners, release automation infrastructure, and ephemeral cloud build environments. Dependency lockfiles, build logs, package caches, and software bill of materials (SBOM) records can help determine where compromised versions were introduced.

After identifying affected systems, organizations should isolate them for forensic analysis rather than immediately rebuilding or rotating credentials. Public reporting has identified persistence mechanisms and credential monitoring components associated with the malware. Performing credential rotation before confirming that these artifacts have been removed could complicate incident response or allow persistence mechanisms to remain active. Researchers therefore recommend treating affected systems as potentially compromised, removing malicious packages, investigating for persistence, and then rotating exposed credentials once systems have been cleaned.

Credential rotation should extend beyond GitHub and npm tokens. AWS IAM credentials, Azure service principals, Google Cloud service accounts, HashiCorp Vault tokens, Kubernetes secrets, SSH private keys, TLS certificates, database credentials, CI/CD secrets, and any additional authentication material accessible from compromised systems should all be considered for replacement based on organizational risk assessments.

Organizations should also review GitHub repositories, cloud audit logs, package publishing histories, and CI/CD activity for unauthorized changes occurring after installation of affected packages. Because the malware specifically targeted software development infrastructure, signs of compromise may appear first in source code repositories, build pipelines, or cloud identity logs rather than on developer endpoints.

Conclusion

The Keyv incident represents one of the most significant npm supply chain attacks observed to date, not because of the popularity of a single package, but because it demonstrated how quickly trusted software ecosystems can become attack vectors when maintainer accounts are compromised. By abusing legitimate publishing workflows, trusted repositories, and standard npm lifecycle features, the attackers transformed ordinary dependency installation into an opportunity for large-scale credential theft across developer workstations and enterprise CI/CD infrastructure.

Perhaps the most important lesson is that software provenance alone cannot establish software trust. Signed releases, trusted publishing pipelines, and cryptographic attestations remain valuable security controls, but they verify who built the software, not whether the source code itself has been maliciously modified. When an attacker gains access to a trusted maintainer account, even correctly signed releases can deliver malware to downstream users.

For defenders, the incident reinforces the importance of layered supply chain security. Dependency monitoring, rapid package inventory, repository integrity reviews, least-privilege access to publishing credentials, short-lived authentication tokens, behavioral monitoring of CI/CD systems, and continuous credential hygiene all become essential when trust in upstream dependencies can no longer be assumed.

As investigations continue, additional affected packages, infrastructure, and indicators may still emerge. Security teams should therefore monitor updates from researchers and affected maintainers while treating the currently identified package versions as confirmed indicators of exposure. The next part of this series examines the malware’s indicators of compromise, affected packages, detection opportunities, and enterprise response guidance in greater technical detail.