Rotieren, Neu deployen, Widerrufen: Die webvise-Antwort auf den Vercel-Breach

Am 19. April 2026 legte Vercel einen Sicherheitsvorfall offen, der auf eine kompromittierte OAuth-Drittanbieteranwendung innerhalb von Vercels Google Workspace zurückzuführen war. Die Response wurde noch am selben Wochenende über alle von webvise verwalteten Vercel-Projekte durchgeführt; Audit-Logs auf Vercel sowie in den administrierten Google Workspaces kamen sauber zurück. Dabei handelte es sich nicht um eine Schwachstelle in Vercels eigenem Code. Es war ein Supply-Chain-Kompromiss über einen SaaS-zu-SaaS-Vertrauenspfad durch eine OAuth-Vertrauensgrenze, und diese Angriffsform verändert, wie eine angemessene Response aussehen muss.

Secrets im Vercel-Dashboard zu rotieren deckt vielleicht die Hälfte der Response ab. Die andere Hälfte liegt in Google Workspace, und die meisten Berichte gehen darauf kaum ein.

Sie haben die Offenlegung gelesen und jeden auffindbaren Key rotiert. Das ist der richtige erste Schritt. Dieser Artikel beschreibt, was tatsächlich von Anfang bis Ende durchgeführt wurde, den technischen Fallstrick, der Rotation auch auf laufende Functions anwendbar macht, und warum die Angriffsform dieses Breaches den nächsten Response-Plan verändern sollte.

• Die Rotation von Vercel-Umgebungsvariablen aktualisiert die Konfiguration, nicht die laufenden Function-Instanzen; ein Redeploy ist nötig, damit die Änderungen wirksam werden. Neue Werte greifen erst beim nächsten Deploy.
• Der Google Workspace OAuth-Audit ist die Hälfte, über die kaum gesprochen wird. Das ist der Vertrauenspfad, den der Angreifer genutzt hat, um in Vercel einzudringen.
• Das war keine Vercel-Schwachstelle. Es war ein SaaS-zu-SaaS-Kompromiss über einen OAuth-Grant, und eine normale CVE-Response schließt die Lücke nicht vollständig.
• Langfristig sollten Secrets aus Umgebungsvariablen heraus in einen Runtime-Secret-Manager verlagert werden. Phishing-resistente MFA ist Pflicht für alle, die OAuth-Apps installieren dürfen.
• Monatliche OAuth-Grant-Audits im Identity Provider gehören ab sofort zur Baseline, nicht zu einem optionalen Reifegrad-Upgrade.

Was Vercel tatsächlich offengelegt hat

Kurzfassung: Eine OAuth-Drittanbieteranwendung mit Zugriff auf Vercels Google Workspace wurde kompromittiert. Der Angreifer nutzte diese Vertrauensgrenze, um über einen SaaS-zu-SaaS-Vertrauenspfad auf die Werte von Umgebungsvariablen in einer Teilmenge von Kundenprojekten zuzugreifen. Vercel veröffentlichte eine OAuth-Client-ID als Indicator of Compromise und forderte alle Kunden auf, jeden als Umgebungsvariable gespeicherten Secret zu rotieren. Vercels eigener Code war nicht betroffen. Die Angriffsfläche war der Identitäts-Vertrauensgraph zwischen zwei SaaS-Tools.

Das ist entscheidend für die Response. Bei einer Schwachstelle in der eigenen Plattform patcht man, rotiert das Geleakte und geht weiter. Bei einer Schwachstelle im Vertrauenspfad zwischen Plattformen ist Rotation notwendig, schließt das Loch aber nicht. Zusätzlich muss der Grant widerrufen werden, über den der Angreifer hereingekommen ist, sonst wiederholt eine erneute Kompromittierung desselben Tools denselben Schadensradius.

Für eine zweite Überprüfung Ihres Vercel-Setups vor dem nächsten Vorfall: webvise führt Sicherheitsreviews für Vercel-Teams, Google Workspaces und SaaS-zu-SaaS-Grants durch.

