Mini Shai-Hulud: The npm & pip Supply Chain Vulnerability Burrowing Through Your Stack

What Is Mini Shai-Hulud?

In the security research community, threat campaigns are often named after their distinctive behaviour or the imagery they evoke. Mini Shai-Hulud — named after the massive sandworms of Frank Herbert's Dune, creatures that burrow invisibly beneath the surface and consume everything in their path — refers to a class of software supply chain attacks that silently embed themselves in the dependency ecosystems that developers trust most: npm (Node.js) and PyPI (Python).

The "Mini" prefix is deliberate. Unlike the dramatic, headline-grabbing breaches that target enterprise perimeters, these attacks are quiet, precise, and devastatingly effective. They do not knock on the front door. They arrive as a perfectly ordinary-looking library that a developer installs in thirty seconds without a second thought.

What makes this campaign particularly dangerous is its targeting: it does not discriminate between Fortune 500 companies and five-person startups. Every organisation that uses open-source packages — which is effectively every organisation that writes software — is in scope.

How the Attack Works

Mini Shai-Hulud exploits three well-understood but persistently under-defended attack surfaces in open-source software ecosystems. Understanding each vector is essential for building effective defences.

1. Typosquatting

The most common entry point. Attackers register package names on npm or PyPI that closely resemble legitimate, widely-used libraries — differing by a single transposed letter, a hyphen instead of an underscore, or a common misspelling. Examples from observed campaigns include packages like reqeusts (vs. the legitimate requests), colourama (vs. colorama), and setup-tools (vs. setuptools).

Developers install these by accident — a single typo in a pip install or npm install command, a copy-paste error from a tutorial, or an AI-generated code suggestion that retrieved a slightly wrong package name. The malicious package runs its install scripts immediately, before the developer has any opportunity to review the code.

2. Dependency Confusion

First documented at scale in 2021 by security researcher Alex Birsan, dependency confusion exploits the way package managers resolve private (internal) packages versus public registry packages. If an organisation uses an internal package — say, acme-internal-auth — and an attacker publishes a public package with the same name on npm or PyPI with a higher version number, many package managers will preferentially install the public version over the private one.

The attack requires only that the attacker know (or guess) the names of internal packages — information that frequently leaks through job postings, public GitHub repositories, error messages, or even stack traces shared on developer forums. Once the attacker's public package is installed, it executes with the full privileges of the build system or CI/CD pipeline that triggered the install.

3. Malicious Maintainer Takeovers

