Die Angriffskette begann an der Stelle, an der Zapier seinen Nutzern eigentlich entgegenkommt: Wie andere Automatisierungsanbieter erlaubt Zapier, eigenen Code in einem Codeblock auszuführen oder ihn von einem KI-Agenten schreiben zu lassen. Über die Funktion „Code by Zapier" können Kunden etwa Skripte und Code zur Datenverarbeitung in Python und JavaScript ausführen. „Es wird als Ort beworben, an dem Nutzer ihre eigene Logik ausführen. Also haben wir unsere eigene Logik ausgeführt", schreibt Balilti in seiner Analyse.

Mit eigenem Code fragten die Forscher das Betriebssystem der Sandbox ab und stellten fest, dass diese auf AWS Lambda lief. Zwar fanden sie keine offen sichtbaren Zugangsdaten, doch das Auslesen einer Aufgabendatei offenbarte eine zu weit gefasste Rolle – irreführend benannt als „allow_nothing_role" – sowie das Versäumnis, Zugangsdaten sicher zu löschen.

Im zweiten Schritt schrieben die Forscher ein Python-Skript, um Geheimnisse aus dem Speicher zu extrahieren. Begünstigt wurde dies dadurch, dass AWS Lambda Tokens und andere Geheimnisse nicht aktiv löscht, bevor der Container neu aufgesetzt wird. Mithilfe der Rolle konnten sie im dritten Schritt 1.111 Dateien aus Zapiers privatem Repository auflisten und anfordern. Eine davon legte ein NPM-Token zum Veröffentlichen offen, das sich für jedes Paket nutzen ließ.

Die letzten beiden Schritte beschrieben die Forscher, führten sie aber nicht aus: Ein Post-Install-Skript hätte das Ausführen beliebigen Codes ermöglicht, indem es einem legitimen Zapier-Paket hinzugefügt worden wäre; die fünfte Stufe hätte die Verteilung des Codes an den Browser jedes angemeldeten Zapier-Nutzers erlaubt.

„Ein Angreifer hätte als der Nutzer innerhalb von Zapier handeln können: Zaps anlegen, Tabellen erstellen, MCP-Server einrichten, bestehende Automatisierungen ändern und die vorhandenen Verbindungen des Nutzers zu Drittdiensten über Zapiers Plattform nutzen", schreibt Balilti. Diese Verbindungen würden serverseitig ausgeführt; der Angreifer könne sie steuern, indem er die Sitzung des Nutzers übernimmt.

Token Security meldete die Schwachstelle im Februar im Rahmen der verantwortungsvollen Offenlegung; Zapier behob sie in weniger als einer Woche. Token Security bestätigte später, dass die Korrektur funktioniert, und kündigte an, die Forschung am 1. Juni auf der fwd:cloudsec North America vorzustellen.

Balilti rät Unternehmen, ihre Automatisierungsplattformen und die zugänglichen Daten stärker zu beachten und Rollen so weit wie möglich einzuschränken. Verbindungen zu Diensten wie Salesforce, Gmail und Google Drive sollten mit dem geringstmöglichen Berechtigungsumfang eingerichtet werden, damit ein kompromittierter Nutzer nur lesenden oder auf bestimmte Ressourcen begrenzten Zugriff biete.

Das Berechtigungsproblem ist weit verbreitet: Laut den Forschern verfügen 56 Prozent der Unternehmen über keinen Prozess, um SaaS-zu-SaaS-Verbindungen und -Integrationen nachzuverfolgen. Höchstwahrscheinlich, so Balilti, testen Angreifer bereits die SaaS-Umgebungen von Unternehmen. Viele Automatisierungsplattformen verfügten über eine ähnliche Codeblock-Funktion – „und vielleicht werden manche Angreifer denselben Ansatz versuchen".