Neuartiger Angriff auf die Lieferkette („Mini Shai-Hulud“), der auf das SAP Cloud -Ökosystem abzielt

Am 30. April 2026, im Anschluss an die Veröffentlichung dieses Blogbeitrags, veröffentlichte SAP einen neuen Sicherheitshinweis (3747787), der sich mit den vier schädlichen Open-Source-Paketen befasst, die im NPM-Ökosystem verbreitet wurden.

Onapsis beobachtet aufmerksam einen raffinierten Angriff auf die Lieferkette, der sich gegen SAP-Entwickler und Unternehmen richtet, die das SAP Cloud Programming (CAP)-Modell nutzen.

Dieser Angriff, der als Variante des „Shai-Hulud“-Wurms identifiziert wurde, beinhaltet das Einschleusen von Schadcode in weit verbreitete SAP-npm-Pakete. Das Hauptziel dieser Malware ist der automatisierte Diebstahl von cloud , Service-Tokens und privaten Schlüsseln.

Das schädliche Paket war am 29. April 2026 für einen Zeitraum von zwei bis vier Stunden verfügbar. Falls einer Ihrer Entwickler das betreffende Paket bzw. die betreffenden Pakete in dem Zeitraum heruntergeladen hat, in dem die schädlichen Versionen verfügbar waren, sind Sie möglicherweise betroffen. Es wurden bereinigte Versionen der Pakete veröffentlicht, um die infizierten Versionen zu ersetzen. Weitere Details finden Sie weiter unten.

Warum dies gerade für SAP-Kunden von Bedeutung ist