This is arguably the most insidious vector. Attackers identify npm or PyPI packages that are widely used but have a single maintainer who has become inactive — perhaps they changed jobs, moved to a different technology stack, or simply abandoned the project. The attacker contacts the maintainer (or, in some cases, gains access to the maintainer's account through credential stuffing or phishing) and either requests a transfer or directly compromises the account.

Once in control of a legitimate, trusted package, the attacker publishes a new version containing a malicious payload. Because the package already has an established reputation — potentially millions of weekly downloads — few developers or security tools flag the update as suspicious. The malicious code rides the next automated dependency update directly into production environments.

What the Payload Does

The payloads observed in Mini Shai-Hulud campaign variants follow a consistent pattern, though the specific implementation varies. Common post-installation behaviours include:

• Environment variable exfiltration: The install script reads environment variables — which in CI/CD systems routinely contain API keys, cloud credentials, database passwords, and authentication tokens — and transmits them to an attacker-controlled server via an HTTPS request. This can happen in under a second, silently, with no visible output.
• SSH key and credential harvesting: On developer workstations, the malicious package searches for ~/.ssh/ directories, credential files, AWS config files, and browser-stored passwords. These are compressed and exfiltrated.
• Persistence mechanisms: Some variants drop a persistent backdoor — modifying shell startup files (.bashrc, .zshrc), creating scheduled tasks, or establishing a reverse shell that allows the attacker to return to the compromised system at will.
• Lateral movement via CI/CD: When packages are installed in GitHub Actions, GitLab CI, or similar pipelines, the attack can exfiltrate repository secrets and pipeline tokens. With access to these, attackers can modify source code, inject malicious commits, or pivot to cloud infrastructure.
• Cryptomining: In lower-sophistication campaigns, the payload simply deploys a cryptocurrency miner, consuming compute resources at the organisation's expense. While less damaging than credential theft, this is a clear indicator of compromise.

Real-World Impact: What Happens After Compromise

The downstream consequences of a supply chain compromise depend heavily on where in the software development lifecycle the malicious package was installed:

Developer Workstation Compromise

If a developer installs a malicious package locally, the attacker gains access to that developer's environment — including their Git credentials (and therefore the ability to push malicious code to repositories), their SSH keys (which may allow access to servers), cloud CLI credentials, and any plaintext secrets stored in .env files or shell history.

CI/CD Pipeline Compromise

This is the highest-impact scenario. Modern CI/CD pipelines run with elevated permissions — they need to push container images, deploy to cloud environments, update databases, and interact with external services. An attacker who gains access to a CI/CD pipeline via a malicious dependency can effectively do anything the pipeline can do: deploy malicious code to production, exfiltrate secrets from the secrets manager, modify infrastructure-as-code, or create persistent backdoors in cloud environments.

Production Runtime Compromise

If malicious packages make it past development and CI/CD into production runtime environments (a Docker container, a serverless function, a server process), the attacker has access to production data, internal network segments, and any credentials the application uses at runtime — database connection strings, API keys, session signing secrets, encryption keys.

Why Indian SMEs and Startups Are Particularly Exposed

Several factors make Indian SMEs and technology startups especially vulnerable to supply chain attacks of this type:

• Heavy reliance on open-source: India's startup and SME technology ecosystem is built heavily on open-source frameworks and libraries. This is a strength in terms of velocity and cost, but it creates a large attack surface that requires active management.
• Limited dependency governance: Most SMEs and startups do not have formal processes for reviewing new dependencies before they are added to codebases. Developers install packages freely, and there is no gate that checks for signs of malicious intent.
• Unprotected CI/CD pipelines: Smaller organisations frequently configure CI/CD pipelines with overly broad permissions ("give it admin access so it doesn't break") and do not rotate the credentials that pipelines use. A single compromise of the pipeline can therefore have organisation-wide impact.
• Secrets in environment variables without rotation: Long-lived, never-rotated credentials are the norm in many SME environments. Once exfiltrated, these credentials may remain valid for months or years — giving attackers sustained access long after the initial compromise.
• No runtime monitoring: Without endpoint detection or runtime application monitoring, malicious package activity (outbound connections, unexpected file reads) goes undetected.

How to Detect If You Are Already Affected

Detection is challenging precisely because supply chain attacks are designed to be quiet. However, there are practical steps organisations can take:

• Audit your installed packages: Run npm audit or pip-audit and cross-reference your installed packages against known malicious package databases (Snyk, OSV, NIST NVD). Tools like socket.dev and deps.dev can provide supply chain risk scoring for packages.
• Review outbound network connections: Look for unexpected outbound HTTPS connections originating from CI/CD pipelines, build servers, or developer workstations — particularly to unfamiliar IP addresses or newly registered domains.
• Audit recent CI/CD runs: Review the logs of recent pipeline runs for unexpected steps, unusual package installs, or error messages that indicate something unexpected was executed during the build.
• Check for new SSH keys and scheduled tasks: On developer workstations and build servers, look for recently added SSH keys in ~/.ssh/authorized_keys, new cron jobs, and modifications to shell startup files.
• Review cloud access logs: If your CI/CD pipeline has cloud access, review CloudTrail (AWS), Audit Logs (GCP/Azure) for unusual API calls made during or after recent pipeline runs.

How to Protect Your Organisation

Defending against supply chain attacks requires layering controls across the software development lifecycle. No single measure is sufficient on its own.

Pin Your Dependencies

Instead of allowing package managers to automatically install the latest version of a dependency, pin every dependency to a specific, known-good version and commit the lock file (package-lock.json, Pipfile.lock, poetry.lock) to version control. This prevents unexpected updates from automatically pulling in malicious new versions. Treat every dependency update as a deliberate decision, not an automated action.

Enforce Private Package Scoping

For internal packages, use npm scopes (@your-org/package-name) or configure your package manager to resolve internal packages exclusively from your private registry. This eliminates the dependency confusion attack vector entirely for well-scoped packages.

Use a Software Composition Analysis (SCA) Tool

Integrate an SCA tool — such as Snyk, Dependabot, FOSSA, or Socket — into your CI/CD pipeline. These tools check each dependency against databases of known malicious and vulnerable packages and can block the pipeline if a problematic package is detected. Configure the tool to block builds, not just warn.

Apply Least Privilege to CI/CD

CI/CD pipelines should have only the permissions they need for each specific job — and no more. A pipeline that runs unit tests does not need deploy credentials. Use short-lived, scoped credentials (OIDC tokens for cloud access, per-job tokens for registry access) rather than long-lived secrets stored as environment variables. Rotate all CI/CD credentials regularly.

Enable Runtime Application Security Monitoring

Deploy an agent-based runtime security tool (Falco, Aqua, Sysdig, or similar) in your build and production environments. These tools can detect anomalous behaviour — such as a package install script attempting to read SSH keys or establish an outbound connection — and alert or block in real time.

Developer Security Awareness

Train your development team to verify package names carefully before installing, to review install scripts in packages they are unfamiliar with, and to treat unsolicited pull requests that add new dependencies as a security event. Many successful supply chain attacks begin with a developer installing a package from a tutorial, a Stack Overflow answer, or an AI code completion suggestion without verifying it.

The Broader Picture: Supply Chain Risk Is Now a Board-Level Issue

The Mini Shai-Hulud campaign is not an isolated phenomenon. Supply chain attacks via package ecosystems increased dramatically over the 2022–2025 period, and the trajectory is upward. CERT-In has flagged software supply chain security as a priority area in its advisories, and SEBI CSCRF's vendor and third-party risk management requirements implicitly cover the software supply chain for regulated entities.

For organisations that ship software — or that rely on internally developed software for their operations — supply chain risk is no longer a purely technical concern. A single compromised dependency can result in a production breach, regulatory notification obligations under the DPDP Act, and significant reputational damage.

How InfraDefend Can Help

InfraDefend offers supply chain security assessments for SMEs and startups — covering your package dependency posture, CI/CD pipeline security, secrets management practices, and runtime monitoring. If you are unsure whether your development environment is exposed to attacks like Mini Shai-Hulud, we can give you a clear picture and a practical remediation roadmap. Reach out for a free initial conversation.