Anfang 2026 hat eine Gruppe namens TeamPCP bösartige Versionen von TanStack-Paketen veröffentlicht, und weil TanStack in unzähligen JavaScript Projekten als Abhängigkeit steckt, hat sich die Malware innert Stunden über Hunderte von Organisationen verbreitet. OpenAI hatte zwei kompromittierte Entwicklergeräte (sie sagen „eine begrenzte Anzahl interner Repositories“ sei betroffen gewesen, keine Kundendaten), bei Grafana wurde die gesamte GitHub Umgebung kompromittiert und der Quellcode gestohlen, gefolgt von einem Erpressungsversuch. Der TanStack-Vorfall war allerdings nur einer von drei grossen Supply Chain Angriffen in der ersten Jahreshälfte 2026, die alle nach dem gleichen Grundprinzip funktionierten.
Im Mai hat die „Megalodon“ Kampagne über 5500 GitHub Repositories infiziert, indem sie bösartige Commits als legitime automatisierte Beiträge getarnt hat, und ebenfalls Anfang 2026 wurde die populäre Nx Console Extension für VS Code mit einem Trojaner versehen der Entwicklern ihre Credentials gestohlen hat. Was alle drei Angriffe verbindet, ist dass sie nicht auf Server oder Endgeräte zielen, sondern auf Entwickler und deren Werkzeuge.
Warum Entwickler
Entwickler sind aus Angreifersicht besonders attraktive Ziele, weil sie typischerweise Zugang zu allem haben was wertvoll ist: Source Code Repositories, CI/CD Pipelines, Cloud Konsolen, Produktionsumgebungen. Ein kompromittierter Entwickler-Laptop liefert im besten Fall SSH Keys, API Tokens, Cloud Credentials, Kubernetes Konfigurationen und Zugang zu internen Systemen, und das alles auf einem einzigen Gerät. Dazu kommt dass Entwickler ständig fremden Code installieren (npm install, pip install, VS Code Extensions) und dabei selten hinterfragen ob das Paket wirklich vertrauenswürdig ist, weil es ja von einem bekannten Anbieter kommt und in der offiziellen Registry steht.
Der TanStack Angriff hat genau diese Vertrauenskette ausgenutzt. TeamPCP hat die offizielen TanStack Pakete kompromittiert (nicht Fakes mit ähnlichen Namen, sondern die echten Pakete), und jeder Entwickler der ein Update gemacht hat, hat sich die Malware automatisch eingefangen. Die Malware hat dann GitHub Credentials, Cloud Secrets, SSH Keys und CI/CD Tokens vom Entwicklergerät abgezogen und an die Angreifer geschickt. Von dort aus konnten sie in die Repositories und Build Pipelines der betroffenen Organisationen eindringen; ein klassischer Kaskadeneffekt bei dem ein einziger kompromittierter Baustein Dutzende oder Hunderte von nachgelagerten Opfern produziert.
Dass die gleiche Gruppe auch Trellix gehackt hat, einen Anbieter von Sicherheitssoftware, unterstreicht wie schwer diese Art von Angriffen selbst für Unternehmen zu erkennen ist, die sich professionell mit IT-Sicherheit beschäftigen…
Megalodon
Die Megalodon Kampagne im Mai 2026 hat einen anderen Ansatz gewählt, aber mit dem gleichen Ziel. Statt Pakete zu kompromittieren haben die Angreifer bösartige Commits in bestehende GitHub Repositories eingeschleust, getarnt als automatisierte Beiträge (z.B von Bots die Abhängigkeiten updaten oder Code formatieren). In wenigen Stunden waren über 5500 Repositories betroffen, und die gestohlenen Daten umfassten Cloud Credentials, SSH Keys, Kubernetes Konfigurationen und CI/CD Secrets.
Die Wirksamkeit dieses Ansatzes beruht darauf, dass die Commits wie normale Wartungsarbeit aussahen und viele Maintainer sie durchgewunken haben, ohne den Code im Detail zu prüfen. Die Angreifer haben damit den gesamten Software-Lieferzyklus ins Visier genommen, von Source Code Repositories über Automation Workflows bis zu Build Pipelines.
VS Code als Einfallstor
Der dritte Angriffsvektor betrifft eine trojanisierte VS Code Extension namens Nx Console, ein beliebtes Entwicklertool für Angular und React Projekte. Wer es installiert hat, hat den Angreifern unbemerkt Zugang zu seinem GitHub Account, seinen CI/CD Workflows, Cloud Umgebungen und ev. sogar Produktionssystemen gegeben.
VS Code Extensions laufen mit den gleichen Berechtigungen wie VS Code selbst, was bedeutet dass sie auf praktisch alles zugreifen können was der Entwickler auf seinem Rechner hat. Es gibt zwar einen Marketplace Review Prozess, aber der ist bei weitem nicht so streng wie z.B. bei mobilen App Stores, und bei Updates einer bestehenden Extension wird oft nicht mehr genau hingeschaut.
Angriffskette
Der typische Ablauf eines Supply Chain Angriffs folgt einem wiederkehrenden Muster:
1. Kompromittierung der Quelle: Der Angreifer übernimmt ein npm Paket, eine VS Code Extension oder ein GitHub Repository (über gestohlene Maintainer Credentials, Social Engineering oder eine Schwachstelle in der Plattform).
Was hätte geholfen: Paket-Signierung, Dependency Pinning mit Hash Verifikation, Zwei-Faktor-Authentifizierung für alle Maintainer Accounts.
2. Der Entwickler installiert das Update: Das kompromittierte Paket wird über den normalen Update Prozess verteilt (npm update, Extension Update etc).
Was hätte geholfen: Automatisiertes Dependency Scanning (Dependabot, Snyk), Lockfile Verifikation, Review von Dependency Updates bevor sie in die Pipeline gehen.
3. Schadcode wird ausgeführt: Die Malware läuft im Kontext der Entwicklungsumgebung und hat Zugriff auf alles was der Entwickler hat.
Was hätte geholfen: Sandboxed Build Umgebungen, Least Privilege für Entwicklertools (nicht jedes Tool braucht Zugang zu Produktion).
4. Credentials werden abgezogen: GitHub Tokens, SSH Keys, Cloud Credentials, API Schlüssel werden an den Angreifer geschickt.
Was hätte geholfen: Secrets Management (HashiCorp Vault etc), keine langlebigen Credentials auf Entwicklergeräten, kurzlebige Tokens mit automatischer Rotation.
5. Zugriff auf CI/CD: Mit den gestohlenen Credentials hat der Angreifer Zugang zu Build Pipelines und Deployment Systemen.
Was hätte geholfen: OIDC Tokens statt statischer Credentials, Pipeline Hardening, getrennte Credentials für verschiedene Umgebungen.
6. Ausbreitung: Der Angreifer bewegt sich lateral in Richtung Produktion, andere Repositories und Kundensysteme.
Was hätte geholfen: Netzwerksegmentierung, Zero Trust Architektur, separate Produktions Credentials die nicht auf Entwicklergeräten liegen.
7. Datendiebstahl oder weitere Kompromittierung: Source Code wird gestohlen, Kundendaten abgezogen, oder die kompromittierten Pakete werden genutzt um den Angriff weiter zu verbreiten.
Was hätte geholfen: DLP, Code Signing, Audit Logging, Incident Response Plan.
Empfehlungen
Für Schweizer Software Unternehmen (und eigentlich für alle die Software entwickeln) gibt es eine Reihe konkreter Massnahmen die das Risiko von Supply Chain Angriffen erheblich reduzieren:
Erstens sollte Dependency Management als sicherheitsrelevanter Prozess behandelt werden. Das bedeutet Lockfiles verwenden, Hashes verifizieren und automatisierte Tools wie Dependabot oder Snyk einsetzen die bei verdächtigen Änderungen in Abhängigkeiten Alarm schlagen, statt Dependency Updates ungeprüft durchlaufen zu lassen.
Zweitens sollten keine langlebigen Secrets auf Entwicklergeräten liegen. SSH Keys, API Tokens und Cloud Credentials sollten kurzlebig sein und automatisch rotiert werden, damit bei einer Kompromittierung eines Entwicklergeräts die Credentials innert Stunden ablaufen und nicht monatelang gültig bleiben.
Drittens sollten Build Umgebungen von Entwicklergeräten isoliert sein. CI/CD Pipelines sollten nicht mit den gleichen Credentials laufen die auch auf Entwicklergeräten liegen, und der Zugang zu Produktion sollte über separate, kontrollierte Kanäle erfolgen die nicht direkt vom Arbeitsgerät des Entwicklers abhängen.
Viertens sollten VS Code Extensions und andere Entwicklertools nicht pauschal als vertrauenswürdig behandelt werden, nur weil sie im offiziellen Marketplace stehen. Bei Updates lohnt sich ein Blick auf die Änderungen bevor man sie akzeptiert..
Wer sich fragt ob das eigene Unternehmen gegen Supply Chain Angriffe gewappnet ist: sprechen Sie mit uns über ein Security Assessment Ihrer Entwicklungsumgebung.
Quellen: