devoracles.

NewsSecurity & Audits

Keyv and Cacheable Supply Chain Attack: How Malicious Code Compromised 400+ Packages

Wiz Research reports that the widely used keyv and cacheable npm packages were compromised in a software supply-chain attack, with a malicious commit pushed directly to a repository’s main branch.

Keyv and Cacheable Supply Chain Attack: How Malicious Code Compromised 400+ Packages

The payload was a credential-stealing worm, not a harmless typo in a dependency update. For teams building oracle services, data feeds, and Web3 infrastructure, this is the attack vector that turns a routine package install into privilege escalation across developer machines, CI/CD runners, cloud accounts, and crypto wallets.

There is no financial-loss figure in the available reporting. That absence is less reassuring than it sounds: the confirmed damage is the delivery mechanism and the scope of the theft attempt, not a completed balance sheet.

The compromise entered through the maintainer account

According to Wiz, an attacker compromised a GitHub maintainer account and used it to introduce malicious changes to the keyv repository. The first move was persistence through IDE-related configuration, followed shortly by publication of a malicious keyv version. The same payload then appeared across multiple packages in the Keyv and Cacheable ecosystem.

Wiz says the worm propagated to more than 400 distinct npm packages. The payload targeted cloud credentials, infrastructure secrets, developer credentials, AI-related configuration files, and cryptocurrency wallets. It also attempted to harvest secrets from CI/CD environments, identify build runners, and enumerate cloud environments for further compromise.

That is a familiar post-mortem pattern: trusted identity, trusted repository, trusted package manager, then a blast radius determined by transitive dependencies. The attack did not need to break a smart contract or manipulate an oracle response. It attacked the machinery used to build and operate the systems around them.

The malware also attempted persistence through Claude Code hooks and VS Code tasks.json. Exfiltrated data was sent through GitHub repositories created under compromised identities, using the description “Shai-Hulud: Here We Go Again.” Wiz identified the payload as a descendant of the “Mini” Shai-Hulud malware family, with similarities to earlier TeamPCP and antv supply-chain campaigns.

Why this matters to oracle infrastructure

An oracle network can have sound on-chain logic and still be compromised before deployment. A malicious npm dependency can sit inside a data collector, signing service, monitoring tool, SDK, or deployment pipeline. Once credentials leave the build environment, the attack surface expands from package integrity to cloud access, repository access, deployment keys, and wallet operations.

The reported payload also used an Ethereum smart contract to dynamically retrieve command-and-control domains. That detail is particularly uncomfortable for this audience. The chain was not merely the asset being protected; it became part of the malware’s control-plane design. Deterministic public infrastructure can be useful to attackers when they need a resilient way to distribute configuration.

Wiz further reported that the malware used a new RSA key to encrypt exfiltrated data, while retaining an RSA key for verifying fallback command-and-control locations posted to GitHub. The payload’s dead-man switch could be selectively armed by the command-and-control server and configured to monitor token revocation through api.github.com/user.

None of this requires a novel exploit primitive. It is credential theft, persistence, and lateral movement assembled into a package-distribution attack. The grim lesson is that “open source” and “reviewed once” are not security controls.

What teams should inspect now

The first task is dependency triage. Search lockfiles, package manifests, build caches, and container definitions for keyv, cacheable, and other packages in the affected ecosystem. Do not limit the search to direct dependencies: the stated propagation through more than 400 packages means transitive exposure is part of the threat model.

Next, treat build environments as potentially relevant attack surfaces. Review CI/CD jobs, build runners, developer workstations, IDE configuration, Claude Code hooks, and VS Code task files for unexpected changes. Pay particular attention to environments holding cloud credentials, infrastructure secrets, repository tokens, deployment credentials, or wallet-related material.

Finally, review identities rather than only files. The reported malware was designed to locate and exfiltrate credentials, and the attack used a compromised maintainer identity to publish packages. Teams should determine which credentials were available to affected builds and whether those credentials remain valid. Repository activity and newly created GitHub repositories also deserve scrutiny, given Wiz’s description of the exfiltration path.

A software supply-chain incident is not finished when the malicious package is removed. If the package executed inside a privileged runner, the package was only the initial foothold. The real question is what that runner could read, sign, deploy, or impersonate.

For oracle and Web3 teams, the warning is blunt: dependency trust is part of key management. A compromised npm package can become an attack vector against the entire off-chain control plane long before anyone notices an on-chain anomaly.