Inside the SAP npm Package Attack: Q&A on Developer Tool Supply Chain Risks
<p>In late April 2025, a sophisticated supply chain attack dubbed “mini Shai-Hulud” targeted SAP-related npm packages, stealing credentials and cloud secrets from developer environments. This campaign exploited weaknesses in CI/CD pipelines and developer workflows, highlighting urgent security concerns for enterprises. Below, we answer key questions about the attack, its methods, and what it means for software supply chain protection.</p><h2 id="q1">What exactly was the “mini Shai-Hulud” supply chain attack?</h2><p>The “mini Shai-Hulud” campaign was a targeted malware attack on npm packages used in SAP’s JavaScript and cloud application development ecosystem. Malicious versions of four legitimate packages were published to the npm registry on April 29, 2025. The malware deployed installation-time code that harvested developer credentials, GitHub and npm tokens, GitHub Actions secrets, and cloud credentials from AWS, Azure, GCP, and Kubernetes environments. Researchers from <strong>SafeDep</strong>, <strong>Aikido Security</strong>, <strong>Wiz</strong>, and others identified the threat. The name references the sandworms from *Dune*, suggesting the attack’s ability to “burrow” into development workflows unnoticed.</p><figure style="margin:20px 0"><img src="https://www.infoworld.com/wp-content/uploads/2026/04/4165432-0-34330300-1777543463-SAP-shutterstock_2433092297.jpg?quality=50&strip=all" alt="Inside the SAP npm Package Attack: Q&A on Developer Tool Supply Chain Risks" style="width:100%;height:auto;border-radius:8px" loading="lazy"><figcaption style="font-size:12px;color:#666;margin-top:5px">Source: www.infoworld.com</figcaption></figure><h2 id="q2">Which specific npm packages were compromised, and how were they fixed?</h2><p>The affected packages included <code>mbt@1.2.48</code>, <code>@cap-js/db-service@2.10.1</code>, <code>@cap-js/postgres@2.2.2</code>, and <code>@cap-js/sqlite@2.2.2</code>. These are part of the SAP CAP (Cloud Application Programming) model development toolkit. After detection, the suspicious versions were quickly replaced with safe releases. However, any developer who installed the packages during the window of compromise may have been affected. The attackers used stolen tokens to publish the poisoned versions, demonstrating how credential theft can propagate supply chain risks.</p><h2 id="q3">How did the attackers compromise the npm packages initially?</h2><p>The attackers exploited a configuration gap in npm’s <strong>OpenID Connect (OIDC) trusted publishing</strong> setup for the <code>@cap-js</code> packages, allowing them to publish malicious versions without legitimate authorization. For the <code>mbt</code> package, the breach likely involved a <strong>static npm token</strong> that was stolen. By abusing these authentication weaknesses, the attackers bypassed normal security checks. SafeDep researchers noted that this type of attack is especially insidious because it leverages the trust inherent in package management systems.</p><h2 id="q4">What data did the malware exfiltrate, and how?</h2><p>The malware was designed to harvest a wide range of sensitive data in a single pass: GitHub and npm tokens, GitHub Actions secrets, and cloud credentials from AWS, Azure, GCP, and Kubernetes environments. It also attempted to persist through <strong>Visual Studio Code</strong> and <strong>Claude AI</strong> configuration files. The stolen data was encrypted and then sent to public GitHub repositories that the malware created using the victim’s own accounts. This technique made the exfiltration appear as legitimate push activity. The attackers also used stolen tokens to add malicious GitHub Actions workflows to accessible repositories and publish more poisoned packages.</p><h2 id="q5">What broader implications does this attack have for CISOs and enterprise security?</h2><p>This campaign underscores that developer workstations and CI/CD pipelines are now prime targets. As <strong>Sakshi Grover</strong> of IDC noted, attackers treat the developer environment as a “master key” because a single compromised identity can unlock the entire supply chain. For CISOs, the attack shows how quickly a tainted dependency can skip traditional safeguards and spread. It also highlights that developer tools are often governed less rigorously than production systems. The attack leveraged AI-assisted coding tools (Claude Code) for persistence, indicating that AI-augmented development introduces new attack surfaces. Enterprises must strengthen identity governance for developer accounts, implement continuous monitoring of build pipelines, and invest in automated supply chain risk analysis.</p><figure style="margin:20px 0"><img src="https://www.infoworld.com/wp-content/uploads/2026/04/4165432-0-34330300-1777543463-SAP-shutterstock_2433092297.jpg?quality=50&amp;strip=all&amp;w=1024" alt="Inside the SAP npm Package Attack: Q&A on Developer Tool Supply Chain Risks" style="width:100%;height:auto;border-radius:8px" loading="lazy"><figcaption style="font-size:12px;color:#666;margin-top:5px">Source: www.infoworld.com</figcaption></figure><h2 id="q6">Are enterprises prepared for such supply chain attacks with AI-driven defenses?</h2><p>According to IDC’s Asia Pacific Security Survey 2025, 46% of enterprises plan to deploy AI for third-party and supply chain risk analysis within the next 12 to 24 months. However, most organizations are still in the planning stage and have not yet operationalized AI-driven defenses. The “mini Shai-Hulud” attack demonstrates the need for faster adoption. Current manual review of dependencies cannot scale to detect malicious installation-time behavior. Automated tools that analyze package behavior, token usage anomalies, and suspicious outbound connections are becoming essential. Without such defenses, attacks that exploit trusted publishing gaps and credential theft will continue to succeed.</p><h2 id="q7">What lessons can development teams draw from this incident?</h2><p>Development teams should adopt a “least privilege” approach for tokens and CI/CD secrets, rotate them frequently, and use short-lived credentials via OIDC where possible. They should also monitor for unexpected package updates and verify hashes of installed dependencies. Implementing <strong>GitHub Actions</strong> security scanning and npm audit tools can help. Importantly, teams should treat developer workstations as critical assets, with endpoint detection and response (EDR) tools that can flag credential-stealing malware. The attack also highlights the risk of third-party AI coding assistants; their configuration files should be secured and monitored. Finally, a robust incident response plan that includes quarantining compromised packages and revoking all tokens is crucial.</p>
Tags: