Am 29. April 2026 hat eine unbekannte Angriffsgruppe vier npm-Pakete kompromittiert, die offiziell zum SAP-Ökosystem gehören. Die infizierten Versionen waren zwischen zwei und vier Stunden lang auf npm verfügbar. Wer in diesem Zeitfenster npm install ausgeführt hat, hat Schadsoftware auf seinem System.
Was infiziert wurde
Die betroffenen Pakete sind zentrale Bausteine des SAP Cloud Application Programming Model (CAP) — dem Standardframework für custom Development auf SAP BTP, S/4HANA Side-by-Side Extensions und Fiori-Backends:
mbt@1.2.48(MTA Build Tool)@cap-js/db-service@2.10.1@cap-js/postgres@2.2.2@cap-js/sqlite@2.2.2
Das Besondere: Der eigentliche Paketcode ist sauber. Die normalen Dateien der infizierten Versionen stimmen Byte-für-Byte mit den vorherigen, sauberen Versionen überein. Die Kompromittierung versteckt sich in zwei hinzugefügten Dateien: setup.mjs und execution.js, sowie einem preinstall-Hook in der package.json.
Das bedeutet: Die Malware wird automatisch ausgeführt, wenn jemand npm install ausführt — noch bevor die Installation abgeschlossen ist.
Wer dahintersteckt
Die Malware bezeichnet sich selbst als „Mini Shai-Hulud“ — eine Anspielung auf den sandwüstenbasierenden Wurm aus Dune. Sie ist Teil einer größeren Kampagne, die seit Ende 2025 npm-Pakete unterschiedlicher Anbieter infiziert. Die aktuellen Angriffsmuster gleichen denen der „TeamPCP“-Gruppe, die bereits mehrere supply chain Angriffe auf CI/CD-Infrastrukturen durchgeführt hat.
SAP hat am 30. April die Security Note 3747787 veröffentlicht und saubere Versionen aller vier Pakete nachgeliefert.
Wie die Angreifer an die npm-Token gekommen sind
Der wahrscheinlichste Einstiegspunkt ist ein CircleCI-PR-Build des SAP-Repositories cloud-mta-build-tool. Am 29. April wurde ein kurzlebiges Draft-PR mit dem Titel „feat: ci speedup“ geöffnet — und innerhalb weniger Minuten wieder geschlossen. Der Branch wurde später force-pushed, sodass der GitHub-Diff leer ist.
CircleCI hat aber die Build-Logs behalten. Der PR-Build zeigte, dass während des Build-Prozesses Secrets verfügbar waren — darunter CLOUD_MTA_BOT_NPM_TOKEN, CLOUD_MTA_BOT_GITHUB_TOKEN, OIDC-Tokens, Docker Hub-Zugänge und Cloud Foundry-Credentials. In den Logs tauchen auch Octokit-Warnungen für POST https://api.github.com/user/repos auf. Das entspricht genau dem GitHub-Exfiltrationsverhalten der Malware.
Der Schluss: Jemand hat einen PR gegen das SAP-Repository erstellt, in dem der CircleCI-Build mit den echten Release-Tokens lief. Die Malware im PR-Code hat die Tokens extrahiert und mit dem NPM-Token die infizierten Pakete unter dem offiziellen SAP-Account auf npm veröffentlicht.
Was die Malware macht
Die erste Stage, setup.mjs, lädt die Bun-JavaScript-Runtime (Version 1.3.13) von GitHub herunter und führt damit execution.js aus. Warum Bun? Es umgeht Monitoring-Tools, die auf Node.js-Prozesse überwachen.
execution.js ist ein 11,7 MB großer, verschleierter Credential Stealer und Propagationsframework. Er sammelt:
- GitHub-Tokens (inklusive
gh auth token) - npm-Tokens aus
.npmrc - AWS STS-Identitäten, Secrets Manager, SSM-Parameter
- Azure Key Vault-Zugänge und Secret-Werte
- GCP Secret Manager
- Kubernetes Service Account Tokens
- GitHub Actions Secrets (dafür wird der
Runner.Worker-Prozess im Speicher gelesen und maskierte Secrets extrahiert) - Claude-Config, VPN-Configs, Signal-Config, sogar Electrum-Wallets
Die Daten werden mit AES-256-GCM verschlüsselt, der Schlüssel mit einem eingebetteten RSA-4096-Public-Key verpackt, und über öffentliche GitHub-Repositories exfiltriert — erstellt unter dem Konto des Opfers. Die Repos haben zufällige Dune-bezogene Namen und die Beschreibung: „A Mini Shai-Hulud has Appeared“.
Aktuell sind über 1.100 derartige Repos identifizierbar.
Was das für SAP-Kunden bedeutet
CAP ist das de-facto Framework für fast alles Custom auf SAP BTP. Side-by-Side Extensions, Fiori-Backends, Integration-Flows, MTAs — all das nutzt @cap-js/*-Pakete, häufig mit lockeren Version-Ranges und vielen transitive Dependencies.
Das direkte Risiko besteht, wenn Entwickler oder CI/CD-Pipelines am 29. April zwischen 09:55 und 15:40 UTC eines der vier Pakete mit der infizierten Version installiert haben. Die Folge: Das System ist kompromittiert, die Tokens sind weg, und die Malware hat versucht, sich auf alle Repositories zu verbreiten, auf die der Token Zugriff hatte.
Wie man prüft, ob man betroffen ist
Die betroffenen Versionsnummern sind bekannt. Ein Scan der package-lock.json-Dateien auf die vier konkreten Versionen reicht als erster Check. Zusätzlich sollten GitHub-Konten der Entwickler auf unbefugte öffentliche Repositories überprüft werden.
SAP hat die Security Note 3747787 veröffentlicht. Die sauberen Paketversionen überschreiben die infizierten.
Warum das relevant ist
Dieser Angriff zeigt ein Muster, das über SAP hinausgeht: Supply-Chain-Kompromittierungen über CI/CD-Tokens werden zur Norm. Der Unterschied zu klassischen SAP-Security-Themen wie Berechtigungen oder Patches ist, dass dieses Risiko nicht im SAP-System selbst liegt. Es liegt in der Entwicklungsumgebung, im Build-Prozess, im npm-Token.
Keine SIEM-Korrelationsregel wird einen kompromittierten preinstall-Hook erkennen. Kein SAP-Basis-Admin wird einen npm-Token prüfen. Und niemand hat daran gedacht, dass ein PR-Build mit echten Release-Tokens laufen könnte.
Das ist kein SAP-Problem. Es ist ein Software-Supply-Chain-Problem. Aber weil die infizierten Pakete offiziell zum SAP-Ökosystem gehören, trifft es SAP-Kunden direkt.








