So haben wir auf einen npm-Lieferkettenangriff reagiert

Kevin van Zonneveld

Mitgründer · Amsterdam, Niederlande · Bio anzeigen

Am 12. Mai 2026 überprüften wir, inwieweit wir von der laufenden Mini-Shai-Hulud-Lieferkettenkampagne betroffen sein könnten, nachdem öffentliche Berichte kompromittierte Pakete in den npm- und PyPI-Ökosystemen beschrieben hatten. Dazu gehörten TanStack-Pakete und intercom-client.

Wir fanden keine Hinweise darauf, dass die Produktionssysteme, Kundendaten oder veröffentlichten Pakete von Transloadit betroffen waren. Wir nutzten den Vorfall jedoch als Anlass, die Installation von Abhängigkeiten und die Release-Pfade von GitHub Actions in unseren Repositorys abzusichern.

Was passiert ist

Kurz gesagt verlassen sich Angreifer nicht mehr nur auf gestohlene Paketmanager-Token oder Paketnamen mit absichtlichen Tippfehlern. Beim TanStack-Vorfall beschreibt der Post-Mortem-Bericht⁠ eine Angriffskette, die einen pull_request_target-Workflow, die Manipulation des GitHub-Actions-Caches und den Zugriff auf Token für vertrauenswürdige Veröffentlichungen beziehungsweise OIDC kombinierte. Dadurch konnten schädliche Pakete über die offizielle Release-Infrastruktur veröffentlicht werden.

Der Mini-Shai-Hulud-Tracker⁠ von Socket bringt die Kampagne außerdem mit kompromittierten Paketen in Verbindung, darunter intercom-client@7.0.4 auf npm und lightning 2.6.2/2.6.3 auf PyPI. Die gemeldeten Schadprogramme zielen auf Entwicklungs- und CI-Umgebungen ab und suchen nach Zugangsdaten wie GitHub-Token, npm-Token, Cloud-Schlüsseln, SSH-Schlüsseln und Konfigurationen von KI-Tools.

Das ist relevant, weil CI-Systeme häufig eng mit Quellcode, Zugangsdaten für Deployments, Berechtigungen zur Paketveröffentlichung und Cloud-Infrastruktur verbunden sind. Die Installation einer schädlichen Abhängigkeit an der falschen Stelle kann weit mehr als ein lokales Entwicklungsproblem verursachen.

Auswirkungen auf Transloadit

Wir fanden keine Hinweise auf Auswirkungen auf Transloadit-Dienste oder Kundendaten.

Unsere Überprüfung umfasste:

• Die Prüfung von Repositorys, die intercom-client verwenden. Wir fanden diese im Website-Repository, in der API und in weiteren internen Repositorys. Jede dieser Abhängigkeiten war jedoch festgeschrieben und wurde als intercom-client@5.0.0 aufgelöst, nicht als eine der gemeldeten schädlichen Versionen 7.0.4 oder 7.0.5.
• Die Suche nach bekannten verdächtigen Dateien und Indikatoren der Kampagne, darunter router_init.js, router_runtime.js, execution.js, verdächtige shai-hulud-Workflow-Dateien und die gemeldete schädliche Git-Referenz von TanStack.
• Die Suche nach dem gemeldeten Persistenzmechanismus zur Überwachung von GitHub-Token auf den für diese Untersuchung verwendeten Entwicklungsrechnern.
• Die Prüfung unserer GitHub-Actions-Workflows auf das im Post-Mortem-Bericht von TanStack hervorgehobene konkrete Risikomuster: nicht vertrauenswürdiger Pull-Request-Code, der in einen vertrauenswürdigen Cache- oder Release-Workflow gelangt.

Die von uns geprüften betroffenen Paketversionen waren weder in den untersuchten Lockfiles noch in den installierten Kopien vorhanden. Auch die bekannten Persistenz- oder Schadprogrammindikatoren fanden wir nicht in den überprüften Arbeitsverzeichnissen.

Was wir geändert haben

Wir haben in unseren Repositorys mehrere Pull Requests zur Absicherung eröffnet und aktualisiert. Diese Änderungen sind bewusst klein gehalten: Sie verringern das Lieferkettenrisiko, ohne das Produktverhalten zu verändern.

Die wichtigsten Änderungen sind:

