Rotieren, Neu deployen, Widerrufen: Unsere Reaktion auf den Vercel-Vorfall

Am 19. April 2026 offenbarte Vercel einen Sicherheitsvorfall, der auf eine kompromittierte OAuth-Drittanwendung innerhalb von Vercel's Google Workspace zurückzuführen ist. Wir führten die Reaktionsmaßnahmen über alle webvise-verwalteten Vercel-Projekte durch, bevor das Wochenende vorbei war, und die Audit-Logs sowohl von Vercel als auch der von uns administrierten Google Workspaces kamen sauber zurück. Dies war keine Schwachstelle in Vercel's eigenem Code. Es handelte sich um eine SaaS-to-SaaS Supply-Chain-Kompromittierung über eine OAuth-Vertrauensgrenze, und die Art dieses Vorfalls verändert, wie eine angemessene Reaktion aussehen muss.

Das Rotieren von Secrets im Vercel-Dashboard ist vielleicht die Hälfte der Reaktion. Die andere Hälfte liegt in Google Workspace, und die meisten Berichte gehen darauf nicht ein.

Sie haben die Offenlegung gelesen und jeden Key rotiert, den Sie finden konnten. Das ist der richtige erste Schritt. Dieser Artikel beschreibt, was wir tatsächlich von Anfang bis Ende durchgeführt haben, die technische Besonderheit, die dafür sorgt, dass Rotation auch auf laufende Funktionen angewendet werden muss, und warum die Art dieses Vorfalls Ihren Reaktionsplan für das nächste Mal verändern sollte.

• Das Rotieren von Vercel env vars verändert das Dashboard, nicht die laufenden Funktionen. Werte werden erst beim nächsten Deploy wirksam.

• Das Google Workspace OAuth-Audit ist die Hälfte, über die kaum gesprochen wird. Das ist der Vertrauenspfad, den der Angreifer genutzt hat, um Vercel zu erreichen.

• Dies war keine Vercel-Schwachstelle. Es war eine SaaS-to-SaaS-Kompromittierung über einen OAuth-Grant, und eine normale CVE-artige Reaktion schließt die Lücke nicht.

• Langfristig: Secrets aus env vars herausverlagern in einen Runtime-Secret-Manager. Phishing-resistente MFA für alle, die OAuth-Apps installieren können, ist Pflicht.

• Monatliche Audits von OAuth-Grants Dritter in Ihrem Identity Provider sind jetzt Bestandteil der Baseline, keine optionale Reifegrad-Maßnahme.

Was Vercel tatsächlich offengelegt hat

Die Kurzfassung: Eine SaaS-Drittanwendung mit OAuth-Zugriff innerhalb von Vercel's Google Workspace wurde kompromittiert, und der Angreifer nutzte diese Vertrauensgrenze, um auf Environment-Variable-Werte in einer Teilmenge von Kundenprojekten zuzugreifen. Vercel veröffentlichte eine OAuth-Client-ID als Indicator of Compromise und bat alle Kunden, jeden als Environment Variable gespeicherten Secret zu rotieren. Nichts davon betraf eine Schwachstelle in Vercel's eigenem Code. Die Angriffsfläche war der Identity-Trust-Graph zwischen zwei SaaS-Tools.

Das ist entscheidend für die Reaktion. Liegt die Schwachstelle im eigenen Code der Plattform, patchen Sie, rotieren das Geleakte und machen weiter. Liegt die Schwachstelle im Vertrauenspfad zwischen Plattformen, ist Rotation zwar notwendig, schließt aber die Lücke nicht. Sie müssen auch den Grant widerrufen, über den der Angreifer eingedrungen ist, sonst wiederholt die nächste Kompromittierung desselben Tools denselben Schadensradius.

Wenn Sie vor dem nächsten Wochenend-Post-Mortem ein zweites Augenpaar auf Ihr Vercel-Setup möchten, führen wir Security Reviews über Vercel-Teams, Google Workspaces und SaaS-to-SaaS-Grants durch.

Schritt 1: Die Secrets rotieren, die tatsächlich wichtig sind

Wir behandelten jede Environment Variable, die Zugriff auf irgendetwas gewähren könnte, standardmäßig als kompromittiert. Das ist die Annahme, die die Offenlegung erfordert. Hier sind die Secret-Klassen, die wir über alle verwalteten Projekte hinweg neu ausgestellt haben.