Schritt 1: Die Secrets rotieren, die wirklich zählen

Jede Umgebungsvariable, die Zugang zu irgendetwas gewähren kann, wurde standardmäßig als kompromittiert behandelt. Das ist die Annahme, die die Offenlegung vorschreibt. Folgende Secret-Klassen wurden in den verwalteten Projekten neu ausgestellt.

• Datenbank-Credentials. Connection Strings, Read-Only-Replica-Passwörter und Admin-Rollen-Keys in jedem Projekt mit Datenbank-Backend.
• Resend-API-Keys für transaktionale E-Mails in jedem Projekt, das Verifizierungs-, Benachrichtigungs- oder Registrierungsnachrichten versendet.
• Google-API-Credentials für Workspace-, Calendar-, Drive- und Analytics-Integrationen, die serverseitig laufen.
• AI-Gateway-Keys einschließlich Model-Access-Tokens, Provider-Credentials und Rate-Limit-Tokens für alles, was über das Gateway geleitet 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 mit der Endung `_URL`, die Credentials in Connection Strings einbetten, sowie alles mit `_TEST` oder `_DEV` im Namen, das sich als produktionsseitig herausstellt. Diese werden zusammen mit dem Rest rotiert. Ein Angreifer, der Umgebungsvariablen liest, interessiert sich weder für gewählte Flags noch für das, was der Variablenname verspricht.

Schritt 2: Neu deployen (der technische Fallstrick, der Rotation erst wirksam macht)

Diesen Schritt behandeln die meisten Response-Checklisten zu oberflächlich. Vercel übernimmt Änderungen an Umgebungsvariablen zum Zeitpunkt von Build und Deploy, nicht zur Laufzeit. Ein Projekt, das aktualisiert aber nicht neu deployt wurde, läuft noch immer den gestrigen Build, in dem der alte Secret in die Laufzeitumgebung eingebacken ist. Das Dashboard wurde rotiert, das System nicht.

Konkretes Beispiel: Der Resend-API-Key wird um 10:14 Uhr rotiert, dann wird ein neuer Tab geöffnet. Um 10:17 Uhr versucht eine Function, eine Verifizierungs-E-Mail zu senden, ruft Resend mit dem alten, noch im deployt Env eingebackenen Key auf, und Resend lehnt die Anfrage ab. Der Nutzer erhält seine E-Mail nicht. Multipliziert mit jeder Function, jedem Cron-Job und jedem Webhook-Handler, der noch den alten Build ausführt.

Zur Überprüfung der Response: Den Deployments-Tab jedes Projekts öffnen und ein Deployment suchen, das nach der Rotation zeitgestempelt ist. Zeigt die oberste Zeile einen Zeitstempel vor der Rotation, hat diese keinen laufenden Prozess erreicht. Der zweite explizite Schritt in der Response war daher ein erzwungenes Production-Redeploy aller verwalteten Projekte nach der Rotation, bevor weitergemacht wurde.

Schritt 3: Den Google Workspace OAuth-Grant widerrufen

Das ist die Hälfte der Response, die in den Wochenend-Diskussionen kaum thematisiert wurde. Der Vorfall begann in Google Workspace. Der Angreifer gelangte über eine OAuth-Drittanbieteranwendung mit einem gewährten Scope in Workspace hinein und pivotierte von dort über einen SaaS-zu-SaaS-Vertrauenspfad in Vercel. Wer nur auf der Vercel-Seite rotiert hat, lässt dieselbe OAuth-App mit demselben Scope stehen, bereit für den nächsten Missbrauch, sobald sie erneut kompromittiert wird.