CAP ist das De-facto-Framework für nahezu alle kundenspezifischen Entwicklungen auf SAP BTP andere JavaScript-Entwicklungen außerhalb von BTP. Dazu gehören beispielsweise Side-by-Side-Erweiterungen für S/4HANA, Fiori-App-Backends, Integrationsabläufe und MTAs. Jeder SAP-Kunde, der JavaScript-Entwicklungen durchführt, bezieht möglicherweise Pakete aus den Repositorien @sap/* und @cap-js/* in seine Build-Pipelines ein, häufig mit ungenauen Versionsbereichen und zahlreichen transitiven Abhängigkeiten. 

Auch wenn diese Sicherheitslücke in der Lieferkette Entwickler im Allgemeinen betreffen könnte, dürfte sie für SAP-Kunden von besonderer Bedeutung sein, insbesondere für diejenigen, die BTP nutzen und NodeJS-Anwendungen auf BTP entwickeln, sowie für SAP-Kunden, die kundenspezifische XSA-Anwendungen, SAP-UI5-Anwendungen oder Fiori-Anwendungen entwickeln.  

Was wir bisher wissen

• Betroffene Pakete: Mehrere offizielle SAP-npm-Pakete wurden als kompromittiert identifiziert. Diese Pakete waren nur für einen begrenzten Zeitraum veröffentlicht, wodurch das Ausmaß des Risikos gemindert wird. Wie von socket.dev berichtet:

• Der Angriffsvektor: Die Malware wird während der npm-Installation über einen Preinstall-Hook automatisch ausgelöst. Sie nutzt eine eigenständige „Bun“-Laufzeitumgebung, um die standardmäßige Sicherheitsüberwachung von Node.js zu umgehen.
• Auswirkungen: Die Payload durchsucht die Umgebung des Opfers nach vertraulichen Zugangsdaten (z. B. AWS-, Azure-, GCP-, GitHub- und Kubernetes-Tokens). Diese Zugangsdaten werden anschließend durch die Erstellung öffentlicher GitHub-Repositorys unter dem Konto des Opfers abgezogen, wodurch sensible Unternehmensdaten im offenen Internet auffindbar werden.
• Verbreitung: Die Malware verhält sich „wie ein Wurm“ und versucht, mit gestohlenen Zugangsdaten andere Repositorys zu infizieren, auf die der Nutzer Zugriff hat.

Auswirkungen auf den Geschäftsbetrieb und Erstmaßnahmen

Da Npms meist von Entwicklern genutzt werden, sind in erster Linie die Arbeitsstationen der Entwickler betroffen; dies kann somit auch Auswirkungen auf Systeme, Repositorys, Anwendungen und cloud haben, auf die der betroffene Entwickler Zugriff hat. Von sekundärer Bedeutung, aber ebenso gravierend ist, dass möglicherweise Komponenten der CI/CD-Pipeline betroffen sind, darunter Artifactory und Build-Tools. Ablauf der Ereignisse:

• Npm-Installation eines betroffenen Pakets, direkt oder indirekt als Abhängigkeit
• Ausführung von Schadcode
• Entwendung / Abzug von Geheimnissen und Zugangsdaten
• Nutzung von Geheimnissen/Zugangsdaten
  • Spread
    • Wiederbesiedlung
    • Neuveröffentlichung
  • Code-Einblendung/Verunstaltung

Im Folgenden werden alle bekannten Erkennungsmethoden ausführlich behandelt; die wichtigsten Ansätze und Anhaltspunkte ergeben sich jedoch aus Endpunktmethoden auf den Arbeitsstationen der Entwickler sowie aus der Überprüfung der Code-Repositorys.

Onapsis – Reaktion und Zusammenarbeit 

Die Lage entwickelt sich derzeit rasant weiter. Wir führen derzeit eine eingehende technische Analyse der Nutzlast und ihrer Übertragungswege durch.

Sofortige Beratung 

Während unsere umfassende Untersuchung noch läuft, empfehlen wir folgende Sofortmaßnahmen:

• Prüfungsabhängigkeiten: Überprüfen Sie Ihre „package-lock.json“-Dateien auf aktuelle Aktualisierungen der schädlichen Versionen von @cap-js-Paketen mit spezifischem Geltungsbereich während des Zeitraums, in dem diese schädlichen Versionen verfügbar waren.
• GitHub-Tokens einschränken: Stellen Sie sicher, dass die persönlichen Zugriffstokens (PATs) der Entwickler auf die unbedingt erforderlichen „Mindestberechtigungen“ beschränkt sind, und vermeiden Sie globale Schreibberechtigungen.
• Öffentliche Repositorys überwachen: Verwenden Sie automatisierte Tools oder manuelle Überprüfungen, um sicherzustellen, dass unter den GitHub-Profilen Ihrer Organisation oder Ihrer Mitarbeiter keine unbefugten öffentlichen Repositorys angelegt wurden.

Ausführlichere technische Hinweise

Die folgenden Leitlinien basieren auf aktuell veröffentlichten forensischen Analysen.

Sofortige Abhängigkeitsprüfung

Um direkt zu prüfen, ob eine Sicherheitslücke vorliegt, sollten Sie die Projektmanifeste auf bekanntermaßen schädliche Paketversionen überprüfen.

• Scan-Lock-Dateien: Suchen Sie in „package-lock.json“, „yarn.lock“ oder „pnpm-lock.yaml“ nach diesen spezifischen Versionen:
  • @cap-js/sqlite: v2.2.2
  • @cap-js/postgres: v2.2.2
  • @cap-js/db-service: v2.10.1
  • mbt (Cloud Build Tool): v1.2.48
    
• Tiefliegende Abhängigkeiten prüfen: Verwenden Sie den Befehl `npm ls @cap-js/sqlite` (oder einen entsprechenden Befehl), um zu überprüfen, ob diese Versionen als Unterabhängigkeit eines anderen Tools mit einbezogen werden.

Überprüfung des Dateisystems und der Umgebung

Falls eine schädliche Version installiert wurde, hat die Malware wahrscheinlich Spuren auf dem Rechner des Entwicklers oder dem CI/CD-Runner hinterlassen.

• Nach Payload-Dateien suchen: Suchen Sie im Verzeichnis „node_modules“ von SAP-Projekten oder in den temporären Verzeichnissen des Systems nach:
  • Setup.mjs
    • SHA-256: 4066781fa830224c8bbcc3aa005a396657f9c8f9016f9a64ad44a9d7f5f45e34
  • execution.js (in der Regel eine große, verschleierte Datei von ca. 11 MB)
    • SHA-256: ([email protected]) 80a3d2877813968ef847ae73b5eeeb70b9435254e74d7f07d8cf4057f0a710ac
  • bun oder bun.exe (Die Malware lädt häufig ihre eigene Bun-Laufzeitumgebung in das Verzeichnis /tmp/ oder das Projektstammverzeichnis herunter).
    • Bun download URL: https://github.com/oven-sh/bun/releases/download/bun-v1.3.13/{asset}.zip
      
• Auf geheime Datenlecks prüfen: Die Malware erstellt vor der Datenexfiltration lokale Dateien. Suchen Sie nach:
  • Cloud.json
  • Environment.json
  • truffleSecrets.json
    
• Hintergrundprozesse identifizieren: Suchen Sie nach lang laufenden Prozessen (die die Bun-Laufzeitumgebung nutzen ), die nicht vom Benutzer gestartet wurden. Unter Linux/macOS: ps aux | grep bun.

Überblick über GitHub- und SaaS-Aktivitäten

Da die Malware die eigenen Zugangsdaten des Opfers nutzt, um Daten abzugreifen, sind die Spuren dafür oft im eigenen GitHub-Konto des Nutzers zu finden.

• Nicht autorisierte öffentliche Repositorien: Nach neuen Einträgen suchen öffentlich Repositorys, die in den letzten 7 Tagen erstellt wurden und folgende Beschreibungen aufweisen:
  • „Ein Mini-Shai-Hulud ist aufgetaucht“
  • „Shai-Hulud-Repository“
  • „Die Wanderung des Shai-Hulud“
    
• Unerwartete Zweige: Suche in privaten oder öffentlichen Repositorys nach neuen Zweigen mit dem Namen „shai-hulud“.
  
• GitHub Actions prüfen:
  • Überprüfe, ob eine neue Workflow-Datei unter .github/workflows/discussion.yaml oder shai-hulud-workflow.yml vorhanden ist.
  • Überprüfen Sie, ob ein selbst gehosteter Runner mit dem Namen „SHA1HULUD“ registriert ist .
    
• Commit-Verlauf: Suche nach Commits mit der Signaturmeldung: OhNoWhatsGoingOnWithGitHub:[Base64_String].

Netzwerk- und Cloud

• Ausgehender Datenverkehr: Achten Sie auf ungewöhnliche ausgehende Verbindungen zu:
  • github.com/oven-sh/bun/releases (zum Herunterladen der Laufzeitumgebung).
  • webhook.site (wird von einigen Varianten zur sekundären Datenexfiltration genutzt).
    
• NutzungCloud : Überprüfen Sie AWS CloudTrail, Azure-Aktivitätsprotokolle oder GCP-Auditprotokolle auf ungewöhnliche Aktivitäten (z. B. Aufrufe von „DescribeInstances“ oder „GetSecretValue“), die von Entwickler-IP-Adressen oder CI/CD-Runner stammen und kurz nach einer npm-Installation aufgetreten sind.

Manuelle Behebung

Wenn einer der oben genannten Anzeichen festgestellt werden, ergreifen Sie sofort folgende Maßnahmen:

1. Maschine isolieren: Trennen Sie den betroffenen Entwickler-Rechner oder CI/CD-Runner vom Netzwerk.
   
2. Caches bereinigen: Führen Sie den Befehl „npm cache clean –force“ aus und löschen Sie die globalen Dateien „node_modules“ und „package-lock.json“.
   
3. Alle Geheimnisse drehen:Das ist von entscheidender Bedeutung. Falls die Malware ausgeführt wurde, ist davon auszugehen, dass folgende Elemente kompromittiert sind:
   • SSH-Schlüssel, die unter ~/.ssh/ gespeichert sind.
   • GitHub-Tokens, einschließlich der Ausgabe von „gh auth token“
   • NPM-Token aus der Datei „.npmrc“
   • Geheime Daten in GitHub Actions
   • GitHub-Zugriffstoken für persönliche Konten (PATs)
   • AWS STS-Identität, Secrets Manager-Geheimnisse und SSM-Parameter
   • Azure-Abonnements, Key Vault-Namen und Key Vault-Geheimniswerte
   • GCP-Projekt-ID und Secret Manager-Werte
   • Kubernetes-Dienstkontotoken
   • Umgebungsvariablen
   • Claude-Konfigurationsdateien, MCP-Konfigurationsdateien, GCP-Token-Datenbanken, Azure-Token-Caches, Signal-Konfigurationsdateien, Electrum-Wallets und VPN-Konfigurationsdateien
     
4. Schädliche Repos löschen: Löschen Sie alle von der Malware erstellten GitHub-Repos oder -Branches manuell, um eine weitere Offenlegung der gestohlenen Geheimnisse zu verhindern.

Die „Mini“-Variante ist besonders gefährlich, da sie bereits während der Vorinstallationsphase ausgeführt wird. Das bedeutet, dass die Anmeldedaten möglicherweise bereits abgezogen wurden, selbst wenn die Installation fehlschlägt oder abgebrochen wird.

Produktangebot von Onapsis

Angesichts des primären Erkennungsvektors sind Onapsis-Produkte nicht optimal dafür geeignet, dies direkt zu erkennen oder darauf zu reagieren. Der primäre Erkennungsvektor liegt auf der Entwickler-Workstation oder auf dem CI/CD-Runner-System. Die Reaktion von Onapsis – sowohl intern als auch extern – bestand darin, in erster Linie auf Standard-Tools für Informationssicherheit und EDR sowie auf Bestandsaufnahmen auf Repository-Ebene zurückzugreifen.

Nächste Schritte 

Onapsis ist bestrebt, Ihnen die genauesten Informationen zur Verfügung zu stellen, sobald diese verfügbar sind. Wir werden diesen Artikel weiterhin aktualisieren, sobald weitere Informationen bekannt werden, einschließlich weiterer Indikatoren für eine Kompromittierung (IoCs) und/oder zusätzlicher Maßnahmen zur Behebung des Problems.

Sollten Sie dringende Fragen zu Ihrer aktuellen SAP-Landschaft haben, wenden Sie sich bitte an Ihren Onapsis-Kundenbetreuer.

Wichtige Artikel als weitere Informationsquelle:

• Socket.dev: SAP-CAP-npm-Pakete im Visier des Shai-Hulud-Angriffs auf die Lieferkette
• Aikido Security: Mini Shai-Hulud zielt auf SAP-npm-Pakete mit einem Bun-basierten Secret Stealer ab
• Wiz Research: Shai-Hulud 2.0: Laufende Analyse von Angriffen auf die Lieferkette
• Step Security: https://www.stepsecurity.io/blog/a-mini-shai-hulud-has-appeared