npm and PyPI Supply-Chain Compromise (Mini Shai-Hulud): How Indian Dev Teams Should Respond

For most engineering teams, a dependency in package.json or requirements.txt feels like settled infrastructure — you installed it once, it worked, you stopped thinking about it. The supply-chain campaign that played out across the npm and PyPI registries in late April and May 2026 is a hard reminder that a “trusted” package is really just code from a stranger that you run with full privileges every time you build. This post is a calm, defensive walkthrough for Indian engineering leaders, DevOps and AppSec teams, and founders: what was disclosed, why it matters to your own pipeline, and the concrete steps to check exposure and remediate — even if you do not have a dedicated security team.

What was publicly disclosed

Security vendors and registries reported a self-propagating worm widely referred to as “Mini Shai-Hulud,” the latest in a family of supply-chain attacks attributed to a financially motivated group. Tenable’s advisory tracks it as CVE-2026-45321 with a CVSS score of 9.6, and states the campaign was active from late April 2026, with malicious package versions published in waves (reporting points to activity around 29 April and 11–12 May 2026).

On scale, Tenable’s advisory states that over 170 packages were affected, carrying more than 518 million cumulative weekly downloads. Orca Security reported the compromise spanned over 160 npm packages plus a small number of PyPI packages, across several hundred malicious package-version entries. Both attribute the activity to the same actor and place it as one wave of a longer-running campaign that first surfaced in 2025. Widely used names were caught up in it: reporting from Tenable and Orca names projects including TanStack, Mistral AI, UiPath and Guardrails AI among the affected namespaces.

At a high level — and that is the only level a defender needs — the compromised packages executed code at install time and harvested credentials (npm/registry tokens, GitHub tokens, cloud keys, SSH keys and CI/CD secrets), then used what they stole to publish poisoned versions of further packages. That is the part that makes it a worm: every developer or build agent that pulled a bad version could become the next launch point, with no further action from the attacker. Notably, Tenable observed that some compromised packages still carried valid build-provenance attestations — meaning a green “verified build” badge is not, on its own, proof that code is safe.

Why this is a business risk to your pipeline

The reason a registry compromise is so dangerous is that the malicious code runs in the most privileged places you own. Walk the chain a typical Indian SaaS or product team operates:

• Developer laptop — a routine npm install or pip install runs install scripts with the developer’s full local access: cloud CLI credentials, SSH keys, browser-session tokens, the lot.
• CI/CD runner — your build agent installs the same dependencies, and it usually holds the crown jewels: deploy keys, registry publish tokens, cloud service-account credentials, signing keys.
• Cloud and production — stolen cloud keys can be used to read data stores, spin up resources, or push tampered artefacts into your release path.
• Customer data — if any of that touches personal data of Indian users, you are squarely inside the Digital Personal Data Protection (DPDP) Act’s expectations on safeguards and breach handling. A dependency you never wrote can become a reportable incident you have to own.

The uncomfortable shift is that this risk does not depend on you writing insecure code. You can pass every code review and still be compromised by a package you updated on a Tuesday. That is what “software supply chain security” now means in practice.

How to check your exposure

This is a defensive audit, not an investigation you need a forensics lab for. Start here:

• Search your lockfiles and SBOMs for the affected package names and versions named in the Tenable and Orca advisories. Lockfiles (package-lock.json, pnpm-lock.yaml, poetry.lock) are the source of truth for what actually got installed — not the looser ranges in your manifest.
• Review recent installs and CI runs across the affected window (roughly late April through mid-May 2026). Look at when dependencies were last bumped and which builds ran in that period.
• Look for unexpected outbound connections from developer machines and build runners during that window — connections to destinations your build has no reason to talk to.
• Treat “maybe” as “yes.” If a potentially affected package was anywhere in your tree and any secret was reachable from that context, plan to rotate it. The cost of an unnecessary rotation is small; the cost of a missed one is a breach.

Remediation checklist

Exposure area to remediation, at a glance:

The priority actions

1. Rotate everything that could have been exposed — registry tokens, CI secrets, cloud keys, SSH and GitHub credentials. Assume harvest, then invalidate.
2. Pin dependencies with integrity hashes so a build cannot silently pull a re-published, tampered version of a pinned package.
3. Restrict install-time scripts. Configure your package manager to not run lifecycle/install scripts by default, and allow-list only the few that genuinely need them.
4. Isolate and least-privilege your CI runners. A build agent should hold only the credentials that one job needs, for as short a time as possible — ideally ephemeral, single-use runners.
5. Enable secret scanning on your repos and CI to catch leaked credentials early — and to confirm a rotated secret is truly gone.
6. Adopt SCA and SBOM with dependency review. Software Composition Analysis plus a maintained Software Bill of Materials means that next time an advisory drops, answering “are we affected?” takes minutes, not days.
7. Vet your AI-tooling dependencies specifically. Several named packages in this campaign sat in the AI/agent ecosystem. The newest, fastest-moving corners of your dependency tree deserve the same scrutiny as the rest.

Where testing and a disclosure program fit

One-time cleanup is not the same as resilience. Two practices turn this incident into a permanent uplift. First, ongoing security testing — periodic application and pipeline assessments find the install-time-script and over-privileged-runner weaknesses before an attacker does. Our web application penetration testing checklist is a useful starting point, and a structured VAPT engagement extends that scrutiny to your build and deployment surface. Second, a vulnerability disclosure program gives outside researchers a safe, legitimate channel to report a tampered dependency or leaked secret they spot in the wild — see our guide to running a vulnerability disclosure program in India. Together they shorten the gap between “something is wrong” and “we have fixed it.”

For the primary-source detail on affected packages and timeline, Tenable’s Mini Shai-Hulud FAQ is a solid reference to keep alongside your own audit.

Frequently Asked Questions

We did not use TanStack or any of the named packages — are we safe?

Not necessarily. The named packages are the headline, but the worm self-propagated, so the full list of affected versions grew over time and transitive dependencies matter as much as your direct ones. Search your lockfiles, not just your manifests, against the latest advisory list — and if your build ran in the affected window, a precautionary secret rotation is cheap insurance.

What is the single most important thing to do first?

Rotate credentials that a compromised install could have reached — registry tokens, CI secrets and cloud keys first. The packages were reported to harvest secrets at install time, so any exposed secret should be treated as already stolen and invalidated, regardless of whether you find direct evidence.

Does the DPDP Act apply if a dependency, not our own code, caused a breach?

Yes. Under the DPDP Act, a data fiduciary is responsible for safeguarding the personal data it handles, and the route the attacker took does not change that obligation. If customer personal data was accessible from a compromised system, you should follow your breach-response and notification process. This is general guidance, not legal advice — confirm specifics with your counsel.

How do we stop being a target for the next supply-chain worm?

You cannot stop attackers from poisoning public registries, but you can shrink your blast radius: pin dependencies with integrity hashes, disable install-time scripts by default, give CI runners least privilege with short-lived credentials, and keep an SBOM so you can answer “are we affected?” instantly. Pair that with regular testing and a disclosure channel, and a future advisory becomes a routine check rather than a fire drill.

If you want help auditing your dependency exposure, hardening your CI/CD pipeline, or standing up the testing and disclosure practices above, RingSafe works with Indian product and SaaS teams to do exactly that. Get in touch with our team and we will help you turn this incident into a stronger, harder-to-compromise pipeline.