@cap-js/sqlite – v2.2.2
Supply Chain Attacks on SAP: How to Protect Your Development Pipelines from “Mini Shai-Hulud”
The threat landscape for enterprise IT is shifting. Attackers no longer target only vulnerabilities in production systems but attack the software supply chain right at its root: the developers. A recent wave of attacks on the Node Package Manager (NPM) ecosystem, known as “Mini Shai-Hulud,” has now specifically targeted the SAP environment.
What happens if malicious code is executed during the installation of standard packages? And how can you protect your SAP infrastructure from such sophisticated attacks?
The invisible threat: When the update becomes a gateway
Proprietary products and closed-source software, as well as large open-source environments such as the Node.js and NPM ecosystem, are repeatedly targeted by cybercriminals. On April 29, 2026, four official SAP NPM packages were compromised – including key components for developing Cloud Application Programming (CAP) models and Multi-Target Applications (MTA) on the SAP Business Technology Platform (SAP BTP).
The insidious nature of this attack: The malicious code does not become active only after the developed application is running. It executes automatically during the package installation (npm install) via a manipulated preinstall script – before the developer has even written a single line of their own code.
AFFECTED PACKAGES (APRIL 29, 2026)
@cap-js/postgres – v2.2.2
@cap-js/db-service – v2.10.1
mbt – v1.2.48
“Mini Shai-Hulud”: The technical anatomy of the attack
The attackers behind the “Mini Shai-Hulud” campaign have learned from past attacks and specifically refined their methods. To bypass conventional security mechanisms and monitoring tools designed for Node.js, the malicious script downloads a standalone JavaScript runtime environment called “Bun.” A heavily obfuscated payload, just under 11.7 MB in size, is executed via this environment.
Here’s how the attack unfolds
- Infection during installation:
A tampered preinstall script in package.json automatically launches when npm install is executed. - Bypassing Node.js security:
The script downloads the JavaScript runtime environment “Bun,” thereby bypassing all security tools targeting Node.js. - Execution of the payload:
Bun executes the heavily obfuscated execution.js payload (approx. 11.7 MB). - Credential harvesting:
The malware systematically scans the machine for sensitive login credentials. - Exfiltration & propagation:
Stolen data is exfiltrated in encrypted form via GitHub repositories. The malware spreads like a worm.
What the malware steals
- Developer tokens: GitHub tokens, NPM tokens, and SSH keys
- Cloud credentials: Credentials for AWS, Azure, and GCP
- Infrastructure keys: Kubernetes tokens and configuration files from AI coding tools (e.g., Claude)
- CI/CD secrets: GitHub Actions secrets and build tokens from automated pipelines
The stolen data is encrypted and exfiltrated via public GitHub repositories, which the malware creates under the victim’s account with the description “A Mini Shai-Hulud has Appeared” – meaning that, in the worst-case scenario, corporate secrets are publicly searchable.
The “Blast Radius”: Impact on your SAP infrastructure
The consequences of such a supply chain attack are far-reaching because it strikes directly at the foundation of software development. Developer laptops are typically equipped with extensive access rights. The theft of tokens and keys enables attackers to gain direct access to source code, internal systems, and cloud infrastructures.
The situation becomes even more critical when the manipulated packages are installed in automated build processes (CI/CD). Here, the malware gains access to highly privileged build secrets and deployment tokens. Through stolen deployment credentials, SAP BTP service keys, HANA service bindings, or XSUAA credentials, attackers can penetrate deep into the SAP infrastructure without having to exploit classic SAP vulnerabilities such as ABAP flaws. The attack targets the development path that leads directly to production.
Companies that …
- Develop SAP CAP applications or Node.js services for SAP BTP
- Use MBT- or MTA-based deployment workflows
- Operate automated CI/CD pipelines with access to SAP cloud products such as SAP BTP or versioning platforms like GitHub
- Use loose versioning (caret or tilde versioning) in development dependencies
- Have no defined process for responding to malicious packages in development environments
DevSecOps: How to harden your Software Supply Chain
Since this is a supply chain attack, reactive security measures often come too late. Defense requires a holistic DevSecOps approach that integrates security into the development process from the very beginning. You should immediately review and implement the following measures:
- Version Pinning: Strictly specify package versions in package.json to prevent automatic updates to potentially compromised versions and to update packages only after a longer release window.
- Cooldown periods & local proxies: Use internal package repositories that only release new package versions to your developers after a waiting period and following automated security checks.
- eBPF Monitoring in CI/CD Pipelines: Implement Extended Berkeley Packet Filter (eBPF) in your build pipelines to detect unusual behavior – such as the downloading of external binaries – at the system level early on.
- Consistent secret management: Avoid storing secrets in plain text on developer machines. Instead, use password managers or secret vaults that dynamically inject credentials at runtime.
- NPM Wrappers & Malware Protection: Use tools that monitor the npm install process and immediately block it upon detection of malware – before the malicious code can be executed.
- Least Privilege: Ensure that developer tokens and CI/CD accounts have only the minimum necessary permissions – to limit the “blast radius” of a compromised account.
abat as a partner for your DevSecOps Strategy
Supply chain attacks like “Mini Shai-Hulud” clearly demonstrate that absolute security does not exist. Such incidents can happen. The strategic goal must therefore be to keep the so-called “blast radius” – that is, the potential impact of a successful attack – as small as possible while simultaneously strengthening resilience, meaning the ability to respond to and withstand such incidents. If a developer account is compromised, this must not lead to the collapse of the entire corporate IT infrastructure. Furthermore, when such an incident occurs within the company, there must be an organized response and a process in place to handle the security incident appropriately.
This is exactly where abat AG comes in. We not only support you in implementing secure development guidelines and hardening your CI/CD pipelines in the SAP BTP environment. We also offer you the opportunity to put your defenses to the test through targeted penetration tests.
Penetration Testing as a Reality Check
Such a pentest can precisely simulate the scenario of a compromised developer account or an infected CI/CD runner. We’ll show you how far an attacker can penetrate your SAP infrastructure from this point and uncover vulnerabilities in your internal segmentation and authorization model. This way, you won’t just know where your risks lie in theory – you’ll have proof in black and white.
FAQs:
The “Mini Shai-Hulud” attack is a supply chain attack in which four official SAP NPM packages were compromised. The malicious code is not executed at application runtime but instead runs automatically during installation (npm install) via a manipulated preinstall script. To bypass Node.js security mechanisms, the script downloads the “Bun” runtime environment and executes the actual payload through it.
Contact our experts and let’s work together to optimize your DevSecOps strategy for SAP BTP.