Vercel April 2026 Incident Response Guide
Zuletzt aktualisiert: 20. April 2026 @ 12:07 Uhr AEST/Brisbane – (v2 – enthält Update des Vercel-CEOs vom 20. April)
Was ist passiert?
Vercel gab am 19. April 2026 bekannt, dass ein Angreifer unbefugten Zugang zu internen Systemen erlangt hat. Hier ist die offizielle Ankündigung:
Am 20. April veröffentlichte Vercel-CEO Guillermo Rauch ein detailliertes Update, das den anfänglichen Zugriffsweg bestätigte: Ein Vercel-Mitarbeiter nutzte eine KI-Plattform namens Context.ai, die selbst gehackt wurde; von dort aus wechselte der Angreifer in das Google Workspace-Konto des Mitarbeiters und eskalierte in Vercel-Umgebungen. Umgebungsvariablen sind im Ruhezustand verschlüsselt, aber der Angreifer konnte Variablen aufzählen, die nicht als "sensitiv" gekennzeichnet waren. Vercel bezeichnet den Angreifer als hochgradig raffiniert und wahrscheinlich KI-beschleunigt. Google Mandiant ist in die Reaktion eingebunden. Vercel gibt an, dass Next.js, Turbopack und deren Open-Source-Projekte sicher bleiben.
Hier ist der wichtige Abschnitt über Indikatoren einer Kompromittierung aus diesem Sicherheitshinweis:
Ziemlich detailarm. Sie sagen nicht einmal, wo Sie nach dem einen einzelnen Google-IOC suchen sollen. Als Vercel-Kunde bin ich ziemlich enttäuscht über diesen Detaillierungsgrad. Helfen Sie mir zu verstehen, wonach ich suchen soll! Sagen Sie mir, wohin ich gehen soll, um herauszufinden, ob ich kompromittiert wurde oder nicht!
In Ermangelung von Details von Vercel haben wir dieses Dokument erstellt
Wenn Sie Workloads auf Vercel betreiben, gehen Sie bis zum Beweis des Gegenteils von Folgendem aus:
- Umgebungsvariablen, die in keinem Vercel-Projekt im Gefährdungszeitraum als "sensitiv" gekennzeichnet waren, könnten lesbar gewesen sein.
- Jegliche Anmeldedaten, die über das Dashboard oder die CLI
vercel env an Vercel übergeben und nicht rotiert wurden, sind ein dauerhaftes Risiko.
- Tokens innerhalb der Integrationspfade Vercel ↔ GitHub und Vercel ↔ Linear könnten zugänglich gewesen sein.
- Sie werden nicht schnell ein klares "Sie sind betroffen / Sie sind nicht betroffen"-Signal erhalten. Rotieren Sie zuerst, dann untersuchen Sie.
Bekannt vs. behauptet: Halten Sie dies in Ihren Briefings getrennt
Diese Unterscheidung ist wichtig für die Kommunikation mit der Führungsebene und um nicht überzureagieren (oder zu wenig zu reagieren).
Von Vercel bestätigt (Bulletin + CEO-Update vom 20. April)
- Unbefugter Zugriff auf bestimmte interne Vercel-Systeme.
- Anfänglicher Zugriffsvektor: Context.ai, eine KI-Plattform, die von einem Vercel-Mitarbeiter genutzt wurde, wurde gehackt. Der Angreifer nutzte diese Basis, um das Vercel-Google-Workspace-Konto des Mitarbeiters zu kompromittieren und von dort aus in Vercel-Umgebungen zu eskalieren.
- Kundenspezifische Umgebungsvariablen sind im Ruhezustand verschlüsselt. Variablen, die als "nicht-sensitiv" gekennzeichnet waren, konnten vom Angreifer dennoch aufgezählt werden, sobald er drin war.
- Die Auswirkungen auf Kunden werden als "ziemlich begrenzt" beschrieben; Vercel hat Kunden, bei denen Bedenken bestehen, direkt kontaktiert.
- Next.js, Turbopack und die Open-Source-Projekte von Vercel wurden analysiert und gelten als sicher (d. h. kein bösartiges Artefakt im Veröffentlichungspfad dieser Projekte, Stand der Aussage von Vercel vom 20. April).
- Der Angreifer wird als hochgradig raffiniert und wahrscheinlich erheblich KI-beschleunigt beschrieben.
- Reaktionspartner: Google Mandiant ist aktiv eingebunden; externe IR-Firmen, Branchenkollegen und Strafverfolgungsbehörden sind beteiligt.
- Vercel hat sich an Context.ai gewandt, um den gesamten Umfang zu verstehen.
- Vercel hat UI-Verbesserungen ausgeliefert: Übersichtsseite für Umgebungsvariablen, verbesserte Verwaltung sensibler Umgebungsvariablen.
Von Dritten und dem Angreifer berichtet/zugeschrieben (nicht von Vercel bestätigt)
- Linear- und GitHub-Integrationen überproportional betroffen (Community-Berichte, insbesondere von Theo Browne auf X).
- Auf BreachForums zum Verkauf angebotene Daten: interne DB, Mitarbeiterkonten, GitHub-Tokens, npm-Tokens, Quellcodefragmente, Aktivitätszeitstempel – angeboten für ca. 2 Millionen US-Dollar.
- Der Akteur identifiziert sich selbst als ShinyHunters; andere historisch mit diesem Namen verbundene Akteure haben die Beteiligung bestritten.
- Spezifische Kunden-Datenklassen, die über das hinausgehen, was Vercel direkt mit Kunden bestätigt hat.
Behandeln Sie unbestätigte Berichte für Ihre eigene Triage als plausibel und umsetzbar, zitieren Sie sie jedoch nicht als Tatsache in der Kommunikation mit Kunden oder Aufsichtsbehörden, bis Vercel sie bestätigt oder Sie unabhängige Beweise haben. Die Lücke zwischen "aufzählbaren Umgebungsvariablen" (von Rauch bestätigt) und "npm + GitHub-Tokens zum Verkauf auf BreachForums" (Behauptung des Angreifers) ist die Lücke, die für das Lieferkettenrisiko am wichtigsten ist – gehen Sie für Rotationszwecke vom Schlimmsten aus, halten Sie sich für die Kommunikation an die bestätigte Version.
Abgrenzung: Wer dieses Playbook ausführen muss
Höchste Dringlichkeit – Sie haben eine direkte Kontaktaufnahme von Vercel erhalten oder einer der folgenden Punkte trifft zu:
- Sie haben (oder hatten) eine Vercel ↔ GitHub-Integration mit Schreibberechtigung für das Repository.
- Sie haben (oder hatten) eine Vercel ↔ Linear-Integration.
- Sie speichern unverschlüsselte Geheimnisse (nicht als sensitiv markiert) als Vercel-Umgebungsvariablen.
- Sie veröffentlichen npm-Pakete von CI/CD, das auf oder über die Vercel-Infrastruktur läuft.
Standard-Dringlichkeit – jedes Team mit aktiven Vercel-Projekten, auch Marketingseiten. Marketingseiten enthalten oft CMS-API-Schlüssel, Analyse-Tokens und Formular-Handler-Webhooks, die in sensiblere Systeme führen.
Trotzdem durchführen – selbst wenn Ihre Projekte vor dem Vorfall gelöscht wurden. Die Frage ist, ob Geheimnisse jemals in lesbarer Form in Vercel vorhanden waren, nicht ob das Projekt noch existiert.
Parallele Frage: Ist Ihr Unternehmen direkt Context.ai ausgesetzt?
Das Update vom 20. April nennt Context.ai als den gehackten vorgelagerten Anbieter. Wenn jemand in Ihrer Organisation Context.ai unabhängig von Vercel verwendet – für Meeting-Intelligence, Wissensmanagement, CRM-Anreicherung oder andere Workflows – haben Sie möglicherweise ein eigenes direktes Gefährdungsfenster, das vom Vercel-Vorfall getrennt ist.
Führen Sie diese Prüfungen parallel durch:
- Durchsuchen Sie Ihr SSO/IdP (Okta, Entra, Google Workspace) nach Benutzern, die sich bei Context.ai oder einer Context-bezogenen OAuth-App authentifiziert haben.
- Überprüfen Sie die Google Workspace-Admin-Konsole → Sicherheit → OAuth-App-Zugriffsprotokolle auf
context.ai oder zugehörige App-IDs.
- Überprüfen Sie die Unternehmensausgaben-/SaaS-Ausgabenverwaltungstools auf Context.ai-Abonnements.
- Überprüfen Sie, welche OAuth-Bereiche gewährt wurden – Gmail-Lesen, Kalender, Drive und Workspace-Verzeichnisbereiche haben hohe Auswirkungen.
Wenn Sie Context.ai-Nutzung in Ihrer Umgebung finden, widerrufen Sie die OAuth-Genehmigungen, rotieren Sie alle Anmeldedaten, die durch Context.ai-Workflows gelaufen sind, und überwachen Sie die Google Workspace-Konten der betroffenen Benutzer auf dieselben Indikatoren einer Kompromittierung, die Vercel bei ihrem Mitarbeiterkonto festgestellt hat. Wenden Sie sich für Ihre eigenen Vorfall-Details direkt an Context.ai; Vercel hat öffentlich erklärt, dass sie mit Context.ai koordinieren, um anderen betroffenen Organisationen zu helfen.
Phase 0: Die Blutung stoppen (erste 60 Minuten)
Zwei Ziele: neuen Schaden verhindern, Beweise sichern.
-
Bereitstellungen einfrieren. Automatische Bereitstellungen auf Produktionszweigen pausieren. Sie möchten verhindern, dass ein vom Angreifer modifizierter Build ausgeliefert wird, und das Protokoll soll sich nicht ständig ändern.
-
Vercels GitHub-App deaktivieren. Wenn Sie die Vercel GitHub-App installiert haben, was der Fall sein wird, wenn Sie automatische Bereitstellungen auf Vercel durchführen, wenn Sie neuen Code auf GitHub pushen. Sie finden Ihre installierten GitHub-Apps unter https://github.com/organizations/<GitHub-Organization>/settings/installations
-
Identifizieren Sie, welchen Zugriff die GitHub-App hat. Klicken Sie oben auf die Schaltfläche "Konfigurieren" und prüfen Sie, auf welche Repositorys die Vercel-App Zugriff hatte. Das sagt Ihnen, worauf Sie sich jetzt konzentrieren müssen. Gehen Sie zu GitHub → Organisation → Einstellungen → GitHub-Apps → Vercel. Überprüfen Sie:
- Repository-Zugriff (alle Repositorys vs. ausgewählte)
- Gewährte Berechtigungen
- Installationsdatum und wer sie installiert hat
- Erstellen Sie eine Momentaufnahme des Vercel-Aktivitätsprotokolls für Ihr Team. Exportieren oder erfassen Sie es sofort per Screenshot. Die Aufbewahrungsdauer ist begrenzt und die Benutzeroberfläche zeigt nicht alles. Holen Sie sich dies, bevor Sie Änderungen vornehmen, die das Protokoll verunreinigen. Sie finden es unter https://vercel.com/activity-log
- Aktivieren Sie "Observability Plus". Dies ist eine zusätzliche kostenpflichtige Funktion von Vercel, und es ist ärgerlich, dass ich vorschlagen muss, sie zu aktivieren und DAFÜR zu ZAHLEN, aber in diesem Fall halte ich es für das Beste, dies während der Incident Response zu tun. Ich bin sicherlich nicht glücklich darüber, aber ich habe es aktiviert, einfach weil es die Aktivitätsprotokolle länger speichert als die Standardeinstellung, die SEHR kurz ist.
- Erfassen Sie das Ausmaß der Gefährdung. Listen Sie für jedes Vercel-Team/Konto, das Sie kontrollieren, Folgendes auf:
- Projekte und deren verknüpfte Git-Repositorys
- Verbundene Integrationen (GitHub-App, Linear, Slack, Marketplace-Integrationen)
- Teammitglieder und ihre Rollen
- Persönliche Zugriffstokens / API-Tokens, die unter dem Team ausgestellt wurden
- Bereitstellungs-Hooks
- Überprüfen Sie das GitHub-Organisations-Aktivitätsprotokoll. Suchen Sie ****im Gefährdungszeitraum (vorsichtshalber 1.–15. April 2026 bis heute). Filtern Sie nach:
repo.add_member, repo.add_topicorg.invite_member, org.add_memberintegration_installation, integration_installation.repositories_added
Tätigen Sie noch keine Ankündigungen oder rotieren Sie keine Geheimnisse. Sie möchten zuerst die Momentaufnahme.
Phase 1: Auf Indikatoren einer Kompromittierung (IOC) prüfen
Die Details aus Vercels Ankündigung sind ziemlich dürftig:
So weit wir es verstehen, schlagen sie vor, dass Sie zu Ihrer Google Workspace Admin-Konsole gehen und nach dieser googleusercontent.com-App suchen. Hier ist, wie Sie diese in der Konsole finden:
-
Gehen Sie in Ihrer Workspace Admin-Konsole zu Sicherheit > Zugriff und Datenkontrolle > API-Steuerung und finden Sie die zugegriffenen und ausstehenden Apps.
-
Suchen Sie dann in den verschiedenen Listen nach dem IOC, das offenbar eine OAuth-App ist: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
-
Wenn Sie es finden, entfernen Sie es sofort und konsultieren Sie einen Incident-Response-Partner. Das übersteigt meine Gehaltsstufe.
Phase 2: Credential-Rotation
Rotation ist die einzelne Maßnahme mit dem höchsten Wert. Führen Sie sie in der Prioritätsreihenfolge durch, damit im Falle einer Unterbrechung das Gefährlichste bereits erledigt ist.
Was Sie rotieren müssen, hängt davon ab, was Ihre GitHub- und Vercel-Umgebungen freigelegt haben. Beginnen Sie mit GitHub-PATs usw. und arbeiten Sie sich mit diesem Leitfaden nach außen vor.
Prioritätsstufen
Stufe 0 – Heute rotieren, vor allem anderen:
- Rotieren Sie sofort alle GitHub-PATs und beenden Sie alle bestehenden Sitzungen. Persönliche Zugriffstokens oder PATs. Es gibt zwei Arten von PATs:
- Rotieren Sie sofort alle Vercel-Umgebungsvariablen, die sensitiv sind: http://vercel.com/all-env-vars
Stufe 1 – Heute rotieren, abhängig davon, was in Ihren Apps freigelegt wurde:
- Geheime Schlüssel für Zahlungsabwickler (Stripe, Adyen, Braintree usw.)
- Geheimnisse für Authentifizierungssignierung (NextAuth
AUTH_SECRET / NEXTAUTH_SECRET, JWT-Signierschlüssel, Sitzungs-Cookie-Schlüssel, CSRF-Tokens)
- Datenbank-Verbindungsstrings mit Schreibzugriff (
DATABASE_URL, direkte Postgres/MySQL-URLs, Mongo-URIs, Redis mit Authentifizierung)
- Cloud-Provider-Root- oder breit angelegte Schlüssel (AWS-IAM-Zugriffsschlüssel, GCP-Dienstkonto-JSON, Azure-Client-Geheimnisse)
- Geheimnisse für Webhook-Signierung (Stripe, GitHub, Slack – rotieren und die Senderkonfiguration aktualisieren)
Stufe 2 – Diese Woche rotieren:
- Drittanbieter-SaaS-API-Schlüssel (Analytik, E-Mail-Anbieter, SMS, CRM)
- OAuth-Client-Geheimnisse für Apps, die Sie besitzen
- SMTP-Anmeldedaten
- Verschlüsselungsschlüssel für anwendungsschichtige Kryptografie (mit Schlüsselversionserhöhung, nicht Ersatz direkt)
- CDN-Löschschlüssel, Bilddienstschlüssel
- Feature-Flag-Anbieterschlüssel
Stufe 3 – Bei Gelegenheit rotieren, aber trotzdem rotieren:
- Schreibgeschützte Analyse-Tokens
- Sentry/Logging-DSNs (Hinweis: DSN-Rotation ist nicht kritisch, wenn Sie mit einem kurzen Zeitfenster verlorener Ereignisse einverstanden sind)
- Öffentliche Schlüssel und anonyme Schlüssel (trotzdem rotieren – sie können die Existenz von Projekten offenbaren und manchmal die Aufzählung ermöglichen)
Fallstricke bei der Reihenfolge der Maßnahmen
- Sitzungssignierschlüssel invalidieren alle aktiven Sitzungen bei Rotation. Planen Sie ein erzwungenes Abmeldeereignis. Kommunizieren Sie es.
- Webhook-Geheimnisse müssen an beiden Enden rotiert werden. Aktualisieren Sie zuerst den Sender (Stripe, GitHub), um unter dem neuen Geheimnis zu senden, dann Ihren Empfänger, um dagegen zu prüfen. Oder unterstützen Sie vorübergehend beide.
- Datenbank-Anmeldedaten – erstellen Sie zuerst den neuen Benutzer, stellen Sie bereit, dann widerrufen Sie den alten. Ersetzen Sie ihn nicht direkt, sonst verursachen Sie eine Ausfallzeit.
- AWS-Schlüssel – Wenn Sie die Zugriffsschlüssel eines IAM-Benutzers rotieren, erstellen Sie den zweiten Schlüssel, rollen Sie die Bereitstellungen aus, dann löschen Sie den ersten. Nicht "deaktivieren" und hoffen.
- Nach Änderungen an Umgebungsvariablen erneut bereitstellen. Vercel-Umgebungsvariablen werden bei vielen Framework-Konfigurationen zur Build-Zeit eingebacken. Eine Änderung der Umgebungsvariablen ohne neue Bereitstellung ist nicht vollständig wirksam.
- Überprüfen Sie auch Ihre CI-Geheimnisse. Wenn ein Geheimnis auf GitHub Actions, CircleCI oder ähnliches gespiegelt wurde, rotieren Sie die Spiegelung.
Vergessen Sie nicht diese häufigen Fehler
.env.local in einem privaten Repository (immer noch ein Problem – Quellcode könnte exfiltriert worden sein)- Geheimnisse in Vercel-Preview-/Entwicklungsumgebungen, nicht nur in der Produktion
- Geheimnisse, die als Vercel-"Team-Level"-freigegebene Umgebungsvariablen gespeichert sind
- Bereitstellungs-Hooks (rotieren Sie diese; sie sind vollständige Bereitstellungsauslöser)
- Vercel persönliche Zugriffstokens, die unter Ihrem Konto ausgestellt wurden
- GitHub persönliche Zugriffstokens, die die Installation der Vercel GitHub-App autorisiert haben (getrennt von der App selbst)
Phase 3: Repo-Level-Jagd
Für Repositorys, die mit Vercel verbunden waren:
- Vergleichen Sie den HEAD von
main/master mit dem Tag/Commit, von dem Sie wissen, dass er vor dem Vorfall gut war.
- Suchen Sie nach Änderungen an:
package.json → scripts (insbesondere postinstall, prepare, preinstall)package-lock.json / pnpm-lock.yaml / yarn.lock – unerwartete Abhängigkeitshinzufügungen oder Versionserhöhungen.github/workflows/*.yml – neue Workflows, neue run:-Schritte, neue uses: mit nicht fixierten SHAsvercel.json – Änderungen am Build-Befehl, neue Rewrites/Redirects, die Datenexfiltration ermöglichen könnten
Wenn Sie npm-Pakete aus diesen Repositorys veröffentlichen
Hier könnte eine Vercel-Kompromittierung zu einem Lieferkettenereignis werden. Selbst wenn Sie Vercel nicht zum Veröffentlichen verwenden, wenn ein Angreifer Ihr GitHub-Token erhalten hat und Ihr Veröffentlichungsworkflow dieses Token verwendet:
- Überprüfen Sie den
npm-Veröffentlichungsverlauf: npm view <pkg> time --json auf unerwartete Versionen.
- Vergleichen Sie das Tarball jeder kürzlichen Version mit dem Git-Tag, von dem es stammen soll. Angreifer veröffentlichen von einem Tag, der nicht mit dem übereinstimmt, was im Registry ist.
- Überprüfen Sie die Verwendung von
NPM_TOKEN in Workflows – rotieren Sie das Token, überprüfen Sie, wer Zugriff hatte.
- Suchen Sie nach neuen Betreuern, die zu Ihren Paketen hinzugefügt wurden:
npm owner ls <pkg>.
- Wenn Sie etwas Bedeutendes betreuen, achten Sie auf die Ausführung von Post-Install-Skripten im Tarball – entpacken Sie es und prüfen Sie es.
Wenn Sie Beweise für eine nicht autorisierte Veröffentlichung finden, melden Sie dies der npm-Sicherheit ([email protected]) und erwägen Sie eine Meldung bei OSV.dev. Veralten Sie die schlechte Version; löschen Sie sie nicht (Löschen ist zeitlich begrenzt und unterbricht nachgelagerte Nutzer).
Hinweis zu Vercel-eigenen Paketen im Speziellen: Vercels Update vom 20. April gibt an, dass Next.js, Turbopack und ihre Open-Source-Projekte analysiert wurden und als sicher gelten. Das ist Vercels Behauptung über ihren Veröffentlichungspfad – Sie sollten dennoch Ihre Pakete wie oben prüfen. Wenn Sie Next.js oder Turbopack konsumieren, müssen Sie basierend auf aktuellen Informationen nicht als Vorsichtsmaßnahme auf eine Version vor dem Vorfall fixieren, aber überwachen Sie das Vercel-Bulletin auf Änderungen dieser Haltung.
Phase 4: Linear-Integrationsüberprüfung
Wenn Ihr Team die Vercel ↔ Linear-Integration verwendet:
- Überprüfen Sie das Linear-Aktivitätsprotokoll (Workspace-Einstellungen → Sicherheit → Aktivitätsprotokoll) für den Gefährdungszeitraum.
- Suchen Sie nach:
- Neu ausgestellten API-Schlüsseln
- Neu hinzugefügten Integrationen
- Kommentaren, die von Dienstkonten gepostet wurden
- Änderungen an Webhook-Zielen
- Mitgliedereinladungen
- Ansichten/Exporte von Ausgabedaten (die Integration hat Lesezugriff auf Ausgaben, die oft Kundennamen, Fehlerdetails und manchmal in Tickets eingefügte Anmeldedaten enthalten)
- Spezifisches Anliegen: Linear-Ausgaben enthalten häufig eingefügte Geheimnisse aus dem Debugging von Entwicklern. Durchsuchen Sie Ihren Linear-Workspace nach häufigen Leak-Mustern (
AKIA, sk_live_, ghp_, ghs_, npm_, eyJ, ----BEGIN). Alles Gefundene sollte rotiert werden.
Phase 5: Überprüfung der nachgelagerten Systemprotokolle
Die Rotation von Anmeldedaten neutralisiert in den meisten Fällen die Persistenz des Angreifers, aber er könnte den Zugriff bereits genutzt haben. Überprüfen Sie die Konsumenten Ihrer rotierten Geheimnisse auf Anzeichen einer Nutzung während des Gefährdungszeitraums.
Zu überprüfende Zeitfenster
Verwenden Sie 1. April 2026 bis jetzt als vorsichtige untere Grenze. Der Vorfall wurde am 19. April bekannt gegeben, aber der anfängliche Zugriff datiert vor der Bekanntgabe. Wenn Vercel ein genaueres Datum veröffentlicht, werden wir dies entsprechend eingrenzen.
Was abzufragen ist
- AWS CloudTrail – ungewöhnliche API-Aufrufe von kompromittierten IAM-Schlüsseln, insbesondere
GetObject-Bursts gegen S3-Buckets, CreateUser, AttachUserPolicy, Konsolenanmeldungen von neuen ASNs/Ländern.
- Datenbank-Aktivitätsprotokolle – ungewöhnliches
SELECT * auf sensitive Tabellen, große Exporte, Verbindungen von unerwarteten Quell-IPs.
- Stripe / Zahlungsprotokolle – ungewöhnliche Kundenerstellungen, Überweisungserstellungen, API-Schlüsselerstellungen.
- Auth-Anbieterprotokolle (Auth0, Clerk, Cognito, Firebase) – unmögliche Reise-Anmeldungen, Passwort-Zurücksetzungen für Admin-Benutzer, neue Anwendungsregistrierungen.
- E-Mail-Anbieter (SendGrid, Postmark usw.) – unerwartete ausgehende Kampagnen, neue API-Schlüssel, Änderungen der Senderidentität.
- GitHub – Klone, Fork-Erstellungen, neue SSH-Schlüssel auf Benutzerkonten mit Repo-Zugriff.
Nützliche IOC-Jagd-Primitive
Fügen Sie alle von Vercel oder IR-Partnern veröffentlichten gegnerischen Hostnamen oder IPs ein in:
- HTTP-Zugriffsprotokolle für Ihr Frontend (Angreifer testen manchmal vor, um den Zugriff zu bestätigen, bevor sie handeln).
- DNS-Protokolle – ausgehende Auflösung ungewöhnlicher Domains von Ihren Servern.
- Ausgehende Proxy-/VPC-Flussprotokolle.
Zum Zeitpunkt der Veröffentlichung wurden von Vercel keine IOCs freigegeben. Überwachen Sie das Vercel-Bulletin und die Berichte bekannter IR-Firmen auf Aktualisierungen.
Phase 6: Erkennung einer verbleibenden Kompromittierung
Die Persistenz des Angreifers nach einem Plattformschicht-Einbruch nimmt häufig diese Formen an. Jagen Sie aktiv nach jedem:1. Neue Teammitglieder oder Mitarbeiter in Ihrem Vercel-Team, GitHub-Org, Linear-Workspace oder Cloud-Konten. Datumsmäßig innerhalb des Gefährdungszeitraums.
2. Neue OAuth-Autorisierungen auf verbundenen SSO-Anbietern (Google Workspace, Okta, Entra ID) für die Konten Ihrer Entwickler.
3. Geänderte CI/CD-Konfiguration – Workflows, die jetzt nach Hause telefonieren, neue selbstgehostete Runner, neue Secrets mit harmlosen Namen.
4. Unerwartete Deployments in Vercel – überprüfen Sie die Deployment-Historie auf Deployments, die Sie keinem bekannten Commit eines bekannten Autors zuordnen können.
5. Reverse-Shell-Indikatoren in Serverless-Funktionslogs – Base64-Blobs, die geschrieben/ausgeführt werden, ungewöhnliche ausgehende Verbindungen von Edge/Serverless Functions.
6. DNS-Abweichung – neue Subdomains, CNAME-Änderungen, Weiterleitungen, die über vercel.json oder Framework-Konfiguration hinzugefügt wurden.
7. Authentifizierungsänderungen – MFA deaktiviert, Wiederherstellungscodes neu generiert, Passwort ohne Benutzereingriff geändert.
Kommunikation
Intern
Bestimmen Sie einen Einsatzleiter. Tägliches Stand-up mindestens, solange die Rotation läuft. Ein einziges Quell-der-Wahrheit-Dokument für „was wir rotiert haben, was aussteht, was wir gefunden haben“. Halten Sie es außerhalb von Linear, wenn Linear im Rahmen des Vorfalls liegt – nutzen Sie einen Nebenkanal.
Kundenorientiert
Rechtsbeistand konsultieren. Die Meldeschwellen variieren, aber:
- DSGVO: 72 Stunden für meldepflichtige Verstöße, die EU-Bürger betreffen.
- Australien (Notifiable Data Breaches scheme, OAIC): so bald wie möglich melden, wenn ernsthafte Schäden wahrscheinlich sind.
- USA: von Bundesstaat zu Bundesstaat unterschiedlich; einige Bundesstaaten haben 30–60 Tage Frist, andere verlangen eine sofortige Benachrichtigung für bestimmte Datenkategorien.
- Kalifornien (CCPA): spezifische Verpflichtungen, wenn personenbezogene Daten von Einwohnern Kaliforniens betroffen sind.
- SOC 2 / ISO 27001-Kunden: vertragliche Benachrichtigungsklauseln verlangen oft eine frühere Benachrichtigung als die regulatorischen Mindestanforderungen. Lesen Sie Ihre MSAs.
Wenn Sie keine Hinweise auf einen Datenabfluss aus Ihren Systemen haben, besteht möglicherweise noch keine Meldepflicht – aber „wir nutzen Vercel und Vercel hatte einen Vorfall“ allein reicht in der Regel nicht aus, um eine Meldung auszulösen, sofern keine sensiblen Daten materiell gefährdet waren. Dokumentieren Sie Ihre Begründung.
Vorbereitete Erklärungen
Erstellen Sie diese vorab, bevor Sie sie benötigen:
- Interne Mitarbeiterversammlung
- Kundenorientierte Mitteilung
- Regulierungsbehörden-Meldevorlage
- Statusseiten-Update (falls öffentlich)
Öffentliche Zuordnungshygiene
Wiederholen Sie die Behauptungen von Angreifern nicht öffentlich als Tatsache. Verlinken Sie auf das Vercel-Bulletin als Primärquelle. Lassen Sie Vercel ihren eigenen Vorfall charakterisieren – Sie sind in Ihrem Bereich unterwegs, um Ihre eigene Gefährdung zu charakterisieren.
Mittelfristige Härtung (nach dem Vorfall)
Dieser Vorfall deckt strukturelle Probleme auf, die es wert sind, behoben zu werden, selbst wenn Sie sich als unbeeinträchtigt herausstellen.
- Migrieren Sie alle Secrets zur Funktion für sensible Umgebungsvariablen von Vercel. Machen Sie es zum Teamstandard. Schulen Sie Entwickler darin, beim Erstellen das Flag zu setzen.
- Setzen Sie nach Möglichkeit kurzlebige Anmeldeinformationen ein. Nutzen Sie GitHub OIDC-Föderation mit AWS/GCP/Azure anstelle von langlebigen Zugriffsschlüsseln, die in Vercel-Umgebungsvariablen gespiegelt werden. Nutzen Sie cloudnative Secret-Manager (AWS Secrets Manager, GCP Secret Manager), die zur Laufzeit abgerufen werden, anstatt eingebackener Env-Vars.
- Inventarisieren Sie OAuth-Apps von Drittanbietern, die mit Ihrem Google Workspace, Microsoft 365, GitHub-Org und Vercel-Team verbunden sind. Der Vercel-IAV war Context.ai – eine KI-Plattform, die per OAuth in das Google Workspace eines Mitarbeiters integriert war. Dieselbe Risikoklasse besteht in jeder Organisation, die SaaS- und KI-Tool-Integrationen großzügig genehmigt hat, und die Messlatte für „was genehmigt wird“ ist im KI-Tool-Goldrausch der letzten 18 Monate erheblich gesunken. Konkrete Maßnahmen:
- Ziehen Sie Ihren Google Workspace-OAuth-App-Bericht (Admin-Konsole → Sicherheit → API-Steuerung → App-Zugriffssteuerung). Überprüfen Sie jede App mit sensiblen Bereichen (
gmail.readonly, calendar, drive, admin.directory).
- Machen Sie dasselbe für Microsoft 365 (Entra ID → Unternehmensanwendungen).
- Führen Sie vierteljährliche Überprüfungen ein. Verlangen Sie die Sicherheitsfreigabe für neue OAuth-Genehmigungen mit sensiblen Bereichen.
- Ziehen Sie in Betracht, die Installation von OAuth-Apps auf eine Whitelist zu beschränken, anstatt eine benutzergesteuerte Genehmigung zuzulassen.
- Prinzip der geringsten Privilegien im GitHub-App-Bereich. Wenn Vercel keinen organisationsweiten Repo-Zugriff benötigt, beschränken Sie es auf die Repos, die es tatsächlich deployed.
- Routine-Rotation von Deploy-Hooks. Vierteljährlich.
- Bauen Sie einen Secret-Scan in Ihren Pre-Commit und CI ein. Trufflehog, gitleaks oder gleichwertig. Scannen Sie die Repo-Historie nachträglich auf alles, was committet und dann rotiert wurde – gehen Sie davon aus, dass einmal Committetes noch in irgendeinem Clone vorhanden ist.
Referenz
Änderungsprotokoll
- 2026-04-20 (v2) – Aktualisiert nach der Stellungnahme von Vercel-CEO Guillermo Rauch vom 20. April. Mehrere Punkte von „berichtet“ auf „bestätigt“ hochgestuft: Context.ai als kompromittierter Upstream-Anbieter genannt, Google Workspace-Konto eines Vercel-Mitarbeiters als Dreh- und Angelpunkt, Aufzählung nicht-sensibler Env-Vars als laterale Bewegung innerhalb der Plattform. Parallele Prüfung der direkten Context.ai-Gefährdung hinzugefügt. Vercels Aussage hinzugefügt, dass Next.js, Turbopack und OSS-Projekte sicher bleiben. Mandiant-Engagement hinzugefügt. Die Empfehlung zur OAuth-App-Inventarisierung verstärkt.
- 2026-04-20 (v1) – Erste Version. Basierend auf Vercel-Bulletin vom 19.04.2026 und zeitgenössischen öffentlichen Berichten. Aktualisieren, sobald Vercel zusätzliche Details, IOCs oder ein engeres Gefährdungsfenster veröffentlicht.
opensourcemalware/vercel-april2026-incident-response
