@cap-js/sqlite – v2.2.2
Supply Chain Angriffe auf SAP: Wie Sie Ihre Entwicklungs-Pipelines vor „Mini Shai-Hulud“ schützen
Die Bedrohungslandschaft für Unternehmens-IT verschiebt sich. Angreifer zielen nicht mehr nur auf Schwachstellen in produktiven Systemen ab, sondern greifen die Software-Lieferkette direkt an der Wurzel an: bei den Entwickler*innen. Eine aktuelle Welle von Angriffen auf das Node Package Manager (NPM) Ökosystem, bekannt unter dem Namen „Mini Shai-Hulud“, hat nun gezielt das SAP-Umfeld ins Visier genommen.
Was passiert, wenn Schadcode bereits bei der Installation von Standard-Paketen ausgeführt wird? Und wie können Sie Ihre SAP-Infrastruktur vor solchen raffinierten Angriffen schützen?
Die unsichtbare Gefahr: Wenn das Update zum Einfallstor wird
Proprietäre Produkte bzw. Closed-Source als auch große Open-Source-Umgebungen wie das Node.js und NPM-Ökosystem sind immer wieder Ziel von Angriffen Cyberkrimineller. Am 29. April 2026 wurden vier offizielle SAP NPM-Pakete kompromittiert – darunter zentrale Bausteine für die Entwicklung von Cloud Application Programming (CAP) Modellen und Multi-Target Applications (MTA) auf der SAP Business Technology Platform (SAP BTP).
Das Perfide an diesem Angriff: Der Schadcode wird nicht erst aktiv, wenn die entwickelte Anwendung läuft. Er führt sich bereits während der Installation des Pakets (npm install) über ein manipuliertes preinstall-Skript automatisch aus – bevor der Entwickler auch nur eine Zeile eigenen Code geschrieben hat.
BETROFFENE PAKETE (29. APRIL 2026)
@cap-js/postgres – v2.2.2
@cap-js/db-service – v2.10.1
mbt – v1.2.48
„Mini Shai-Hulud“: Die technische Anatomie des Angriffs
Die Angreifer hinter der „Mini Shai-Hulud“-Kampagne haben aus vergangenen Angriffen gelernt und ihre Methoden gezielt verfeinert. Um herkömmliche Sicherheitsmechanismen und Überwachungstools, die auf Node.js ausgerichtet sind, zu umgehen, lädt das bösartige Skript eine eigenständige JavaScript-Laufzeitumgebung namens „Bun“ herunter. Über diese Umgebung wird ein stark verschleierter, knapp 11,7 MB großer Payload ausgeführt.
So läuft der Angriff ab
- Infektion bei Installation:
Ein manipuliertes preinstall-Skript in der package.json startet automatisch beim Ausführen von npm install. - Bypass der Node.js-Sicherheit:
Das Skript lädt die JavaScript-Laufzeitumgebung „Bun“ herunter und umgeht damit alle auf Node.js ausgerichteten Sicherheitstools. - Ausführung des Payloads:
Bun führt den stark verschleierten execution.js-Payload (ca. 11,7 MB) aus. - Credential Harvesting:
Die Malware durchsucht die Maschine systematisch nach sensiblen Zugangsdaten. - Exfiltration & Verbreitung:
Gestohlene Daten werden verschlüsselt über GitHub-Repositories exfiltriert. Die Malware verbreitet sich wurmartig weiter.
Was die Malware stiehlt
- Entwickler-Tokens: GitHub-Tokens, NPM-Tokens und SSH-Schlüssel
- Cloud-Zugangsdaten: Credentials für AWS, Azure und GCP
- Infrastruktur-Schlüssel: Kubernetes-Tokens und Konfigurationsdateien von KI-Coding-Tools (z. B. Claude)
- CI/CD-Secrets: GitHub Actions Secrets und Build-Tokens aus automatisierten Pipelines
Die gestohlenen Daten werden verschlüsselt und über öffentliche GitHub-Repositories exfiltriert, die die Malware unter dem Account des Opfers mit der Beschreibung „A Mini Shai-Hulud has Appeared“ anlegt – damit sind Unternehmensgeheimnisse im schlimmsten Fall öffentlich durchsuchbar.
Der „Blast Radius“: Auswirkungen auf Ihre SAP-Infrastruktur
Die Konsequenzen eines solchen Supply Chain Angriffs sind weitreichend, weil er direkt an der Basis der Softwareentwicklung ansetzt. Entwickler-Laptops sind in der Regel mit weitreichenden Zugriffsrechten ausgestattet. Der Diebstahl von Tokens und Schlüsseln ermöglicht Angreifern den direkten Zugriff auf Quellcode, interne Systeme und Cloud-Infrastrukturen.
Noch kritischer wird es, wenn die manipulierten Pakete in automatisierten Build-Prozessen (CI/CD) installiert werden. Hier erlangt die Malware Zugriff auf hochprivilegierte Build-Secrets und Deployment-Tokens. Durch gestohlene Deployment-Credentials, SAP BTP Service Keys, HANA Service Bindings oder XSUAA-Credentials können Angreifer tief in die SAP-Infrastruktur eindringen, ganz ohne klassische SAP-Schwachstellen wie ABAP-Lücken ausnutzen zu müssen. Der Angriff zielt auf den Entwicklungspfad, der direkt in die Produktion führt.
Besonders gefährdet sind Unternehmen, die …
- SAP CAP-Anwendungen oder Node.js-Services für SAP BTP entwickeln
- MBT- oder MTA-basierte Deployment-Workflows nutzen
- automatisierte CI/CD-Pipelines mit Zugriff auf SAP Cloud-Produkte wie die SAP BTP oder Versionierungsplatformen wie GitHub betreiben
- lose Versionsangaben (Caret- oder Tilde-Versioning) in Entwicklungs-Dependencies verwenden
- Keinen definierten Prozess zur Reaktion auf solche Schadpakete in Entwicklungsumgebungen besitzen
DevSecOps: So härten Sie Ihre Software-Lieferkette
Da es sich um einen Supply Chain Angriff handelt, greifen reaktive Sicherheitsmaßnahmen oft zu spät. Die Verteidigung erfordert einen ganzheitlichen DevSecOps-Ansatz, der Sicherheit von Beginn an in den Entwicklungsprozess integriert. Folgende Maßnahmen sollten Sie umgehend prüfen und implementieren:
- Version Pinning: Legen Sie Paketversionen in der package.json strikt fest, um so automatische Updates auf potenziell kompromittierte Versionen zu verhindern und Pakete erst nach einer längeren Veröffentlichungszeit zu aktualisieren
- Cooldown-Perioden & lokale Proxies: Nutzen Sie interne Paket-Repositories, die neue Paketversionen erst nach einer Wartezeit und nach automatisierten Sicherheitsprüfungen für Ihre Entwickler*innen freigeben.
- eBPF-Monitoring in CI/CD-Pipelines: Setzen Sie Extended Berkeley Packet Filter (eBPF) in Ihren Build-Pipelines ein, um ungewöhnliches Verhalten – wie das Herunterladen externer Binaries – auf Systemebene frühzeitig zu erkennen.
- Konsequentes Secret Management: Vermeiden Sie Klartext-Secrets auf Entwicklermaschinen. Nutzen Sie stattdessen Password Manager oder Secret Vaults, die Credentials dynamisch zur Laufzeit injizieren.
- NPM-Wrapper & Malware-Schutz: Setzen Sie Tools ein, die den npm install-Prozess überwachen und bei Erkennung von Malware sofort blockieren – bevor der Schadcode ausgeführt werden kann.
- Minimale Berechtigungen (Least Privilege): Stellen Sie sicher, dass Entwickler-Tokens und CI/CD-Accounts nur die minimal notwendigen Rechte besitzen – um den „Blast Radius“ eines kompromittierten Accounts zu begrenzen.
abat als Partner für Ihre DevSecOps-Strategie
Supply Chain Angriffe wie „Mini Shai-Hulud“ zeigen deutlich: Die absolute Sicherheit gibt es nicht. Solche Vorfälle können passieren. Das strategische Ziel muss daher sein, den sogenannten „Blast Radius“ – also die potenziellen Auswirkungen eines erfolgreichen Angriffs – so gering wie möglich zu halten und gleichzeitig die Resilienz, also die Reaktion und Widerstandsfähigkeit gegen solche Vorfälle zu stärken. Wenn ein Entwickler-Account kompromittiert wird, darf dies nicht zum Fall der gesamten Unternehmens-IT führen. Außerdem muss bei Auftreten eines solchen Vorfalls im Unternehmen eine organisierte Reaktion erfolgen und ein Prozess existieren, um einen solchen Sicherheitsvorfall angemessen zu behandeln.
Genau hier setzt die abat AG an. Wir unterstützen Sie nicht nur bei der Einführung sicherer Entwicklungsrichtlinien und der Härtung Ihrer CI/CD-Pipelines im SAP BTP-Umfeld. Wir bieten Ihnen auch die Möglichkeit, Ihre Verteidigungslinien durch gezielte Penetrationstests auf die Probe zu stellen.
Pentesting als Realitätscheck
Ein solcher Pentest kann exakt das Szenario eines kompromittierten Entwickler-Accounts oder eines infizierten CI/CD-Runners simulieren. Wir zeigen Ihnen auf, wie weit ein Angreifer von diesem Punkt aus in Ihre SAP-Infrastruktur vordringen kann, und decken Schwachstellen in Ihrer internen Segmentierung und Ihrem Berechtigungskonzept auf. So wissen Sie nicht nur theoretisch, wo Ihre Risiken liegen – sondern haben den Beweis schwarz auf weiß.
FAQs:
1. Was ist der „Mini Shai-Hulud“-Angriff und wie funktioniert er?
Der „Mini Shai-Hulud“-Angriff ist ein Supply-Chain-Angriff, bei dem vier offizielle SAP NPM-Pakete kompromittiert wurden. Der Schadcode wird nicht erst zur Laufzeit der Anwendung aktiv, sondern führt sich bereits bei der Installation (npm install) über ein manipuliertes preinstall-Skript automatisch aus. Um Node.js-Sicherheitsmechanismen zu umgehen, lädt das Skript die Laufzeitumgebung „Bun“ herunter und führt darüber den eigentlichen Payload aus.
2. Welche SAP-Pakete waren von dem Angriff betroffen?
3. Welche Daten stiehlt die Malware bei einer Infektion?
4. Warum ist dieser Angriff für die SAP-Infrastruktur so gefährlich?
5. Wie können Unternehmen ihre Software-Lieferkette vor solchen Angriffen schützen?
Kontaktieren Sie unsere Expert*innen und lassen Sie uns gemeinsam Ihre DevSecOps-Strategie für SAP BTP optimieren.
abat Insights
Melden Sie sich an und erhalten Sie eine Nachricht, sobald wir neues Wissen für Sie bereitstellen.