Der Pfad in der Admin-Konsole: admin.google.com, Sicherheit, API-Steuerung, App-Zugriffssteuerung, Drittanbieter-Apps. Nach der OAuth-Client-ID suchen, die Vercel als Indicator of Compromise veröffentlicht hat. Wenn vorhanden, widerrufen. Dann der schwierigere Teil: Jeden weiteren OAuth-Grant in der Liste prüfen, bestätigen, dass jeder Scope bewusst erteilt wurde, und alles widerrufen, für das kein aktiver Verwendungszweck besteht.

Dieser Audit wurde in jedem administrierten Workspace durchgeführt. Der Indicator of Compromise war nicht vorhanden, und die meisten Grants hatten einen legitimen Geschäftszweck. Einige wenige nicht, und diese wurden widerrufen. Seither gilt ein monatlicher Rhythmus: OAuth-Grant-Audit zu Beginn jeden Monats, Widerruf von allem, das 30 Tage lang ungenutzt geblieben ist.

Schritt 4: Die langfristigen Maßnahmen

Rotation und Widerruf haben die unmittelbare Exposition beseitigt. Die langfristigen Maßnahmen sind das, was verhindert, dass der nächste Vorfall zu einem Wochenend-Chaos wird. Diese werden über die kommenden Wochen in die verwalteten Projekte eingespielt und sind die Empfehlung für jedes Team, das einen SaaS-lastigen Stack betreibt.

• Secrets zur Laufzeit aus einem Secret Manager beziehen statt sie in Umgebungsvariablen einzubacken. Rotation wird zum Push-Vorgang, nicht zum Redeploy.
• Kurzlebige Credentials für Datenbanken und APIs, wo immer der Anbieter dies unterstützt. Gültigkeit in Minuten, nicht in Monaten.
• Geplante Rotation für Credentials, die nicht kurzlebig gemacht werden können. Kalendergesteuert, nicht vorfallsgetrieben.
• Phishing-resistente MFA auf jedem Admin-Account, der OAuth-Anwendungen im Identity Provider installieren darf. Passkeys oder Hardware-Token, kein SMS-basiertes Verfahren.
• Monatliche OAuth-Grant-Audits in Workspace, Microsoft 365 oder dem jeweiligen Identity Provider. Der Angriffsweg dieses Vorfalls war ein OAuth-Grant; der nächste wird es ebenfalls sein.

Vielen Teams fehlt ein klar benannter Verantwortlicher für diese Aufgaben, was in Incident-Post-Mortems immer wieder auftaucht. Melden Sie sich, um zu erfahren, wie webvise diese Maßnahmen in den Maintenance-Support verwalteter Projekte integriert.

Warum dieser Breach anders ist

Das Verteidigungsmodell muss dem Angriffsmodell entsprechen. Das bedeutet: OAuth-Grants als Produktionsabhängigkeiten behandeln, sie regelmäßig auditieren und Secrets aus Umgebungsvariablen herausverlagern, wo ein Angreifer mit dem entsprechenden Grant sie lesen kann. Die Audit-Logs dieses Wochenendes kamen sauber zurück, ein Ergebnis dieses Vorfalls, während das Response-Modell selbst weiterhin eine geplante Überprüfung braucht.

Ein Angreifer kompromittiert ein SaaS-Tool, das das Team autorisiert hat, und nutzt dann die Vertrauensbeziehung zwischen diesem Tool und anderen SaaS-Tools, um an Daten zu gelangen, die keines der Tools einem Fremden direkt gegeben hätte. Das Vercel-Konto wurde nicht direkt gehackt, der Google Workspace auch nicht. Ein Drittanbieter-Tool, das jemand vor Monaten verbunden hat, wurde kompromittiert, und die gewährten Scopes propagierten den Schaden nach unten.

Das sollte als dauerhafter Betriebsrhythmus verstanden werden, nicht als einmalige Bereinigung.

Sicherheitsreviews für Vercel-Teams, Google Workspaces und SaaS-zu-SaaS-Identitätsgraphen sind Bestandteil jedes Managed-Engagements bei webvise. Für eine zweite Überprüfung Ihres Vercel-Setups vor dem nächsten Vorfall: Kontakt aufnehmen.