The recent supply chain attack targeting SAP-related npm packages—dubbed 'mini Shai-Hulud'—has exposed critical vulnerabilities in developer tools and continuous integration/continuous deployment (CI/CD) pipelines. Malicious versions of popular packages stole credentials, tokens, and cloud secrets, affecting enterprise software production. This Q&A explores the incident, its methods, and the broader implications for security teams.

What Exactly Was the 'mini Shai-Hulud' Attack?

The attack targeted npm packages used in SAP's JavaScript and cloud application development ecosystem. On April 29, threat actors published malicious versions of packages like mbt@1.2.48 and @cap-js/db-service@2.10.1. These included installation-time code that harvested sensitive data—developer credentials, GitHub and npm tokens, GitHub Actions secrets, and cloud credentials from AWS, Azure, GCP, and Kubernetes. The campaign, named after a fictional sandworm, encrypted the stolen data and exfiltrated it to public GitHub repositories created from victims' own accounts. Researchers from SafeDep, Aikido Security, and Wiz identified the campaign, noting that the malicious versions were soon replaced by safe releases. The attack highlights how a single tainted dependency can compromise an entire build process.

How Did Attackers Compromise the npm Packages?

Researchers identified two primary methods. For the @cap-js packages, the attackers exploited a configuration gap in npm's OpenID Connect (OIDC) trusted publishing setup. This allowed them to publish malicious versions without proper authorization. For the mbt package, the compromise is suspected to involve a static npm token that was leaked or stolen. Once in control, the attackers used stolen GitHub and npm tokens to inject malicious GitHub Actions workflows into accessible repositories, enabling them to propagate poisoned packages further. This dual approach—abusing OIDC misconfiguration and static token theft—shows how attackers can leverage weak points in package publishing workflows.

What Kind of Data Was Stolen, and How Was It Used?

The malware was designed to harvest a wide range of sensitive data in a single pass. It stole developer credentials, GitHub and npm tokens, GitHub Actions secrets, and cloud credentials from AWS, Azure, GCP, and Kubernetes environments. After encryption, the data was sent to public GitHub repositories created from the victims' own accounts—a clever technique that evades detection by blending in with legitimate activity. The attackers also used the stolen tokens to add malicious GitHub Actions workflows to accessible repositories and publish additional poisoned package versions. This demonstrates a sophisticated credential theft and lateral movement strategy, turning compromised developer environments into launch pads for further attacks.

How Did Attackers Attempt to Maintain Persistence?

Beyond immediate data theft, the attackers tried to maintain long-term access by targeting Visual Studio Code and Claude Code configuration files. By modifying these files, they could potentially re-infect developer workstations even after the initial malicious package was removed. This technique puts AI-assisted coding tools and developer IDEs squarely in the supply chain security crosshairs. The attackers' goal was to establish a persistent foothold that could survive clean-ups, allowing them to continue stealing credentials and injecting malicious code over time. This highlights why securing developer workstations is now as critical as securing production systems—an insight echoed by cybersecurity experts.

What Are the Key Takeaways for CISOs?

For chief information security officers (CISOs), this attack underscores how quickly a tainted dependency can escalate beyond the build process. As Sakshi Grover of IDC noted, 'Attackers now treat the developer workstation as a master key.' A single compromised developer identity in a CI/CD pipeline can give attackers a route into the wider supply chain, enabling them to push malicious code to downstream users. The case also highlights that developer environments, despite being central to software delivery, often lack the same governance rigor as production. Grover cited IDC's survey showing 46% of enterprises plan to deploy AI for third-party and supply chain risk analysis in the next 12–24 months, but many are still in planning stages. Proactive defenses—such as strict token management, OIDC configuration reviews, and AI-driven threat detection—are essential to counter attacks like mini Shai-Hulud.

How Can Organizations Defend Against Such Attacks Going Forward?

Organizations should adopt a multi-layered approach. First, enforce least privilege for npm tokens and use OIDC with tight scoping to prevent misuse. Second, implement real-time monitoring of package dependencies and CI/CD pipelines for anomalous behavior. Third, secure developer workstations with endpoint detection and response (EDR) tools and restrict configuration file modifications. Fourth, invest in AI-driven supply chain security tools that can analyze package behavior and detect tampered code. Finally, conduct regular security audits of build workflows and educate developers about credential hygiene. As the attack shows, waiting for a breach is not an option—proactive measures can prevent a single compromised package from cascading into a widespread supply chain compromise.