Mini Shai-Hulud infects 1,800 devs

- SecurityWeek reports the “Mini Shai-Hulud” supply-chain campaign likely infected more than 1,800 developers via compromised SAP, Lightning and Intercom packages. - CyberPress describes a parallel campaign targeting GitHub Actions via malicious Ruby gems and Go modules that masquerade as legitimate dependencies. - These attacks make CI pipelines, package provenance and registry hygiene first-class parts of agent observability and threat models. (securityweek.com) (cyberpress.org)

A software supply-chain attack is what happens when the thing you trust to build software becomes the thing that infects it. That is the story here. Over April 29 and 30, attackers slipped credential-stealing code into real packages across npm, PyPI, and Packagist, then used the stolen secrets to fan the infection out further. By May 1, researchers were saying the “Mini Shai-Hulud” wave had likely touched more than 1,800 repositories tied to stolen developer credentials, with SAP-related npm packages, `lightning` on PyPI, and `intercom-client` on npm all caught in the blast radius. Why does “1,800 developers” matter so much? Because this was not just a typo-squatting scam where someone uploads a fake package and waits. The campaign appears to have used compromised maintainer credentials and package updates inside legitimate projects. That is the hard version of the trick. Developers and CI systems often pin to real package names and trust routine updates. When the real package goes bad, a lot of normal defenses stop helping. Security researchers tied the wave to a group calling itself TeamPCP and described it as a continuation of the broader Shai-Hulud activity seen in late 2025. What actually got poisoned? On the SAP side, four npm packages in SAP’s JavaScript and cloud application development ecosystem were flagged — `mbt@1.2.48`, `@cap-js/db-service@2.10.1`, `@cap-js/postgres@2.2.2`, and `@cap-js/sqlite@2.2.2`. Then the same wave spread into other ecosystems. Researchers found malicious versions `lightning@2.6.2` and `2.6.3` on PyPI, plus `intercom-client@7.0.4` and `7.0.5` on npm. The striking part is the cross-ecosystem coordination — same basic goal, different package managers, very little time between hits. What did the malware want? Secrets. The poisoned packages were built to steal developer and CI credentials, including tokens that can open the door to source repos, package registries, and cloud environments. In the SAP package case, researchers said the malicious code even pulled in the Bun runtime as part of the install chain, which is unusual enough that it helped tip defenders off. Once an attacker has those secrets, the next move is obvious — publish another malicious update, tamper with workflows, or pivot into private infrastructure. Is this the same thing as the GitHub Actions campaign? Not exactly, but it rhymes. A separate campaign uncovered at the same time used malicious Ruby gems and Go modules tied to a GitHub account called BufferZoneCorp. Those packages were dressed up to look like normal developer tooling, then used to steal secrets, tamper with GitHub Actions environments, and in some cases establish persistence. That campaign looks like a parallel operation rather than the same codebase, but the lesson is identical — CI is now part of the attack surface, not just the plumbing around it. Why are CI pipelines such a juicy target? Because they sit in the middle of everything. A developer laptop has some secrets. A CI runner often has all of them — repo access, signing keys, package publish tokens, cloud credentials, deployment permissions. Compromise one build job and you can poison the artifact that every downstream user installs. It is the software equivalent of getting into a bakery by contaminating the flour instead of sneaking into every kitchen one by one. What changes now? Teams have to treat package provenance, maintainer account security, and registry hygiene as first-class controls. That means verifying where dependencies came from, locking down publish credentials, rotating any exposed tokens, and watching CI for weird install-time behavior — especially unexpected network calls or new runtimes appearing during builds. The old model was “scan the code we wrote.” The new model is “watch the code that arrived before ours even started.” The bottom line is simple. Open-source package managers are still the fastest way to ship software, but they are now one of the fastest ways to spread malware too. Mini Shai-Hulud matters because it shows how little time attackers need to jump from one ecosystem to three — and how much damage a stolen maintainer token can do before anyone notices.

Get your own daily briefing

Scout delivers personalized news, insights, and conversations tailored to your role and industry.

Download on the App Store

Shared from Scout - Be the smartest in the room.