Zapocalypse: Die Supply-Chain-Attacke aus fünf bekannten Fehlern

Im Mai 2026 enthüllten Forscher von Token Security eine fünfstufige Exploit-Kette mit dem Namen „Zapocalypse“. Sie demonstrierte, wie sich eine Reihe bekannter Anti-Patterns – also bewährter, aber riskanter Abkürzungen – zu einer fatalen Supply-Chain-Lücke zusammensetzen ließ. Ausgehend von einem kostenlosen Zapier-Konto erlangten die Forscher Schreibzugriff auf die öffentlichen Entwickler-SDK-Pakete sowie interne Pakete von Zapier. Jedes einzelne Glied in der Kette war für sich genommen ein Sicherheitsproblem, das ein einzelnes Team vermutlich als akzeptabel eingestuft hätte. Die Schwachstelle lag nicht in einem einzelnen System, sondern in der Komposition über fünf verschiedene Teams hinweg, die nie gemeinsam einen Angriffspfad betrachten mussten .

Stufe 1: Sandbox-Ausbruch durch Speicher-Scavenging

Die Kette begann in Zapiens Code by Zapier-Feature, das von Nutzern bereitgestellten Python- und JavaScript-Code in AWS-Lambda-Containern ausführt. Zapiens Lambda-Handler versuchte, AWS-Zugangsdaten aus den Umgebungsvariablen zu entfernen, indem er sie in Python mit

del os.environ[k]

Die Forscher nutzten dies aus, indem sie /proc/self/mem lasen und vier Regex-Muster gegen lesbare Speicherbereiche anwendeten. So konnten sie erfolgreich gültige AWS-STS-Sitzungstoken für die IAM-Rolle der Lambda-Funktion wiederherstellen und die Sandbox vollständig umgehen .

Stufe 2: ECR-Enumeration mit minimalen Berechtigungen

Die wiederhergestellte AWS-Rolle trug den trügerischen Namen allow_nothing_role (Rolle, die nichts erlaubt). Tatsächlich gewährte sie jedoch vier Elastic-Container-Registry-Berechtigungen: ecr:DescribeRepositories, ecr:ListImages, ecr:BatchGetImage und ecr:GetDownloadUrlForLayer .

Diese vier Berechtigungen reichten aus, um Container-Images direkt über die AWS-API abzurufen – ganz ohne Docker-Registry-Authentifizierungstoken. Die Forscher zählten 1.111 Produktions-Repositories auf und zogen Container-Images über die Layer-Fetch-APIs .

Stufe 3: NPM-Token aus der Container-Image-Historie

In einem der abgerufenen Container-Images entdeckten die Forscher ein NPM-Publish-Token, das in die Konfigurationshistorie des Images gelangt war. Der Token war über eine Dockerfile-ARG-Anweisung in den Build-Prozess eingeflossen. Diese Anweisungen werden dauerhaft im unveränderlichen history[]-Feld des Images serialisiert. Das bedeutet: Jeder, der das Image abrufen konnte, konnte auch den Token wiederherstellen .

Stufe 4: NPM-Publish-Zugriff mit umgangener 2FA

Der wiederhergestellte NPM-Token besaß drei kritische Eigenschaften:

action: write

name: null

bypass_2fa: true

Die Einstellung

bypass_2fa: true

Stufe 5: Potenzieller Supply-Chain-Brückenkopf und Codeausführung im Browser

Das kritischste Paket in der Kette war zapier-design-system, das bei jeder authentifizierten Sitzung auf zapier.com geladen wird. Die Forscher überprüften diesen Ladepfad in den Browser-Entwicklertools und stoppten an diesem Punkt – sie veröffentlichten kein bösartiges Paket .

Hätte ein Angreifer eine manipulierte Version veröffentlicht, wäre bei der nächsten Aktualisierung von zapier.com JavaScript-Code unter der Kontrolle des Angreifers im authentifizierten Browser-Kontext ausgeführt worden. Von dort aus hätte der Angreifer Zaps, Tabellen und MCP-Server erstellen sowie bestehende Integrationen im Namen authentifizierter Nutzer ansteuern können. OAuth-Token und API-Schlüssel für verbundene Dienste verbleiben serverseitig und wären dem Browser nicht direkt zugänglich gewesen – die operativen Auswirkungen wären dennoch schwerwiegend gewesen .

Zapiens Reaktionszeit

Token Security reichte den Bericht am 12. Februar 2026 ein. Innerhalb von vier Tagen hatte Zapier den Bericht bewertet, den offengelegten NPM-Token widerrufen und die zugrundeliegende AWS-Rolle verschärft. Die vollständige Behebung wurde am 5. März 2026 bestätigt. Zapier meldete keine Hinweise auf eine aktive Ausnutzung .

Die Forscher erhielten die maximale Prämie des Bug-Bounty-Programms in Höhe von 3.000 US-Dollar, und Zapier verpflichtete sich, die Prämienobergrenze bei der nächsten Programmüberprüfung zu evaluieren .

Es ist wichtig zu erwähnen, dass diese Sicherheitsforschung von einer realen Supply-Chain-Attacke auf Zapiens NPM-Konto zu unterscheiden ist, die am 24. November 2025 stattfand, als der Wurm Shai Hulud 2.0 das Konto kompromittierte und 425 Pakete infizierte .

Die größere Lektion: Komponierte Schwachstellen fallen zwischen die Teams

Yair Balilti, Leiter des Security-Research-Teams bei Token Security, brachte die Kernaussage auf den Punkt:

„Jedes Glied in der Kette war ein bekanntes Muster. Die Schwachstelle war die Komposition, und die Komposition ist genau das, was zwischen die Teams fällt. Die Lambda-Sandbox, ECR und IAM, der GitLab-CI-Token, die NPM-Veröffentlichung, der Browser – jedes System gehört einer anderen Gruppe, und jede konnte ihren Teil betrachten und vernünftigerweise als in Ordnung einstufen. Das Risiko wird erst sichtbar, wenn man einen Pfad über alle hinweg verfolgt.“

Die Quintessenz lautet: Kein einzelnes Team war für eine einzelne Schwachstelle verantwortlich. Das Lambda-Sandbox-Team sah kein Problem mit dem Speicher-Scavenging, weil das Token ohnehin außerhalb des Geltungsbereichs hätte sein müssen. Das IAM-Team sah eine Rolle, die auf Leseaktionen in ECR beschränkt war. Das CI/Build-Team übergab den NPM-Token als Build-ARG. Das NPM-Team verwaltete einen Token mit Schreibzugriff. Das Browser-Team lud ein Design-System-Paket. Jede Entscheidung war für sich genommen nachvollziehbar, aber die Verkettung über alle fünf Systeme hinweg war katastrophal .

Das zeigt: Identity- und Access-Reviews müssen Angriffspfade über Systemgrenzen hinweg verfolgen, anstatt die Berechtigungen jeder Komponente isoliert zu prüfen. Unternehmen brauchen teamübergreifende Sicherheitsüberprüfungen, die untersuchen, wie sich scheinbar harmlose Konfigurationen zu gefährlichen Angriffsketten zusammensetzen, wenn Systeme interagieren .