Es hat wohl einen "Mini Shai-Hulud" genannten Lieferkettenangriff auf diverse npm-Pakete (SAP-CAP), die von SAP in der Entwicklung verwendet werden, gegeben. Wer diese infizierten npm-Pakete während der Entwicklung in SAP-Modulen verwendet, hat sich eine Schadsoftware eingefangen. Diese greift Anmeldedaten ab, um diese an Server der Cyberkriminellen weiter zu leiteten, und versucht die Schadsoftware auf weitere npm-Pakete zu verteilen.
Erste Meldungen zu Mini Shai-Hulud Lieferkettenangriff auf SAP
Mir sind erste Meldungen auf X zum 29. April 2026 am späteren Abend untergekommen. Nachfolgendem Tweet zufolge ist das SAP Cloud Application Programming Model (CAP) betroffen.
Betroffen sind die folgenden npm-Paket-Versionen der SAP-Entwicklungsumgebung, die von Entwicklern in älteren Versionen gepinnt werden sollten.
@cap-js/postgres 2.2.2
@cap-js/sqlite 2.2.2
@cap-js/db-service 2.10.1
mbt 1.2.48
npm habe diese Pakete bereits als "DO NOT USE – unknown content" und als deprecated geflaggt. Das npm-Paket mbt 1.2.48 ist laut diesem Tweet bereits als mit Malware verseucht geflaggt.
Entwickler, die diese Pakete verwenden, sollten die Sperrdateien und CI/CD-Protokolle für Installationen während des Zeitraums, in dem die Sicherheitslücke bestand, überprüfen. In diesem Tweet werden noch einige vorläufige Informationen gegeben.
SAP just experienced a supply chain attack. Likely via. a developer account compromise. Multiple packages under [at]cap-js namespace was published with malicious code injected. The malicious code resembles Shai-Hulud 2 due to its dependency on bun runtime and similar obfuscation and payload.
Likely root cause: The malicious files (setup.mjs, execution.js) do not exist in cap-js/cds-dbs or SAP/cloud-mta-build-tool on GitHub. No release tags for v2.2.2 or v2.10.1 exist.
The legitimate [at]cap-js/sqlite@2.2.1 carries two npm attestations (npm publish + SLSA provenance) which was missing in the malicious versions.
Der Poster gibt den mit Malware verseuchten Commit mit dieser URL an. Im Commit sieht man, dass Claude Code involviert ist. Die Angreifer haben den bösartigen Commit hochgeladen und ihn genutzt, um über die GitHub-OIDC-Authentifizierung ein npm-Token zu erlangen. Mit diesem Token haben sie dann bösartige Versionen veröffentlicht.
In diesem Tweet gibt jemand an, dass ein NPM-Token durch einen falsch konfigurierten CircleCI-Job in PR-Builds offengelegt wurde. Das Ganze dürfte meiner groben Einschätzung nach vor allem die SAP-Entwickler betreffen.
Analyse von Socket Security
Socket Security hat auf X in einer Serie an Tweets sowie in diesem Beitrag eine schnelle Analyse publiziert. Die Analyse von Socket zeigt, dass die betroffenen Versionen ein neues Verhalten bei der Installation einführten, das zuvor nicht Teil der erwarteten Funktionalität dieser Pakete war.
Die kompromittierten Versionen der npm-Pakete enthielten ein Vorinstallationsskript, das als Laufzeit-Bootstrapper fungiert: Es lädt eine plattformspezifische Bun-ZIP-Datei von GitHub Releases herunter, entpackt sie und führt die extrahierte Bun-Binärdatei sofort aus.
Die legitimen npm SAP-CAP-Pakete benötigten zuvor keinen Bun-Installer, um zu funktionieren. Es heißt in der Analyse, dass das plötzliche Hinzufügen eines Preinstall-Skripts zum Herunterladen der Binärdatei einen Ausführungsweg mit erheblichen Auswirkungen während der Paketinstallation geschaffen habe. Die Implementierung folgt zudem HTTP-Weiterleitungen, ohne das Ziel zu validieren, und verwendet PowerShell mit -ExecutionPolicy Bypass unter Windows, was das Risiko für betroffene Entwickler- und CI/CD-Umgebungen erhöht.
Die betroffenen Pakete sind laut Analyse besonders relevant, da sie mit dem Cloud Application Programming Model (CAP) von SAP und den SAP-Cloud-Bereitstellungs-Workflows verbunden sind. Das mbt-Paket ist das über npm vertriebene Cloud MTA Build Tool, das zum Erstellen von bereitstellungsfertigen Multi-Target-Anwendungsarchiven für SAP-Cloud-Anwendungen verwendet wird.
Die @cap-js/*-Pakete sind Datenbankdienstpakete für CAP-Anwendungen, einschließlich SQLite- und PostgreSQL-Integrationen. Gemäß Analyse scheinen die bösartigen npm-SAP-CAP-Pakete mit einem Commit am 29. April 2026, ab 10:03:09 UTC bis 12:20:37 UTC hochgeladen worden zu sein.
Socket Security gibt in der Analyse an, dass jeder Tarball den erwarteten SAP-Quellcode-Baum sowie drei eingeschleuste Dateien enthält:
- eine geänderte `package.json`,
- eine neue `setup.mjs`
- und eine neue `execution.js`
Die forensischen Untersuchungen zeigen laut Socket Security, dass die ursprünglichen SAP-Dateien den Standard-Änderungszeitstempel von npm vom 26. Oktober 1985 tragen, während die drei eingefügten Dateien mit Zeitstempeln zwischen 15:25 und 17:43 UTC am 29. April 2026 versehen sind. Das deutet darauf hin, dass die Tarballs nach dem Abruf aus einer legitimen Quelle nachbearbeitet wurden.
Der Vorgang entwickelt sich
Das Ganze ist ein Vorgang, der sich dynamisch entwickelt – Socket Security hat hier bereits eine vorläufige Analyse vorgelegt. Dort wird der Angriff einer Gruppe zugeschrieben, die mit den TeamPCP-Angriffen in Verbindung steht. Das wird durch Hinweise im Code geschlossen. Die SAP-CAP-Kampagne folge zudem dem operativen Modell, das bereits bei früheren, mit TeamPCP in Verbindung stehenden Aktivitäten zu beobachten war. Dies habe Aqua Security Trivy, LiteLLM, Checkmarx KICS/AST, Telnyx und Bitwarden CLI betroffen. Die Payload sammelte Anmeldedaten für GitHub, npm, Cloud, Kubernetes und CI/CD und nutzte den gestohlenen Zugriff anschließend, um weitere Repositorys und Pakete zu kompromittieren.
Auch die Sicherheitsexperten von Wiz haben hier eine Analyse vorgelegt. Dort heißt es, dass der Payload bei der Ausführung der zweiten Stufe als ein Framework zum Diebstahl von Anmeldedaten und zur Verbreitung entpuppt, das sowohl auf Entwicklerumgebungen als auch auf CI/CD-Pipelines abzielt.
Auch dort heißt es, dass das Framework sensible Daten , darunter GitHub-Token, npm-Anmeldedaten, Cloud-Geheimnisse (AWS, Azure, GCP), Kubernetes-Token und GitHub-Actions-Geheimnisse, sammelt. Der Code bedient sich fortschrittlicher Techniken, wie beispielsweise dem Extrahieren von Geheimnissen aus dem Speicher des Runners. Die Exfiltration erfolgt über öffentliche GitHub-Repositorys, in denen verschlüsselte Payloads hinterlegt werden. Darüber hinaus enthält die Malware eine Verbreitungslogik, um weitere Repositorys und Paketverteilungen zu infizieren.
MVP: 2013 – 2016
Die ganzen Lieferkettenangriffe werden noch so richtig für Probleme sorgen. Bei SAP ist wenigstens auch mal ein großer Name dabei.
Btw hier gibt es auch eine neue Linux Sicherheitslücke: https://copy.fail/
Mit Linux hatte ich heute früh gesehen – komme aber mit den Meldungen nicht mehr nach – es knallt an allen Ecken – die IT-Sicherheit hat fertig.
Nichts ist sicher, auch Linux nicht! So viel zu dem Geschwätz ,das Open-Source sicherer wäre.
Was soll der Kommentar? Hier schwätzt keiner mit Relevanz, dass "Open Source" per se sicherer wäre – aber da habe ich wenigstens die Möglichkeit, in den Quellcode reinzuschauen. Und es gibt die Möglichkeit, solche Projekte zu forken.
Na, dann schauen Sie sich mal hunterttausende Zeilen Code an. Viel Erfolg.