• Altersgrenzen für Abhängigkeiten. In Yarn-Repositorys, die noch keine entsprechende Regel hatten, haben wir npmMinimalAgeGate: 2880 hinzugefügt. Dadurch können neu veröffentlichte Paketversionen 48 Stunden lang nicht installiert werden. So erhält das Ökosystem Zeit, viele kompromittierte Releases zu erkennen und zu entfernen, bevor sie in unsere Builds gelangen können.
• Unveränderliche Installationen. Wir haben geeignete CI-Installationen so angepasst, dass sie unveränderliche oder eingefrorene Lockfiles verwenden. Dadurch löst die CI nicht bei Gelegenheit neue Versionen von Abhängigkeiten auf.
• Cache-Grenzen für Releases. Wir haben die Wiederherstellung gemeinsam genutzter Abhängigkeits-Caches aus Release- oder veröffentlichungsfähigen Pfaden entfernt, wenn sie Vertrauensgrenzen überbrücken konnte. Insbesondere haben wir Release- oder CDN-Upload-Pfade in monolib, locutus und uppy aktualisiert.
• CI-Prüfung öffentlicher Repositorys. Wir haben öffentliche Repositorys auf pull_request_target und Workflows mit Zugriff auf Geheimnisse geprüft. Wenn öffentliche Repositorys für die CI Geheimnisse benötigen, bevorzugen wir eine durch die Umgebung geschützte Freigabe, die an den konkret getesteten Code gebunden ist, statt eines ausschließlich auf dem Label „sicher zu testen“ basierenden Ablaufs.
• Verifizierte, ausschließlich ergänzbare Git-Historie. Wir haben organisationsweit GitHub-Regeln aktiviert, die verifizierte Commits voraussetzen und Force-Pushes in Transloadit-Repositorys blockieren. Weitere Untersuchungen bestätigten, dass nicht standardmäßige Branches und veraltete Referenzen zur Angriffsfläche gehören: Kann ein Angreifer einen gemeinsam genutzten Branch mit gefälschten Autorenmetadaten umschreiben, kann die schädliche Historie vertrauter wirken, als sie tatsächlich ist.

Warum das hilft

Keine einzelne Einstellung verhindert alle Lieferkettenangriffe. Das Ziel sind mehrere Schutzebenen:

• Eine Altersgrenze für Pakete verringert das Risiko, dass wir in den ersten Stunden eines Angriffs eine gerade erst kompromittierte Version installieren.
• Unveränderliche Installationen sorgen dafür, dass CI und Deployments das geprüfte Lockfile reproduzieren, statt während der Ausführung neue Versionen zu ermitteln.
• Der Verzicht auf gemeinsam genutzte Caches in Release-Pfaden verringert das Risiko, dass nicht oder weniger vertrauenswürdige Jobs Artefakte hinterlassen, die ein späterer vertrauenswürdiger Veröffentlichungs-Job wiederherstellt.
• Explizite GitHub-Actions-Berechtigungen und Umgebungsfreigaben verhindern, dass Jobs mit Zugriff auf Geheimnisse für ungeprüften Code aus Forks ausgeführt werden.
• Verifizierte Commits erschweren Identitätsfälschungen. Das Blockieren von Aktualisierungen ohne Fast-Forward erhält zudem die überprüfbare Historie gemeinsam genutzter Branches.

Der TanStack-Vorfall hat erneut gezeigt, dass Build-Caches und Release-Jobs Teil der Sicherheitsgrenze sind. Wir behandeln sie nun konsequenter als solche.

Was Sie als Kunde tun sollten

Aufgrund dieser Überprüfung sind keine Transloadit-spezifischen Maßnahmen Ihrerseits erforderlich.

Wenn Sie am oder nach dem 29. April 2026 Pakete installiert haben, die öffentlich als von Mini Shai-Hulud betroffen aufgeführt wurden, empfehlen wir Ihnen, die Hinweise der jeweiligen Paketverantwortlichen zu befolgen. Im Allgemeinen bedeutet das, Lockfiles und CI-Protokolle zu prüfen, betroffene Versionen zu entfernen und alle Zugangsdaten auszutauschen, auf die aus Umgebungen zugegriffen werden konnte, in denen die schädlichen Pakete möglicherweise ausgeführt wurden.

Für Ihre eigenen CI-Systeme empfehlen wir dieselben Kontrollen, die auch wir anwenden:

• Verwenden Sie in CI- und Deployment-Workflows ausschließlich Lockfile-basierte Installationen.
• Fügen Sie Altersgrenzen für Abhängigkeits-Releases hinzu, sofern Ihr Paketmanager diese unterstützt.
• Vermeiden Sie Abhängigkeits-Caches in Veröffentlichungs- oder Deployment-Workflows.
• Gehen Sie mit pull_request_target besonders vorsichtig um. Kombinieren Sie es nicht mit dem Auschecken von nicht vertrauenswürdigem Pull-Request-Code und dem Zugriff auf Geheimnisse oder Token mit Schreibberechtigung.
• Halten Sie die GitHub-Actions-Berechtigungen so gering wie möglich und erweitern Sie sie nur in dem Job, der die jeweilige Berechtigung benötigt.
• Deaktivieren Sie nach Möglichkeit Force-Pushes für gemeinsam genutzte Repository-Branches. Wenn Entwickler die Historie überarbeiten müssen, sollten sie neue Branches erstellen, statt Branches umzuschreiben, die andere Personen oder Automatisierungen möglicherweise abrufen.

Abschluss

Wir danken den Paketverantwortlichen und Forschenden, die schnell technische Details und Indikatoren veröffentlicht haben. Dadurch konnten Teams wie unseres mögliche Auswirkungen rasch prüfen und die Erkenntnisse in konkrete Absicherungsmaßnahmen umsetzen.

Wir werden die Kampagne weiterhin beobachten und diesen Beitrag aktualisieren, falls wir wesentliche Auswirkungen auf Transloadit oder erforderliche Maßnahmen für Kunden feststellen.