• Datenbank-Credentials. Connection Strings, Read-Only-Replica-Passwörter und Admin-Tier-Rollenschlüssel für jedes Projekt mit einem Datenbank-Backend.

• Resend API-Keys für transaktionale E-Mails in jedem Projekt, das Verifikations-, Benachrichtigungs- oder Anmeldenachrichten versendet.

• Google API-Credentials für Workspace-, Calendar-, Drive- und Analytics-Integrationen, die serverseitig laufen.

• AI Gateway-Keys einschließlich Modellzugriffstoken, Provider-Credentials und Rate-Limit-Token für alles, was über das Gateway geroutet wird.

• Ingest-Integrations-Credentials für Webhook-Endpoints, Event-Pipelines und alles, was Daten von außen in das Projekt zieht.

Zwei Kategorien verdienen besondere Aufmerksamkeit: Variablen, die auf `_URL` enden und Credentials in Connection Strings einbetten, sowie alles, was mit `_TEST` oder `_DEV` bezeichnet ist, aber tatsächlich auf Production zeigt. Rotieren Sie diese zusammen mit den anderen. Ein Angreifer, der env vars liest, interessiert sich nicht dafür, welchen Flag Sie gewählt haben oder was der Variablenname vermuten lässt.

Schritt 2: Neu deployen (die technische Besonderheit, die Rotation erst wirksam macht)

Das ist der Teil, der am meisten zählt und am wenigsten Aufmerksamkeit bekommt. Vercel wendet Änderungen an Environment Variables zum Build- und Deploy-Zeitpunkt an, nicht zur Laufzeit. Ein Projekt, das Sie aktualisiert und sich selbst überlassen haben, läuft noch immer auf dem Build, den Sie gestern ausgeliefert haben, der noch den alten Secret in seiner Laufzeit eingebaut hat. Sie haben das Dashboard rotiert, nicht das System.

Konkretes Beispiel: Sie rotieren Ihren Resend API-Key um 10:14 und öffnen einen neuen Tab, um etwas anderes zu prüfen. Eine Funktion versucht um 10:17, eine Verifikations-E-Mail zu senden, ruft Resend mit dem alten, noch in die deployed Umgebung eingebauten Key auf, und Resend lehnt die Anfrage ab. Ihr Nutzer erhält seine E-Mail nicht. Multiplizieren Sie das mit jeder Funktion, jedem Cron und jedem Webhook-Handler, der den alten Build ausführt.

Um Ihre Reaktion zu verifizieren, öffnen Sie den Deployments-Tab bei jedem Projekt und suchen Sie ein Deployment mit einem Zeitstempel nach Ihrer Rotation. Zeigt die oberste Zeile einen Zeitstempel vor Ihrer Rotation, hat die Rotation keinen laufenden Prozess erreicht. Der zweite explizite Schritt in unserer Reaktion war ein erzwungener Production-Redeploy auf jedem verwalteten Projekt nach der Rotation, bevor wir weitermachten.

Schritt 3: Den Google Workspace OAuth-Grant widerrufen

Das ist die Hälfte der Reaktion, über die in den Wochenend-Threads kaum gesprochen wurde. Der Vorfall hat seinen Ursprung in Google Workspace. Der Angreifer gelangte über eine Drittanwendung mit einem gewährten Scope in Workspace hinein und pivotierte dann über einen SaaS-to-SaaS-Vertrauenspfad in Vercel. Wer nur auf der Vercel-Seite rotiert hat, lässt dieselbe OAuth-App noch immer dort mit demselben Scope sitzen, bereit, beim nächsten Mal missbraucht zu werden.

Der Pfad in Ihrer Admin-Konsole: admin.google.com, Sicherheit, API-Steuerung, App-Zugriffskontrolle, Drittanbieter-Apps. Suchen Sie nach der OAuth-Client-ID, die Vercel als Indicator of Compromise veröffentlicht hat. Widerrufen Sie sie, falls sie vorhanden ist. Dann das Schwierigere: Überprüfen Sie jeden anderen OAuth-Grant in der Liste, bestätigen Sie, dass jeder Scope absichtlich vergeben wurde, und widerrufen Sie alles, für das Sie keinen aktiven Grund haben, es zu behalten.

