Vercel speicherte Ihre Geheimnisse im Klartext und nannte es eine Funktion
Ein Angreifer gelangte über ein kompromittiertes KI-Tool und ein Google-Konto in Vercels Infrastruktur und entschlüsselte anschließend jede Umgebungsvariable, die nicht manuell als „sensitive" markiert worden war. Der Vorfall blieb zwei Monate lang unentdeckt.
Vercel wurde kompromittiert. Der Angreifer war rund zwei Monate lang im System, bevor der Vorfall entdeckt wurde. Dabei wurden Umgebungsvariablen von Kunden enumeriert und entschlüsselt — API-Schlüssel, Datenbankpasswörter, Signaturschlüssel, Tokens — und zwar für jedes Projekt, das nicht Vercels optionales Flag „sensitive" verwendet hatte.
Die Angriffskette: Ein Drittanbieter-KI-Tool namens Context.ai wurde kompromittiert. Der Angreifer nutzte diesen Zugang, um die Google-Workspace-Konten eines Vercel-Mitarbeiters zu übernehmen. Von dort aus gelangte er in Vercels interne Systeme. Anschließend begann er, Geheimnisse auszulesen.
Die Daten werden nun angeblich auf BreachForums für 2 Millionen Dollar angeboten.
Die „sensitive"-Checkbox, die nicht voreingestellt war
Hier kommt der relevante Teil.
Vercel kennt zwei Arten von Umgebungsvariablen. Normale, die „bei der Speicherung verschlüsselt" sind, aber von Vercels Systemen entschlüsselt und gelesen werden können. Und „sensitive", die eine zusätzliche Verschlüsselung verwenden, die nach Vercels Angaben selbst den internen Zugriff verhindert.
Der Angreifer konnte alle normalen Variablen lesen. Geschützt waren nur die „sensitive"-Variablen.
Das Problem: „sensitive" war ein Opt-in. Nicht der Standard. Jeder Entwickler, der DATABASE_URL oder STRIPE_SECRET_KEY oder JWT_SIGNING_KEY gesetzt hat, ohne eine Checkbox zu setzen — und das betrifft die meisten —, hatte diese Werte in einem Format vorliegen, das ein Angreifer mit internem Zugriff entschlüsseln konnte.
Vercels Empfehlung nach dem Vorfall: „Enable the sensitive environment variable feature for encrypted storage." Übersetzt: Die Verschlüsselung, von der Sie annahmen, sie schütze Ihre Geheimnisse, schützte sie in Wirklichkeit weder vor uns noch vor jemandem, der in unsere Systeme gelangt.
Zwei Monate Verweildauer
Die Erstkompromittierung erfolgte im Februar 2026. Vercel veröffentlichte sein erstes Sicherheitsbulletin am 19. April. Das sind rund zwei Monate, in denen ein Angreifer Zugriff auf interne Systeme hatte.
Vercels eigenes Sicherheitsteam beschrieb den Angreifer als „highly sophisticated based on their operational velocity and in-depth understanding of Vercel's product API surface". Wenn das Unternehmen, das Ihre Infrastruktur hostet, sagt, der Angreifer habe seine Systeme besser verstanden als erwartet, sollte Sie das nachdenklich machen.
In diesen zwei Monaten hatte der Angreifer Zeit, jede erreichbare Umgebungsvariable in den betroffenen Kundenprojekten zu enumerieren. Zeit für Exfiltration. Zeit für den Verkauf.
Die OAuth-Lieferkette
Der Einstiegspunkt war nicht einmal Vercels eigener Code. Ein Vercel-Mitarbeiter hatte Context.ai — ein KI-Produktivitätstool — über Google OAuth autorisiert. Als Context.ai kompromittiert wurde, übernahm der Angreifer jede Berechtigung, die diese OAuth-Freigabe umfasste.
Ein Muster, das sich ständig wiederholt. Organisationen sichern ihre primäre Authentifizierung sorgfältig ab und geben dann OAuth-Token an Drittanbieter-Tools weiter, die eine eigene, häufig schwächere Sicherheitslage haben. Eine kompromittierte App in der Kette, und der Angreifer erbt den Zugriff Ihres Mitarbeiters.
Die kompromittierte OAuth App ID ist öffentlich: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com. Falls Ihre Organisation diese App autorisiert hat, entziehen Sie die Berechtigung jetzt.
Was Sie tun sollten
Wenn Sie auf Vercel deployen:
- Rotieren Sie sofort jede Umgebungsvariable — warten Sie nicht ab, ob Sie „betroffen" waren
- Aktivieren Sie künftig für alle Umgebungsvariablen das Flag „sensitive"
- Prüfen Sie die OAuth-App-Berechtigungen Ihres Google Workspace und entziehen Sie alles, was Sie nicht aktiv nutzen
- Durchsuchen Sie die Vercel-Deployment-Logs auf unerwartete Änderungen im Zeitraum Februar bis April 2026
- Prüfen Sie nachgelagerte Dienste (Datenbanken, Zahlungsdienstleister, APIs) auf unbefugten Zugriff mit den Zugangsdaten, die in Vercel gespeichert waren
Die eigentliche Lehre
Vercels Architektur speicherte Kundengeheimnisse so, dass interner Zugriff sie entschlüsseln konnte. Es gab eine stärkere Option, aber sie war nicht voreingestellt. Zwei Monate lang hat niemand bemerkt, dass ein Angreifer diese Geheimnisse liest.
Das ist das Problem einer „trust us"-Sicherheit. Vercel hat Ihre Umgebungsvariablen bei der Speicherung verschlüsselt — technisch korrekt. Aber die Entschlüsselungsschlüssel lagen beim Anbieter. Als deren Systeme kompromittiert wurden, waren es auch Ihre Geheimnisse.
Die Alternative ist eine Zero-Knowledge-Architektur, bei der der Dienstleister Ihre Daten mathematisch nicht entschlüsseln kann. Nicht „darauf verzichtet" — kann nicht. Keine noch so weitreichende interne Kompromittierung, kein bösartiger Mitarbeiter, kein ausgefeilter Angreifer, der zwei Monate lang in Ihrer Infrastruktur lebt, kann lesen, wofür der Server nie die Entschlüsselungsschlüssel hatte.
Vercel bittet Kunden, eine Checkbox zu setzen, um echte Verschlüsselung zu aktivieren. Die Frage, die sich lohnt: Warum war das nicht von Anfang an die einzige Option?