The keyv npm Attack: Why Your Software Supply Chain Is a DPDP Security Obligation

A Dependency You Never Installed Can Breach Your Data

On 4 August 2026, a supply chain worm compromised the keyv and cacheable npm package families and spread through stolen npm publishing credentials to packages owned by other maintainers, including packages under the Qlik and uma.cloud scopes. Within hours of the first publication, Socket’s live campaign tracker had logged more than 2,200 malicious package artifacts across more than 440 unique packages. The compromised versions included keyv@6.0.0, flat-cache@6.1.24, file-entry-cache@11.1.6, cacheable-request@13.0.20, cache-manager@7.2.10 and several scoped @keyv/* and @cacheable/* packages.

keyv alone recorded 155 million downloads in the week ending 4 August 2026, per the npm registry’s download API. Most of those downloads are indirect: the common chain runs eslint to file-entry-cache to flat-cache to keyv. Most organisations that received the malicious package never installed it directly. They installed a linter, a build tool, or an application framework, and the compromised code arrived inside the dependency tree.

This briefing explains what the attack did, why it is a DPDP matter for every Indian data fiduciary, and what your organisation should do today.

Why a Supply Chain Attack Is a Data Protection Matter

Section 8(5) of the DPDP Act requires every data fiduciary to implement reasonable security safeguards to prevent personal data breaches. A compromised dependency is not an IT inconvenience. It is a breach vector.

The keyv worm does three things that directly implicate personal data:

1. It harvests credentials and secrets. The payload queries cloud instance metadata services, reads AWS, GCP and Azure credential chains, HashiCorp Vault tokens, Kubernetes service account tokens, and npm and GitHub tokens. It runs a TruffleHog-style sweep for keys, bearer tokens and private key blocks across the machine. CI runners that build your software are prime targets.
2. It extracts what the machine can reach. A developer workstation or CI runner holds database credentials, cloud keys, and often customer data in transit or in test fixtures. The sweep is designed to find exactly that material.
3. It propagates through your identity. The worm uses the victim’s npm account to publish further trojanized versions, so a single compromised token in your build pipeline extends the campaign from packages you use to packages you publish.

Under the DPDP Act, a breach caused by an outdated or compromised dependency is treated like any other breach: the notification duty under Section 8(6), documented response, and penalty exposure up to the caps in the Schedule to the Act, including the ₹250 crore upper bound for failure to maintain reasonable security safeguards. Rule 7 of the DPDP Rules 2025 adds the operational detail, notification to affected Data Principals without delay and a detailed report to the Data Protection Board within 72 hours, and becomes enforceable on 13 May 2027. The preparation window is now.

How the Attack Worked

The malicious packages were engineered to look clean. The published library code was byte-identical to the legitimate release. Only the package manifest and two additional files were changed. All malicious behaviour lived in a preinstall hook: node setup.mjs.

Stage one: the loader. The hook downloads a standalone Bun runtime from a public release URL, with no checksum verification, and executes a second stage under Bun. This bypasses security tooling that monitors only Node processes. The loader detects the platform and architecture, including Alpine and musl variants.

Stage two: the payload. The second stage is a roughly 728 KB bundle with strings protected by polymorphic basE91 encoding. Its modules are labelled [collector], [dispatcher], [provenance] and [publish]. The collector gathers credentials. The publish module downloads other packages, injects the same hook, recomputes integrity fields, and republishes them through the victim’s npm identity using OIDC trusted publishing. The provenance module mints fresh sigstore attestations, so the republished malware ships with newly generated, verifiable provenance.

Persistence beyond npm. The worm plants autostart hooks in .claude/settings.json (a SessionStart hook) and .vscode/tasks.json (a folderOpen task). These execute the loader when a developer or an AI coding agent opens a cloned repository, with no npm install required. It also installs a host-level dead-man’s switch: a background service named gh-token-monitor that polls GitHub with the stolen token every 60 seconds and executes a remote-supplied command the moment the token is revoked or rotated.

That last mechanism matters for incident response. If you suspect compromise and immediately revoke credentials, the revocation itself can trigger the payload. The correct order is to remove the implant first, then rotate.

The Structural Lesson: Provenance Is Not Integrity

The single most important finding of the incident is that keyv@6.0.0 shipped with a passing sigstore attestation. The legitimate release workflow built already-trojanized source, so the attestation verified successfully.

A valid signature proves that a build pipeline ran. It does not prove that the source built was authentic. Attestation is evidence of process, not proof of integrity.

This is the same distinction that governs audit evidence in data protection. A signed log entry proves that a system wrote it. It does not prove that the underlying action was lawful, consented to, or complete. That is why the DPDP compliance record cannot be a single signed artifact. It requires attribution, timestamps, documented legal basis, and an audit trail that connects each record to the decision that produced it. Systems that rely on signatures alone inherit the same blind spot this attack exposed: the pipeline can be trustworthy while the input to the pipeline is not.

Indicators of Compromise

If you have a Node.js codebase, check for these artifacts:

• setup.mjs in a package root or repository root, and a preinstall script referencing it
• Math_Symbol.js (npm tarball payload) or math_init.js (repository payload)
• A gh-token-monitor.sh script under ~/.local/bin, a gh-token-monitor directory under ~/.config, a LaunchAgent or systemd unit named com.user.gh-token-monitor, or logs under /tmp/gh-token-monitor
• A SessionStart hook in any .claude/settings.json or a folderOpen task in any .vscode/tasks.json that references a downloaded script
• Unexpected package versions published from your npm account, or unexpected repositories and commits on your GitHub account

Socket’s live campaign page maintains the current list of affected packages and versions.

What Every Data Fiduciary Should Do

Immediately

1. Check your dependency trees for the affected packages and versions. Run npm ls keyv cacheable-request cache-manager flat-cache file-entry-cache in each project and compare against the campaign list.
2. If any affected version is present, pin every affected package to the version immediately prior to the malicious release and rebuild from lockfiles. Do not allow caret or tilde ranges to resolve fresh versions while the maintainer account remains compromised.
3. Verify whether any compromised version ever ran on a machine that held production credentials. Treat those hosts as compromised.

As a standing practice

4. Commit lockfiles and install from them. Prefer exact versions with integrity hashes.
5. Treat install scripts as code. Block package lifecycle scripts by default and approve them explicitly.
6. Inventory your software supply chain. An SBOM is the technical counterpart of your data inventory under the DPDP Act: you cannot secure what you cannot enumerate.
7. Keep CI credentials short-lived. Prefer OIDC tokens over long-lived secrets, and restrict access to cloud metadata services where possible.
8. Monitor npm and GitHub accounts for unexpected publishes, new repositories and unusual commits. Enable two-factor authentication and use granular tokens.
9. Review hook files in .claude and .vscode before opening any cloned repository with an editor or an AI coding agent. Hook files now execute without an install step.
10. Align incident response with your DPDP obligations. When a credential may be stolen, remove implants before rotating credentials, then document the response as part of your breach readiness record.

The Compliance Record Must Prove What Signatures Cannot

This attack is a case study in why security and compliance evidence must be structurally tamper-evident rather than merely signed. ConsentOS builds the audit record around attributed, timestamped consent capture and documented retention decisions, so the record carries the context that signatures cannot: who consented, when, for what purpose, and on what legal basis the data was retained or erased.

A signed artifact tells you a process ran. The audit trail tells you what the process did. Under the DPDP Act, the second is what an inspection will ask for.

Run the free DPDP gap assessment to see where your organisation stands on security safeguards, data inventory and breach readiness.

Sources

• Socket Research Team. “Popular npm Packages in the keyv and Cacheable Namespaces Compromised in Active Supply Chain Attack.” 4 August 2026.
• Socket. Live campaign page: keyv and cacheable compromise. 4 August 2026.
• npm registry: download statistics and publish history for keyv and file-entry-cache, accessed 6 August 2026. The registry publish record is the authoritative source for the malicious file-entry-cache version (11.1.6, published 10:13 UTC and since removed).