Wir führten dieses Audit auf jeder Workspace durch, die wir administrieren. Der Indicator war nicht vorhanden, und die meisten Grants hatten einen legitimen Geschäftszweck. Einige hatten keinen, und wir widerriefen sie. Seitdem haben wir einen monatlichen Rhythmus eingeführt: Audit der OAuth-Grants am Anfang jedes Monats, Widerruf von allem, das seit 30 Tagen nicht genutzt wurde.

Schritt 4: Die langfristigen Maßnahmen

Rotation und Widerruf haben die unmittelbare Exposition bewältigt. Die längerfristigen Maßnahmen sind das, was verhindert, dass der nächste Vorfall zum Wochenend-Notfallbetrieb wird. Wir setzen diese über die verwalteten Projekte in den kommenden Wochen um, und wir empfehlen sie jedem Team, das einen SaaS-lastigen Stack betreibt.

• Secrets zur Laufzeit aus einem Secret Manager beziehen statt sie in env vars einzubacken. Rotation wird zu einem Push, nicht zu einem Redeploy.

• Kurzlebige Credentials für Datenbanken und APIs, wo immer der Provider sie unterstützt. Gültigkeitsdauer in Minuten, nicht in Monaten.

• Geplante Rotation für Credentials, die nicht kurzlebig gemacht werden können. Kalendergesteuert, nicht vorfallsgesteuert.

• Phishing-resistente MFA auf jedem Admin-Konto, das OAuth-Anwendungen in Ihrem Identity Provider installieren kann. Passkeys oder Hardware-Token, nichts SMS-basiertes.

• Monatliche OAuth-Grant-Audits in Workspace, Microsoft 365 oder welchem Identity Provider Sie auch betreiben. Der Angriffsweg diesmal war ein OAuth-Grant; der Angriffsweg beim nächsten Mal wird es auch sein.

Die meisten Teams haben für keines dieser Themen einen klaren Verantwortlichen. Das ist der stille Grund, warum Vorfälle immer wieder mit denselben Punkten im Post-Mortem enden. Sprechen Sie mit uns darüber, wie webvise diese Maßnahmen in das Wartungsretainer für jedes verwaltete Projekt integriert.

Warum dieser Vorfall anders ist

Das Angriffsmodell, für das die meisten Sicherheitsprogramme ausgelegt sind: Ein Angreifer findet einen CVE in einem Server, den Sie betreiben, nutzt ihn aus und entwendet Ihre Daten. Rotation, Patching und Perimeter-Monitoring decken dieses Modell ab. Der Vorfall vom 19. April hat eine andere Form.

Ein Angreifer kompromittiert ein SaaS-Tool, das Ihr Team autorisiert hat, und nutzt dann die Vertrauensbeziehung zwischen diesem Tool und Ihren anderen SaaS-Tools, um Daten zu erreichen, die keines der Tools einem Fremden direkt gegeben hätte. Ihr Vercel-Konto wurde nicht kompromittiert, und Ihr Google Workspace auch nicht. Ein drittes Tool, das jemand vor Monaten verbunden hatte, wurde kompromittiert, und die Scopes, die Sie diesem Tool gewährt hatten, propagierten die Kompromittierung weiter.

Das Verteidigungsmodell muss zum Angriffsmodell passen. Das bedeutet, OAuth-Grants als Produktionsabhängigkeiten zu behandeln, sie nach Zeitplan zu auditieren und Secrets aus Environment Variables zu verlagern, wo ein Angreifer mit diesem Grant sie lesen kann. Unsere Audit-Logs kamen dieses Wochenende sauber zurück, aber das ist die Auszahlung für diesen spezifischen Vorfall, kein Beweis dafür, dass das Reaktionsmodell zukunftssicher ist.

Wir führen Security Reviews zu Vercel-Teams, Google Workspaces und SaaS-to-SaaS-Identity-Graphs als Teil jedes verwalteten Engagements bei webvise durch. Wenn Sie vor der nächsten Offenlegung an einem Wochenende ein externes Augenpaar auf Ihr Setup möchten, starten Sie ein Gespräch.