Vercel-Verstoß: OAuth-Angriff legt versteckte Risiken von Plattform-Umgebungsvariablen offen

• Eine Kompromittierung der OAuth-Lieferkette führte zu Zugriff auf interne Systeme von Vercel und zur Offenlegung von Umgebungsvariablen in einer begrenzten Zahl von Kundenprojekten
• Ausgangspunkt war eine Lumma-Stealer-Infektion bei einem Mitarbeiter von Context.ai; ein geleakter Google-Workspace-OAuth-Token wurde für den Zugriff auf ein Vercel-Mitarbeiterkonto und interne Systeme verwendet
• Die Angreifer erhielten Berechtigungen, um Umgebungsvariablen von Kundenprojekten aufzulisten; insbesondere als non-sensitive markierte Variablen könnten die Offenlegung von Zugangsdaten zu nachgelagerten Diensten ausgeweitet haben
• Nach den veröffentlichten Hinweisen gab es in mindestens einem Fall bereits vor der Offenlegung durch Vercel eine Erkennung eines geleakten API-Schlüssels; der Zeitabstand zwischen Erkennung und Benachrichtigung tritt als zentraler Risikofaktor hervor
• Der Vorfall zeigt, dass OAuth-Vertrauensbeziehungen und die Art, wie Plattformen Umgebungsvariablen speichern, gemeinsam zu einer Ausbreitung von Zugangsdaten über die gesamte Lieferkette führen können

---

Zentrale Implikationen

• Verstärkungseffekt von OAuth bestätigt
  • Die Kompromittierung einer einzigen OAuth-Vertrauensbeziehung weitete sich kaskadenartig von einem Vendor bis in interne Systeme von Vercel aus
  • Selbst Umgebungsvariablen von Kundenprojekten ohne direkte Beziehung zum kompromittierten Vendor wurden in begrenztem Umfang offengelegt
• Möglichkeit KI-beschleunigter Angriffe aufgeworfen
  • Der CEO äußerte öffentlich, die ungewöhnliche Geschwindigkeit der Angreifer könne mit KI-Unterstützung zusammenhängen
  • Diese Einschätzung ist jedoch kein offizielles forensisches Ergebnis, sondern lediglich eine öffentliche Aussage
• Verzögerung zwischen Erkennung und Offenlegung hervorgehoben
  • In mindestens einem öffentlichen Kundenbericht gibt es Hinweise auf die Erkennung eines geleakten Schlüssels 9 Tage vor der Offenlegung durch Vercel
  • Bei Plattformkompromittierungen wird eine verzögerte Benachrichtigung nach der Erkennung als wesentlicher Risikofaktor benannt
• Verbindung zu einem breiteren Muster im Jahr 2026
  • Gemeinsam mit LiteLLM, Axios, Codecov und CircleCI passt der Vorfall in einen Lieferketten-Trend, der auf von Entwicklern gespeicherte Zugangsdaten zielt

Zeitlinie des Vorfalls

• Etwa im Februar 2026 wurde ein Mitarbeiter von Context.ai mit Lumma Stealer infiziert, wodurch Unternehmenszugangsdaten, Session-Token und OAuth-Token abflossen
• Etwa im März 2026 verschafften sich Angreifer Zugriff auf die AWS-Umgebung von Context.ai und stahlen OAuth-Token von Endnutzern
  • Darunter befand sich auch ein Google-Workspace-Token eines Vercel-Mitarbeiters
• Im März 2026 erfolgte über den gestohlenen OAuth-Token der Zugriff auf das Google-Workspace-Konto eines Vercel-Mitarbeiters
• Von März bis April 2026 wurde nach dem Übergang in interne Systeme von Vercel mit der Auflistung von Kunden-Umgebungsvariablen begonnen
• Etwa im April 2026 tauchte die Behauptung auf, ein mit ShinyHunters verbundener Akteur habe begonnen, Vercel-Daten zu verkaufen
• Am 10. April 2026 erwähnte ein Vercel-Kunde öffentlich, dass er von OpenAI eine Warnung über einen geleakten API-Schlüssel erhalten habe
• Am 19. April 2026 veröffentlichte Vercel eine Sicherheitsmitteilung und einen X-Thread
• Nach dem 19. April 2026 liefen Kundenbenachrichtigungen, Hinweise zur Rotation von Zugangsdaten und Dashboard-Änderungen an
• Trotz einer vergleichsweise kurzen Verweildauer von etwa 2 Monaten zeigt sich die Geschwindigkeit, mit der sich der Vorfall von der Infektion eines Drittanbieters bis zum Abfluss von Kunden-Umgebungsvariablen entwickelte
• Die Standard-Aufbewahrungsdauer für Google-Workspace-OAuth-Audit-Logs beträgt in vielen Tarifen 6 Monate
  • Die Verweildauer von rund 2 Monaten dürfte daher noch innerhalb des Aufbewahrungsfensters liegen
  • Zugleich wird darauf hingewiesen, dass ähnliche, länger andauernde Kompromittierungen die Standard-Aufbewahrungsfrist überschreiten könnten

Angriffskette

• Phase 1: Kompromittierung eines Drittanbieter-OAuth

  • Context.ai verfügte über eine von einem Vercel-Mitarbeiter genehmigte Google-Workspace-OAuth-Anwendung
  • Die Kompromittierung dieser Anwendung wird auf eine Lumma-Stealer-Infektion eines Context.ai-Mitarbeiters um Februar 2026 zurückgeführt
  • Laut Berichten von Hudson Rock und CyberScoop soll sich der Mitarbeiter nach dem Herunterladen eines Roblox-Game-Exploit-Skripts infiziert haben
  • Mit den gestohlenen Zugangsdaten verschafften sich die Angreifer Zugriff auf die AWS-Umgebung von Context.ai und leiteten OAuth-Token für Nutzer der im Juni 2025 gestarteten Context AI Office Suite ab
  • Context.ai teilte mit, im März 2026 einen unbefugten Zugriff auf seine AWS-Umgebung erkannt und gestoppt zu haben
  • Zugleich wurde ausdrücklich erklärt, dass der Abfluss der OAuth-Token selbst bis zu den Untersuchungen von Vercel nicht identifiziert worden sei
  • Genehmigte OAuth-Anwendungen haben folgende Eigenschaften
    • Benutzerpasswörter sind nicht erforderlich
    • Sie können auch nach einer Passwortänderung weiter gültig bleiben
    • Sie verfügen häufig über weitreichende Berechtigungen für E-Mail, Drive, Kalender und mehr
    • Nach der initialen Genehmigung werden sie nur selten auditiert

• Phase 2: Übernahme des Workspace-Kontos

  • Über den Zugriff auf die kompromittierte OAuth-Anwendung erfolgte der Übergang auf das Google-Workspace-Konto eines Vercel-Mitarbeiters
  • Dadurch wurden Zugriff auf E-Mails, interne Dokumente in Google Drive, Sichtbarkeit in Kalender und verbundene Ressourcen sowie potenziell Zugang zu weiteren per OAuth angebundenen Diensten möglich

• Phase 3: Zugriff auf interne Systeme

  • Vom kompromittierten Workspace-Konto aus erfolgte die weitere Bewegung in interne Systeme von Vercel
  • Rauch erklärte, die Eskalation sei über eine Reihe von Operationen verlaufen, die bei dem kompromittierten Vercel-Google-Workspace-Konto eines Kollegen begonnen hätten
  • Konkrete Techniken der lateralen Bewegung wurden nicht offengelegt
    • SSO-Integrationen
    • In E-Mails oder Drive gesammelte Zugangsdaten
    • Andere intern per OAuth verbundene Tools
    • Welche dieser Möglichkeiten zutraf, wurde nicht veröffentlicht

• Phase 4: Auflistung von Umgebungsvariablen

  • Die Angreifer erlangten Zugriff auf interne Systeme von Vercel mit ausreichenden Berechtigungen, um die Umgebungsvariablen von Kundenprojekten aufzulisten
  • Vercel bietet beim Speichern von Kunden-Umgebungsvariablen eine Kennzeichnung als „non-sensitive“ an
  • Nach den öffentlichen Aussagen wurden Kunden-Umgebungsvariablen nicht alle auf dieselbe Weise geschützt; über die Auflistung von nicht als sensibel markierten Variablen wurde zusätzlicher Zugriff möglich

• Phase 5: Möglicher Missbrauch nachgelagerter Dienste

  • Offengelegte Umgebungsvariablen enthalten gewöhnlich Zugangsdaten zu nachgelagerten Diensten
  • Laut dem öffentlichen Bericht von Andrey Zagoruiko vom 19. April 2026 erhielt er am 10. April eine Warnung von OpenAI über einen geleakten Schlüssel
  • Nach Aussage des Meldenden existierte dieser Schlüssel außer bei Vercel nirgends sonst
  • Dies deutet darauf hin, dass mindestens eine offengelegte Zugangsinformation möglicherweise schon vor der Offenlegung durch Vercel extern erkannt wurde

Die Lücke von 9 Tagen bis zur Offenlegung

• In einer Antwort im X-Thread von Guillermo Rauch vom 19. April machte der Kunde Andrey Zagoruiko öffentlich, dass er am 10. April 2026 eine Benachrichtigung von OpenAI über einen geleakten Schlüssel erhalten hatte
• Die Erkennung geleakter Zugangsdaten durch OpenAI wird normalerweise ausgelöst, wenn diese an öffentlichen Orten wie GitHub oder Paste-Sites gefunden werden
• Der Weg von einer Umgebungsvariablen bei Vercel zu einer OpenAI-Benachrichtigung wird im Artikel als nicht geradlinig bewertet
• Nach den Datumsangaben besteht zwischen dem frühesten öffentlichen Hinweis auf eine Offenlegung und der Offenlegung durch Vercel ein Fenster von 9 Tagen

• Was diese Lücke von 9 Tagen bedeutet und was nicht

  • Es handelt sich um einen einzelnen öffentlichen Bericht und nicht um ein forensisch bestätigtes Ergebnis
  • Sie darf nicht als Beleg dafür interpretiert werden, dass Vercel bereits am 10. April von der Kompromittierung wusste
  • Dennoch ist sie als Hinweis relevant, dass mindestens eine Zugangsinformation extern erkannt wurde, bevor Kunden zum Austausch ihrer Geheimnisse aufgefordert wurden

• Implikationen für die Beteiligten

  • Regulierungsbehörden
    • Unter der DSGVO beginnt die 72-Stunden-Frist zur Benachrichtigung ab dem Zeitpunkt, an dem der Verantwortliche von der Verletzung Kenntnis erlangt
    • Wann Vercel Kenntnis erlangte, wird damit zu einem öffentlichen Streitpunkt
  • Auditoren
    • Prüfer für SOC 2 und ISO 27001 könnten Verzögerungen zwischen Erkennung und Benachrichtigung als Nachweis für das laufende Monitoring bewerten
  • Kunden
    • Es kann nicht angenommen werden, dass das Offenlegungsfenster erst am 19. April begann
    • Im Artikel wird dargelegt, dass eine aktive Ausnutzung schon vorher möglich gewesen sein könnte
  • Von Providern versandte Warnungen über geleakte Zugangsdaten gewinnen als Frühwarnkanal an Bedeutung
  • Genannt werden unter anderem OpenAI, Anthropic, GitHub, AWS und Stripe

KI-beschleunigte Angriffsaktivitäten

• Guillermo Rauch erklärte am 19. April 2026 auf X, er vermute stark, dass die Angreifergruppe hochgradig ausgefeilt sei und in erheblichem Maß durch KI beschleunigt wurde.
• Der Artikel behandelt diese Aussage als öffentlich dokumentierte Einschätzung des CEO der betroffenen Plattform und weist auf die Notwendigkeit einer vorsichtigen Prüfung hin.

• Anzeichen, die in forensischen Belegen zu erwarten wären

  • Aufzählungsgeschwindigkeit über manuellem Tempo
    • Teilweise allein durch Skripting erklärbar
    • LLM-basierte Aufklärung kann Schema-Erkundung, Endpoint-Sondierung und die Erkennung von Credential-Formaten parallelisieren.
  • Kontextbewusste Formulierung von Anfragen
    • Anfragen, die zu wissen scheinen, was Vercel-spezifische Begriffe, Projekt-Slugs, Namen von Deployment-Zielen und Namenskonventionen für Env Vars sind, auch ohne offensichtliche vorherige Aufklärung
  • Anpassungsfähigkeit bei der Fehlerbehandlung
    • Strategiewechsel nach API-Fehlern und Rate Limits sind flexibler als bei statischen Skripten.
  • Sozialtechnische Artefakte mit lokalem Anschein
    • Phishing-Köder, Commit-Messages und Support-Tickets in einer Qualität, die dem lokalen Kontext näherkommt als Übersetzungen oder Templates

• Bedeutung über den Vercel-Vorfall hinaus

  • Unabhängig davon, ob diese Einschätzung in einer formalen Forensik bestehen bleibt, ist die Kategorie KI-gestützter Angriffsoperationen nicht mehr bloß reine Vermutung.
  • Microsoft dokumentierte in einer Veröffentlichung vom April 2026 Beispiele für KI-basiertes Device-Code-Phishing, dynamische Code-Erzeugung, hyperpersonalisierte Köder und automatisierte Backend-Orchestrierung.
  • Es wird darauf hingewiesen, dass Telemetrie-Baselines, die auf menschliche Geschwindigkeitsmaßstäbe zugeschnitten sind, bei KI-beschleunigten Akteuren false negatives erzeugen können.

• Implikationen für Detection Engineering

  • Wenn Aufzählung und laterale Bewegung komprimiert stattfinden, können bestehende Regeln auf Basis von Verweildauer und Geschwindigkeits-Schwellenwerten zu wenig Alarm auslösen.
  • Es wird eine Neubewertung der folgenden Punkte angeregt:
    • Rate der Aufzählung eindeutiger Ressourcen pro Session
    • Kurve der Wiederherstellung erfolgreicher Zugriffe im Verhältnis zu Fehlern
    • Diversität von Anfrage-Mustern in kurzer Zeit

Zentrale Schwachstelle im Design von Umgebungsvariablen

• Der gravierendste Aspekt im Artikel ist weniger der ursprüngliche Zugriffsvektor als vielmehr Vercels Sensitivitätsmodell für Umgebungsvariablen.

• So funktionierten Vercel-Umgebungsvariablen damals

  • Projekte injizieren Umgebungsvariablen in Serverless Functions und Build-Prozesse.
  • Es gibt pro Variable ein sensitive-Flag.
  • Der Standardwert ist non-sensitive.
  • sensitive muss ausdrücklich aktiviert werden.
  • non-sensitive-Variablen werden im Dashboard angezeigt.
  • sensitive-Variablen werden nach ihrer Erstellung maskiert.
  • Zugriff über die interne API ist bei non-sensitive möglich, bei sensitive eingeschränkt.
  • Verschlüsselte Speicherung gilt laut öffentlichen Aussagen nicht für non-sensitive, für sensitive dagegen zusammen mit zusätzlichen Einschränkungen.
  • In diesem Vorfall waren die für die Angreifer zugänglichen Werte als non-sensitive markiert.

• Entscheidendende Designentscheidung

  • Das sensitive-Flag ist standardmäßig deaktiviert.
  • Alle DATABASE_URL, API_KEY, STRIPE_SECRET_KEY und AWS_SECRET_ACCESS_KEY, die Entwickler nicht ausdrücklich aktivierten, wurden im internen Zugriffsmodell von Vercel unverschlüsselt gespeichert.
  • Sicherheitskontrollen, die für jedes einzelne Geheimnis ein explizites Opt-in verlangen und weder Standardschutz noch Guardrails bieten, werden als Maßnahmen mit geringer tatsächlicher Einführungsrate bewertet.

• Reaktion von Vercel

  • Die Auslieferung von Verbesserungen an der Übersichtsseite für Umgebungsvariablen sowie an der UI zum Erstellen und Verwalten sensibler Variablen wurde bestätigt.
  • Bei der Sichtbarkeit gab es Verbesserungen, doch zum Zeitpunkt des Schreibens ist der Standardwert weiterhin nicht geändert.
  • Weiterhin ist ein Opt-in pro Variable erforderlich.
  • Ob der Standardwert umgestellt wird, bleibt eine offene öffentliche Frage.

• Branchenvergleich

  • Die Branche bewegt sich in Richtung dedizierter Secret Stores wie Vault, AWS Secrets Manager, Doppler und Infisical.
  • Der Vorfall stützt nach Einschätzung des Artikels die Entscheidung für dedizierte Secret-Management-Strukturen gegenüber Vercels umgebungsvariablenbasiertem Ansatz.
  • Laut Vergleichstabelle gilt:
    • Vercel hat non-sensitive als Standardwert, ohne automatische Erkennung.
    • AWS SSM Parameter Store unterstützt SecureString.
    • HashiCorp Vault bietet Verschlüsselung für alle Secrets und ACLs.
    • GitHub Actions maskiert alle Secrets in Logs.
    • Netlify verwendet einen Umgebungsvariablen-Ansatz mit Secret-Toggle.

Credential Fan-out und nachgelagerte Risiken

• Credential fan-out ist das Phänomen, dass eine einzelne Plattformverletzung kaskadierend alle nachgelagerten Dienste offenlegt, die mit den in dieser Plattform gespeicherten Zugangsdaten authentifiziert werden.
• Übersicht über häufig in Vercel-Projekt-Umgebungsvariablen enthaltene Elemente und ihre nachgelagerten Auswirkungen
  • Datenbanken
    • DATABASE_URL, POSTGRES_PASSWORD
    • Möglichkeit des vollständigen Datenzugriffs
  • Cloud
    • AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY
    • Möglichkeit der Kompromittierung des Cloud-Kontos
  • Zahlungen
    • STRIPE_SECRET_KEY, STRIPE_WEBHOOK_SECRET
    • Risiko für Finanzdaten und Refund-Betrug
  • Authentifizierung
    • AUTH0_SECRET, NEXTAUTH_SECRET
    • Möglichkeit von Session-Fälschung und Account-Übernahme
  • Mailversand
    • SENDGRID_API_KEY, POSTMARK_TOKEN
    • Möglichkeit von Phishing auf Basis vertrauenswürdiger Domains
  • Monitoring
    • DATADOG_API_KEY, SENTRY_DSN
    • Möglichkeit der Manipulation von Telemetrie
  • Source und Packages
    • GITHUB_TOKEN, NPM_TOKEN
    • Möglichkeit von Supply-Chain-Injection
  • AI/ML
    • OPENAI_API_KEY, ANTHROPIC_API_KEY
    • Möglichkeit von API-Missbrauch und Kostenverursachung
• Ein einzelnes Vercel-Projekt enthält typischerweise 10 bis 30 Umgebungsvariablen.
• Auf Organisationsebene kann ein Portfolio von 50 Projekten 500 bis 1.500 Zugangsdaten auf der Plattform enthalten.
• Zwar heißt es, in diesem Vorfall seien nur einige begrenzte Kundenprojekte betroffen gewesen, doch jede offengelegte Credential kann zum Sprungpunkt in ein separates System werden.
• Der Artikel definiert diesen Punkt nicht als bloßen Vertraulichkeitsvorfall auf Plattformebene, sondern als Multiplikatoreffekt, der sich über die gesamte Software-Supply-Chain ausbreitet.

OAuth-Vertrauensbeziehungen und Umgehung von Boundary Defenses

• OAuth-basierte Einbrüche umgehen zahlreiche Kontrollen, die traditionelle credential-basierte Angriffe erkennen oder blockieren.
• Im Artikel steht ein Satz mit etwa 22 Monaten, doch in der Korrektur am Anfang wird die Verweildauer auf etwa 2 Monate geändert.
• Es wird beschrieben, dass viele der Abwehrkontrollen, auf die sich Sicherheitsteams in der linken Spalte verlassen, beim Kompromittierungspfad über OAuth-Apps bedeutungslos sind oder bereits erfüllt wurden.
• Durch diese Asymmetrie entwickelt sich OAuth Governance zu einem eigenen Sicherheitsbereich neben IAM.

• OAuth Governance ist eine Vendor-Risk-Funktion

  • Viele Organisationen behandeln OAuth-Freigaben als Self-Service-Thema für Entwickler.
  • Es bleibt bei der Freigabe benötigter Tools pro Mitarbeiter mit minimaler zentraler Prüfung.
  • Dieser Vorfall wird als Beleg dafür angeführt, dass genehmigte OAuth-Apps als Drittanbieter mit dauerhaftem Zugriffsrecht behandelt werden müssen.
  • Erforderlich sind Vendor Review, regelmäßige Re-Autorisierung und Monitoring ungewöhnlicher Nutzung.

Behauptungen von Bedrohungsakteuren und Zuschreibung

• Grundannahme: Behauptungen von Bedrohungsakteuren in Untergrundforen sind ihrem Wesen nach schwer vertrauenswürdig
• Die Informationen hier sind nicht als bestätigte Fakten, sondern zur Einordnung und Nachverfolgung zusammengefasst

• Behauptete Verbindung zu ShinyHunters

  • Ein Beitrag auf BreachForums behauptet eine Verbindung zu ShinyHunters sowie den Besitz von Vercel-Daten
  • Behauptete Datenelemente
    • rund 580 Mitarbeiterdatensätze
    • Source-Code-Repositories
    • API-Schlüssel und interne Tokens
    • GitHub- und NPM-Tokens
    • interne Kommunikation
    • Zugriff auf den Linear-Workspace
  • Die oben genannten Mengenangaben und der Umfang sind sämtlich nicht verifiziert

• Faktoren, die eine Zuschreibung erschweren

  • Bekannte ShinyHunters-Mitglieder bestritten gegenüber BleepingComputer eine Beteiligung
  • Es gibt die Behauptung, dass über Telegram ein Lösegeld von 2 Millionen US-Dollar gefordert wurde
  • Die Marke ShinyHunters wird seit der ursprünglichen Kampagne von mehreren oder auch nicht verbundenen Akteuren verwendet
  • In der Sicherheitsmitteilung von Vercel wird auf die betreffenden Forenbehauptungen nicht eingegangen
  • Rauchs Thread behandelt die Angriffskette, geht aber nicht direkt auf den Forenbeitrag ein

• Vercels Position zum Supply-Chain-Release-Pfad

  • Rauch erklärte, man habe die Supply Chain von Next.js, Turbopack und mehreren Open-Source-Projekten analysiert und der Community mitgeteilt, dass sie sicher seien
  • Zum Zeitpunkt des Schreibens läuft eine unabhängige Verifizierung noch
  • Organisationen, die Next.js, Turbopack und andere Vercel-Open-Source-Projekte nutzen, wird empfohlen, weiterhin auf Signale zur Paketintegrität wie Prüfsummen, Signaturen und Provenance Attestations zu achten
  • Da es keine unabhängige Verifizierung der in den Foren behaupteten Daten gibt, müssen diese als unbestätigte Informationen behandelt werden
  • Die von Vercel offengelegte OAuth-basierte Angriffskette reicht bereits aus, um den Vorfall technisch zu erklären; der vom Forenbeitrag behauptete weitreichende Zugriffsumfang ist dafür nach dieser Einschätzung keine notwendige Voraussetzung

MITRE ATT&CK-Mapping

• Die bestätigte Angriffskette lässt sich natürlich bestehenden MITRE ATT&CK-Techniken zuordnen
• Mapping-Punkte
  • Initial Access / Trusted Relationship / T1199
    • Die Context.ai-OAuth-App wurde als vertrauenswürdiger Dritter genutzt
  • Persistence / Application Access Token / T1550.001
    • OAuth-Tokens bleiben auch nach einer Passwortänderung bestehen
  • Credential Access / Valid Accounts / T1078
    • kompromittierte Workspace-Zugangsdaten eines Mitarbeiters
  • Discovery / Account Discovery / T1087
    • Auflistung interner Systeme und Projekte
  • Credential Access / Unsecured Credentials: Credentials in Files / T1552.001
    • Zugriff auf nicht sensible Umgebungsvariablen möglich
  • Lateral Movement / Valid Accounts: Cloud Accounts / T1078.004
    • mögliche Nutzung offengelegter Cloud-Zugangsdaten
  • Collection / Data from Information Repositories / T1213
    • Auflistung von Umgebungsvariablen über Projekte hinweg
• Der wertvollste Erkennungspunkt in diesem Mapping ist der Übergang von OAuth-Anwendungszugriff zu Zugriff auf interne Systeme
• Organisationen sollten anomales Verhalten von OAuth-Apps überwachen, die auf Ressourcen außerhalb des erwarteten Umfangs oder aus unerwarteten IP-Bereichen zugreifen

Supply-Chain-Belagerung: LiteLLM, Axios, Vercel

• Der Vercel-Vorfall ist kein isoliertes Ereignis, sondern Teil einer Welle von Supply-Chain-Angriffen, die sich im März und April 2026 konzentrierte
• Der Artikel hält fest, dass dies entweder eine koordinierte Kampagne sein könnte oder – wahrscheinlicher – das Ergebnis davon, dass mehrere Angreifer gleichzeitig dieselbe strukturelle Schwäche entdeckten: Vertrauensgrenzen zwischen Paket-Repositories, CI/CD, OAuth-Anbietern und Deployment-Plattformen

• 24. März 2026: LiteLLM-PyPI-Supply-Chain-Kompromittierung

  • Bösartige PyPI-Pakete litellm 1.82.7 und 1.82.8 veröffentlicht
  • Verwendet wurden aus Aquas Security-Schwachstellen-Scanner Trivy gestohlene CI/CD-Deployment-Zugangsdaten
  • LiteLLM ist ein LLM-Proxy mit rund 3,4 Millionen Downloads pro Tag
  • Die dreistufige Backdoor zielte auf mehr als 50 Arten von Zugangsdaten über große Cloud-Anbieter hinweg
  • Einschließlich Persistenz via Kubernetes DaemonSet
  • Die Verweildauer bis zur Erkennung und Entfernung lag bei etwa 40 Minuten bis 3 Stunden
  • Die zugehörige CVE lautet CVE-2026-33634

• 31. März 2026: Axios-npm-Supply-Chain-Kompromittierung

  • Das npm-Paket axios verzeichnet 70 bis 100 Millionen Downloads pro Woche
  • Nach der Übernahme eines Maintainer-Kontos wurden die bösartigen Versionen 1.14.1 und 0.30.4 verteilt
  • Die Abhängigkeit plain-crypto-js@4.2.1 wurde eingeschleust und enthielt ein plattformübergreifendes RAT
  • Es wurde festgestellt, dass 135 infizierte Endpunkte mit der C2-Infrastruktur der Angreifer kommunizierten
  • Die Verweildauer betrug 2 bis 3 Stunden
  • Microsoft schreibt den Angriff dem von Nordkorea unterstützten Bedrohungsakteur Sapphire Sleet zu

• Konvergierende Muster

  • 3 Angriffe in 3 Wochen
  • unterschiedliche Vektoren
  • das gemeinsame Ziel waren Zugangsdaten und Geheimnisse, die Entwickler in der Toolchain gespeichert hatten
  • Die tabellarische Zusammenfassung nennt:
    • LiteLLM: Diebstahl von CI/CD-Zugangsdaten → PyPI, Entwickler-Zugangsdaten und API-Schlüssel, 40 Minuten bis 3 Stunden
    • Axios: Übernahme eines Maintainer-Kontos → npm, RAT auf Entwickler-Workstations, 2 bis 3 Stunden
    • Vercel: Kompromittierung einer OAuth-App → Plattform, Kunden-Umgebungsvariablen, in der Tabelle mit rund 22 Monaten angegeben, in der Korrektur oben und im Haupttext jedoch auf rund 2 Monate berichtigt

Gemeinsame Muster mit früheren Plattform-Kompromittierungen

• Der Vercel-Vorfall reiht sich in ein wiederkehrendes Muster ein, bei dem Kompromittierungen auf Plattformebene Kundengeheimnisse offenlegen

• Kompromittierung des Codecov Bash Uploaders, Januar bis April 2021

  • Angreifer modifizierten das Bash-Uploader-Skript, um Umgebungsvariablen aus CI-Umgebungen von Kunden abzuleiten
  • Rund 2 Monate unentdeckt
  • Potenziell mehr als 29.000 Kunden betroffen, darunter Twitch, HashiCorp und Confluent
  • Die Gemeinsamkeit mit Vercel ist die Offenlegung von Kunden-Umgebungsvariablen durch eine Plattform-Kompromittierung

• Sicherheitsvorfall bei CircleCI, Januar 2023

  • Malware auf einem privaten Gerät stahl das SSO-Session-Token eines Mitarbeiters
  • Nach Zugriff auf interne Systeme wurden Kundengeheimnisse und Verschlüsselungsschlüssel entwendet
  • CircleCI empfahl allen Kunden, sämtliche auf der Plattform gespeicherten Geheimnisse zu rotieren
  • Die Struktur ist fast identisch mit Vercel
    • Kompromittierung eines Mitarbeiterkontos
    • Zugriff auf interne Systeme
    • Exfiltration von Kundengeheimnissen

• Angriff auf Snowflake-Kundenzugangsdaten, Mai bis Juni 2024

  • UNC5537 nutzte mit Infostealern erbeutete Zugangsdaten und Konten ohne MFA
  • Mehr als 165 Organisationen betroffen
  • Darunter Ticketmaster, Santander Bank und AT&T

• Kompromittierung des Okta-Supportsystems, Oktober 2023

  • Mit gestohlenen Zugangsdaten wurde auf das Fallmanagementsystem des Kundensupports zugegriffen
  • Einsicht in Session-Tokens in HAR-Dateien
  • Betroffen waren unter anderem Cloudflare, 1Password und BeyondTrust

• Musterzusammenfassung

  • Initialzugriff über Vertrauensbeziehungen oder Zugangsdaten
  • laterale Bewegung in interne Systeme
  • Exfiltration von Kundengeheimnissen
  • der Zielumfang reicht von einzelnen Zielen bis zur gesamten Plattform
  • Die Tabelle fasst für jeden Vorfall den initialen Vektor, die offengelegten Assets und die Verzögerung bis zur Entdeckung zusammen
    • Codecov rund 2 Monate
    • Okta mehrere Wochen
    • CircleCI mehrere Wochen
    • Snowflake mehrere Monate
    • Vercel rund 2 Monate

Was weiterhin nicht öffentlich ist

• Trotz umfangreicher Berichterstattung und vieler Aussagen von Führungskräften bleiben zentrale Lücken bestehen
• Nach öffentlicher Aktenlage ungeklärte Fragen
  • wann Vercel die auffällige Aktivität erstmals erkannte
  • warum zwischen dem frühesten öffentlichen Nachweis einer missbräuchlichen Nutzung von Zugangsdaten und der Offenlegung 9 Tage Differenz liegen
  • Anzahl betroffener Kunden
    • Rauch sprach von „quite limited“, nannte aber keine konkrete Zahl
  • ob die Behauptungen im ShinyHunters-Forum vom selben Angreifer stammen
  • der aktuelle Status von Context.ai und ob nachgelagerte Kunden benachrichtigt wurden
  • der vollständige Umfang des internen Zugriffs bei Vercel
    • die Zahl betroffener Teams, Projekte und Umgebungsvariablen ist nicht offengelegt
    • auch ob neben Kunden-Umgebungsvariablen weitere interne Systeme betroffen waren, ist unbestätigt
• Der Artikel betont, dass für eine stringente Analyse nicht nur bekannte Fakten wichtig sind, sondern auch die explizite Anerkennung dessen, was nicht öffentlich gemacht wurde

Erkennungs- und Hunting-Leitfaden

• Sofortmaßnahmen für Vercel-Kunden

  • Alle Projekt-Umgebungsvariablen müssen überprüft werden.
  • Der Artikel enthält die folgenden CLI-Beispiele.
    • vercel env ls --environment production
    • vercel env ls --environment preview
    • vercel env ls --environment development
  • Da die CLI das sensitive-Flag derzeit nicht direkt anzeigt, ist eine Prüfung im Dashboard oder per API erforderlich.

• Suche nach unbefugter Nutzung offengelegter Zugangsdaten

  • Audit-Logs von Cloud-Anbietern durchsuchen
    • AWS CloudTrail
      • eventSource-Filter mit sts.amazonaws.com, iam.amazonaws.com, s3.amazonaws.com
      • Nach userIdentity.accessKeyId suchen, das mit dem rotierten, in Vercel gespeicherten Access Key übereinstimmt.
      • sourceIPAddress außerhalb der bekannten CIDRs der Organisation erkennen, ebenso userAgent-Werte wie python-requests, curl, Go-http-client und unbekannte Automatisierungs-Strings.
      • Zeitraum: von Februar 2026 bis heute
    • GCP Audit Logs
      • Nach protoPayload.authenticationInfo.principalEmail des Servicekontos suchen, das den in Vercel gespeicherten Schlüssel verwendet.
      • callerIp außerhalb des bekannten Bereichs
      • Methoden wie storage.objects.get, compute.instances.list, iam.serviceAccountKeys.create prüfen
    • Azure Activity Logs
      • Nach Anwendungs-ID oder Service Principal filtern, die in den Vercel-Umgebungsvariablen enthalten waren.
      • callerIpAddress außerhalb des erwarteten Bereichs
      • Vorrangig Microsoft.Storage/storageAccounts/listKeys, Microsoft.Compute/virtualMachines/write, Microsoft.Authorization/roleAssignments/write prüfen
  • Zugriffslogs von Datenbanken durchsuchen
    • Alle DB-Ziele, deren Verbindungsstrings in Vercel-Umgebungsvariablen enthalten waren
    • Das gesamte Zeitfenster von Februar bis April 2026 analysieren
    • IPs außerhalb bekannter Egress-Bereiche wie Vercel-Edge-IP, VPN oder Büro prüfen
    • Verbindungen erkennen, die offengelegte Zugangsdaten außerhalb normaler Deployment-Fenster verwenden
    • Bei PostgreSQL pg_stat_activity, log_connections
    • Bei MySQL General Log oder Audit-Plugin
    • Bei MongoDB Atlas die Ereignisse DATA_EXPLORER und CONNECT im Project Activity Feed
  • Logs von Zahlungsabwicklern durchsuchen
    • Stripe Dashboard → Developers → Logs
    • source_ip außerhalb der erwarteten Server
    • /v1/charges, /v1/transfers, /v1/payouts, /v1/customers
    • Entsprechende Logs bei Braintree und Adyen prüfen
    • Vorrangig API-Schlüssel prüfen, die als non-sensitive env vars gespeichert sind und noch nicht rotiert wurden.
    • Auch unerwartete Sendungen in den Logs von E-Mail-Versanddiensten prüfen
  • Unaufgeforderte Benachrichtigungen über offengelegte Zugangsdaten von OpenAI, Anthropic, GitHub, AWS, Stripe usw. müssen geprüft werden.

• Rotation und Redeployment sind gemeinsam erforderlich

  • Laut Vercel-Dokumentation macht allein die Rotation von Umgebungsvariablen bestehende Zugangsdatenwerte in früheren Deployments nicht ungültig.
  • Frühere Deployments verwenden die alten Zugangsdaten weiter, bis sie neu bereitgestellt werden.
  • Daher erfordert jede Rotation ein Redeployment aller Umgebungen, die diese Variablen verwenden, oder die explizite Deaktivierung früherer Deployments.
  • Die Priorisierung erfolgt in folgender Reihenfolge.
    • Zugangsdaten von Cloud-Anbietern
    • Datenbank-Verbindungsstrings
    • Schlüssel für Zahlungsabwicklung
    • Authentifizierungsgeheimnisse
    • API-Schlüssel von Drittanbietern
    • Tokens für Monitoring und Logging

• Vorbeugende Maßnahmen für Sicherheitsteams

  • In der Google Workspace Admin Console unter Security → API Controls → Third-party app access alle genehmigten OAuth-Apps überprüfen.
  • Apps mit weitreichenden Scopes wie Drive, Gmail und Calendar kennzeichnen
  • Anbieter-Apps ohne aktive Geschäftsbeziehung untersuchen
  • Nutzung von OAuth-Tokens aus unerwarteten IP-Bereichen überwachen
  • Nach bekannter bösartiger OAuth Client ID suchen
    • 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com

SIEM-Erkennungslogik

• Auffälligkeiten bei OAuth-Anwendungen, Phase 1–2

  • Sofort Alarm auslösen bei Token-Refresh- oder Autorisierungsereignissen, die mit der bekannten bösartigen OAuth Client ID verknüpft sind.
  • Berechtigungsereignisse mit weitreichenden Scopes wie vollständigem Mailzugriff, Drive-Lese-/Schreibzugriff oder Kalenderzugriff mit der aktuellen Anbieter-Liste abgleichen
  • Apps, die geschäftlich nicht mehr verwendet werden, sind Kandidaten für einen Widerruf.
  • Wenn die Token-Nutzung genehmigter OAuth-Apps von IPs außerhalb der erwarteten CIDR-Bereiche des Unternehmens und der Anbieter erfolgt, ist eine Untersuchung erforderlich.

• Zugriff auf interne Systeme und laterale Bewegung, Phase 3

  • Ungewöhnliche SSO-/SAML-Authentifizierungsereignisse
    • Wenn sich ein kompromittiertes Workspace-Konto von einer unbekannten IP, Region oder einem unbekannten Geräte-Fingerprint bei internen Anwendungen anmeldet
  • Sammlung von Zugangsdaten über E-Mail und Drive
    • Massensuchen nach Schlüsselwörtern wie API key, secret, token, password, .env
    • Zugriff auf gemeinsame Repositories für Zugangsdaten, Engineering-Runbooks und Infrastruktur-Dokumentation
    • Erstellung von E-Mail-Weiterleitungsregeln
  • Zugriff auf interne Tools über OAuth-Verbindungen
    • Sitzungserstellung oder API-Aktivität in Slack, Jira, GitHub, internen Dashboards usw. zu ungewohnten Zeiten oder von ungewohnter Infrastruktur
  • Versuche zur Privilegienerweiterung
    • Beitritt zu neuen Gruppen oder Rollen
    • Zugriff auf selten genutzte Admin-Konsolen
    • Aufrufe der Directory API in Google Workspace, Änderungen an Delegationen oder Versuche zur Auflistung von OAuth-Tokens anderer Benutzer überwachen

• Auflistung von Umgebungsvariablen, Phase 4

  • In den Audit-Logs von Vercel-Teams ungewöhnliche Massen- oder Frequenzmuster bei Aufrufen mit env read, list, decrypt-Charakter erkennen
  • Zunächst muss eine Baseline für normale CI/CD-Build-Zeitpunkte erstellt werden.
  • Danach Alarm auslösen bei Zugriffen, deren Volumen, Zeitpunkt oder Quell-Subjekt von der Baseline abweichen.
  • Besonders auf Zugriffe von Benutzerkonten statt Servicekonten achten sowie auf Konten, die normalerweise nicht mit dem Projekt interagieren.

• Missbrauch nachgelagerter Zugangsdaten, Phase 5

  • In allen Dienst-Logs für Zugangsdaten, die im Zeitraum Februar bis April 2026 als non-sensitive Vercel-Umgebungsvariablen gespeichert waren, prüfen
  • Bei AWS CloudTrail anhand der jeweiligen Access Key ID durchsuchen
  • Bei GCP und Azure die Audit-Logs anhand des Servicekontos oder der Anwendungs-ID durchsuchen
  • Bei SaaS-APIs wie Stripe, OpenAI, Anthropic, SendGrid und Twilio in Dashboard- oder API-Logs prüfen, ob Nutzung von unbekannten IPs oder zu inaktiven Zeiten erfolgte.
  • Nutzung, die sich nicht der eigenen Infrastruktur zuordnen lässt, ist sofort als kompromittierte Zugangsdaten zu behandeln; Rotation und Verhaltensanalyse sind erforderlich.

• Benachrichtigungen über offengelegte Zugangsdaten von Drittanbietern

  • Automatische Secret-Scanning-Benachrichtigungen von GitHub secret scanning partner program, AWS compromised key detection, OpenAI, Anthropic, Stripe, Google Cloud usw. müssen überwacht werden.
  • Benachrichtigungen zu Schlüsseln, die nur auf der Deployment-Plattform existierten, dürfen nicht als bloße Hygiene-Warnung behandelt werden, sondern müssen als Indikator für eine Plattform-Kompromittierung gelten.

Manuelle Verfahren für Threat Hunting

• Manuelle Suche in der Google Workspace Admin Console

  • Admin Console → Reports → Audit and Investigation → OAuth Log Events
  • Application Name = Context.ai oder Client ID = 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
  • Zeitraum: Februar 2026 bis heute
  • Wenn es Ergebnisse gibt, müssen Berechtigungen sofort entzogen und der Vorfall untersucht werden

• Überprüfung von Drittanbieter-OAuth-Apps mit weitreichenden Scopes

  • Admin Console → Security → API Controls → Third-party app access → Manage Google Services
  • Apps sortieren, bei denen App access auf Unrestricted steht
  • Prüfpunkte pro App
    • Besteht eine aktive Anbieterbeziehung?
    • Gibt es eine geschäftliche Rechtfertigung für die Scopes?
    • Datum der letzten Nutzung
  • Apps, die länger als 90 Tage nicht genutzt wurden, sollten entzogen werden

Empfehlungen zur Abwehr

• Sofortmaßnahmen, 0–48 Stunden

  • Alle Vercel-Umgebungsvariablen rotieren, die nicht als sensitive markiert sind
  • Nach der Rotation alle Umgebungen neu bereitstellen
  • Für alle Umgebungsvariablen mit Zugangsdaten, Tokens, Schlüsseln oder Secrets das sensitive-Flag aktivieren
  • Genehmigungen für OAuth-Apps in der Google Workspace- oder Microsoft Entra-Admin-Konsole auditieren
  • Zugriffe von Apps entziehen, die nicht mehr aktiv genutzt werden
  • Zugriffslogs aller Services prüfen, bei denen Zugangsdaten verwendet wurden, die seit Februar 2026 bis heute in Vercel-Umgebungsvariablen gespeichert waren

• Kurzfristige Härtung, 1–4 Wochen

  • Auf den Einsatz dedizierter Secret-Manager wie HashiCorp Vault, AWS Secrets Manager, Doppler oder Infisical umstellen
  • Laufzeitinjektion statt Speicherung in Plattform-Umgebungsvariablen verwenden
  • Wo unterstützt, langfristige Zugangsdaten durch OIDC-basierte Authentifizierung ersetzen
  • Monitoring für OAuth-Apps einführen
    • Nudge Security, Grip Security, Valence Security oder die nativen Verwaltungsfunktionen von Google Workspace
  • Automatisierung für Credential Rotation aufbauen
    • Vorgeschlagener Zyklus: 30 bis 90 Tage
  • OAuth-Genehmigungen in das Third-Party-Risk-Inventar aufnehmen, wie bei Vertragsanbietern

• Strukturelle Änderungen, 1–6 Monate

  • Eine Zero-Trust-Haltung gegenüber Umgebungsvariablen einnehmen
    • Davon ausgehen, dass alle auf Deployment-Plattformen gespeicherten Secrets bei einer Kompromittierung der Plattform offengelegt werden können
  • Scopes nach dem Prinzip der minimalen Rechte begrenzen
    • DB-Konten mit minimalen Rechten
    • API-Keys im Operationsumfang einschränken
    • Für Cloud-Zugangsdaten rollenbasierte temporäre Credentials statt langfristiger Access Keys verwenden
  • Für alle OAuth-Apps und Integrationen mit Zugriff auf das Unternehmens-Identitätssystem Sicherheitsprüfungen von Drittanbietern und regelmäßige Re-Reviews durchführen
  • PaaS-Plattformen in das SBOM-/ASPM-Inventar aufnehmen
    • Sie müssen nicht als externer Service, sondern als erstklassige Supply-Chain-Abhängigkeit behandelt werden

• Empfohlenes Monitoring

  • Die oben genannte OAuth Client ID in der Google Workspace Admin Console auditieren
  • In den Vercel-Audit-Logs auf unerwartete API-Aufrufe env.read und env.list achten
  • In CloudTrail, GCP Audit Logs und Azure Activity Logs prüfen, ob zwischen Februar und April 2026 ungewöhnliche IPs oder User Agents Zugangsdaten genutzt haben, die in Vercel env vars gespeichert waren
  • Wenn LiteLLM oder Axios im Dependency Tree vorkommen, zusätzlich die in den jeweiligen Advisories genannten IOCs überwachen
  • Bei wichtigen API-Anbietern auf Hinweise zu unbeabsichtigt offengelegten Zugangsdaten während des Expositionszeitraums achten

Regulatorische und Compliance-Auswirkungen

• Organisationen, bei denen diese Kompromittierung zu einer möglichen Offenlegung von Zugangsdaten geführt hat, müssen die folgenden Pflichten bewerten

• GDPR

  • Wenn offengelegte Zugangsdaten Zugriff auf Systeme mit EU-Personendaten ermöglichten, kann die 72-Stunden-Frist ab dem Zeitpunkt der bestätigten Offenlegung beginnen
  • Die Benachrichtigung von OpenAI am 10. April wirft die Frage auf, ob einige Organisationen bereits vor der öffentlichen Bekanntgabe am 19. April Kenntnis hatten

• CCPA/CPRA

  • Die Offenlegung von Zugangsdaten, die Zugriff auf Verbraucherdaten ermöglichen, kann Benachrichtigungspflichten auslösen

• PCI DSS

  • Bei offengelegten Zugangsdaten für Zahlungsabwicklung wie Stripe, Braintree oder Adyen können Incident-Response-Verfahren und forensische Untersuchungen erforderlich werden

• SOC 2

  • Vorfallsdokumentation, Maßnahmen zur Credential Rotation und aktualisierte Kontrollen müssen in die Nachweise für das laufende Monitoring einfließen

• SEC Cybersecurity Rules 8-K

  • Börsennotierte Unternehmen, die den Vorfall als wesentlich einstufen, haben eine Offenlegungspflicht innerhalb von vier Geschäftstagen
  • Der Artikel weist darauf hin, dass viele regulatorische Frameworks nicht eine bestätigte Ausnutzung, sondern bereits die Offenlegung selbst als Maßstab nehmen können, auch wenn noch unklar ist, ob es tatsächlich zu unbefugter Nutzung kam

Kompromittierungsindikatoren

• Bestätigte IoC

  • OAuth Client ID
    • 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
    • Wert, der mit der kompromittierten OAuth-Anwendung von Context.ai verknüpft ist

[GN⁺]

Hacker-News-Kommentare

• Das erinnert mich daran, dass Vercel, als die UI für Umgebungsvariablen erstmals eingeführt wurde, noch gar keine sensitive-Option hatte. Es hat fast über zwei Jahre gedauert, bis diese Funktion hinzugefügt wurde. Die dazugehörige Diskussion ist in einer GitHub-Diskussion und im Vercel-Changelog festgehalten

  • Selbst wenn man in der UI ein sensitive-Flag setzt, ändert das nichts an der Runtime. Sobald der Wert zur Build-Zeit in process.env landet, kann ihn jede Dependency lesen, die darauf schaut. Das eigentliche Problem ist aus meiner Sicht die Struktur, bei der alle Secrets in einen einzigen env-Beutel gepackt und dem Build-Tool komplett übergeben werden. Cloudflare trennt das mit scoped bindings bereits, Fly ebenfalls, und andere Plattformen sind hier meiner Einschätzung nach langsam
  • sensitive bedeutet wohl nicht „nicht lesbar“, sondern eher nur in der UI verborgen. Wenn eine action-Funktion oder route etwas zu viele props zurückgibt, kann das leicht nach außen dringen. Um solche Probleme wirklich zu verhindern, müsste man Umgebungswerte letztlich mit eigenen Schlüsseln verschlüsseln, und weil es keine gute Möglichkeit zur Trennung gibt, könnte man manche Secrets als Workaround sogar im Source baked-in hinterlegen. Der Angreifer müsste dann nicht nur die Umgebungswerte lesen, sondern auch das Build-Artefakt herunterladen und den Entschlüsselungsschlüssel finden, was die Hürde etwas erhöht. Ideal ist das nicht, aber als Notbehelf könnte es funktionieren

• Dass man auf diese Weise erwischt wurde, wirkt wirklich wie ein peinlicher Vorfall. Besonders irritierend ist, dass die Lumma-Stealer-Infektion laut dem zitierten Inhalt mit dem Download eines Roblox-Exploit-Skripts durch einen Context.ai-Mitarbeiter begann

• Dass der CEO öffentlich die durch AI beschleunigten Angriffstechniken für die schnelle Bewegung des Angreifers verantwortlich gemacht hat, erscheint mir ehrlich gesagt kaum belegt. Deshalb wirkt es auch so, als kämen dabei nicht viele belastbare Informationen ans Licht

  • Heutzutage scheint AI sogar schon den Markt für absurde Ausreden durcheinanderzubringen, und die Medien scheinen das ohne Prüfung zu wiederholen
  • Andererseits erinnert mich das daran, dass vibe coded Lösungen oft dazu neigten, Vercel zu empfehlen. Das wirkt auf mich ähnlich wie der frühere Hype, überall Axios zu empfehlen

• Ich habe die Erklärung zu Stage 2 nicht wirklich verstanden. Wenn die ContextAI-App Berechtigungen für Google Mail, Drive und Calendar zugleich angefordert hat, erscheint mir das deutlich zu weitgehend. Es ist kein kleines Unternehmen, daher fiel es mir schwer zu glauben, dass man zugestimmt hat, so etwas außerhalb der eigenen Umgebung laufen zu lassen. Allerdings liest es sich im Security-Update von Context.ai eher so, als habe ein einzelner Vercel-Mitarbeiter persönlich den Zugriff auf seinen gesamten Google Workspace erlaubt

• Mir ist noch immer nicht ganz klar, wie dieser Ablauf genau funktioniert hat. Ich frage mich, ob mit dem OAuth-Token hier das Token gemeint ist, das man nach Sign in with Google erhält. Normalerweise ist das doch an die client id und das client secret einer bestimmten Google-App gebunden. Selbst wenn der Angreifer das OAuth-Token des Nutzers und die Client-Informationen kennt, verstehe ich noch, wie man damit auf Drive usw. zugreifen kann, aber nicht, wie das dann zu einem Login in die control plane von Vercel führte. Am Ende wurden die Zugangsdaten also vielleicht doch in Google Drive gefunden

  • Ich habe den Eindruck, dass der Bericht diesen Teil nicht klar erklärt. Deshalb kommt mir sogar der Verdacht, dass es noch einen peinlicheren Fehler gab und man ihn verbirgt. Es könnte ein Passwort in Drive oder Gmail gewesen sein oder, wie ein anderer Kommentar vermutet, ein passwordless login link
  • Der entscheidende Punkt scheint zu sein, dass man nach Abschluss des OAuth-Prozesses letztlich ein session token bekommt und damit API-Anfragen senden kann. Wahrscheinlich hatte das ausgestellte Token auch Zugriff auf den Posteingang des Opfers, und der Angreifer konnte E-Mails lesen, um Einmalpasswörter, magic links oder andere sensible Informationen zu erhalten
  • Ich bin ebenfalls verwirrt. Ich frage mich wirklich, ob die OAuth-App von Context.ai kompromittiert wurde und der Angreifer dadurch dieselbe Sichtbarkeit auf alle Kunden-Workspaces von Context.ai bekam. Dann bleibt aber die Frage, warum sich die Verantwortung auf einen bestimmten Mitarbeiter konzentriert. Entscheidend scheint letztlich zu sein, ob dieser Vercel-Mitarbeiter Context.ai den Zugriff auf den gesamten Vercel-Workspace erlaubt hat

• Der Aussage „OAuth-Apps wie Drittanbieter-Vendoren behandeln, langfristige Plattform-Secrets abschaffen und mit provider-side compromise als Annahme entwerfen“ stimme ich grundsätzlich zu, aber ein Design unter der Prämisse einer Kompromittierung auf Anbieterseite ist wirklich schwer. Vertrauen ist schließlich der Ausgangspunkt des Systems

  • Für uns ist das als SaaS-Anbieter, der sich mit OAuth-Apps beschäftigt, ein sehr schwieriges Problem. Ich frage mich, ob es einen Marketplace gibt, der das gut löst. Cloudflare hat nach dem Salesloft-Vorfall vorgeschlagen, sämtlichen Drittanbieter-OAuth- und API-Traffic über sich selbst zu proxyn, aber das wirkt auch so, als würde man den Angriffsvektor nur verlagern. Abgesehen von Grundregeln wie minimalen Scopes, kurzen Ablaufzeiten und client secret rotation fällt mir kaum ein, was man sonst noch tun kann. Vielleicht eine Allowlist der Ausgangs-IP-Adressen pro Client
  • Wenn man solche Fälle sieht, wirkt vieles von dem, was bisher als Zero Trust verkauft wurde, im Nachhinein eher wie Marketingsprache. Wenn es wirklich security by design wäre, müsste die Möglichkeit, dass ein vorgelagerter Anbieter durch einen Supply-Chain-Angriff vollständig kompromittiert wird, von Anfang an einkalkuliert sein

• Ich glaube, solche Vorfälle werden künftig viel häufiger auftauchen. Ob Großunternehmen oder kleine Anbieter: Die Risikoschulden aus den breit angelegten Experimenten mit AI-Tools holen nun nachträglich die gesamte IT-Wirtschaft ein. Deshalb lese ich das weniger als „AI-enabled tradecraft“, sondern eher als Folge davon, dass die Unternehmensführung aus Geschwindigkeitsgründen auf breiter Front die Installation und Erprobung von AI-Tools gedrängt hat. Der eigentliche Angriff ist viel zu gewöhnlich, und fast jedes Unternehmen ohne durchsetzbare Allowlist für AI-Installationen ist dem ausgesetzt. Wenn man IT-Verantwortliche fragt, wie viele Tools wie Context lokal und als SaaS bereits installiert sind, dürfte die Zahl ziemlich hoch sein. Das Problem ist, dass diese Tools faktisch Zugriff auf fast alles bekommen und dass Sicherheitsanbieter oder ein RBAC-Ökosystem, das das wirklich kontrolliert, wohl erst in 18 bis 24 Monaten ernsthaft verfügbar sein werden. Vercel wirkt hier wie ein Kanarienvogel im Kohlebergwerk, und ich glaube nicht, dass nur Context ins Visier geraten ist. Das ist ein bekannter, aber ignorierter Angriffsvektor, bei dem nach einem Vorfall an einer Stelle weitere Fälle kaskadenartig sichtbar werden könnten. Die nächsten sechs Monate könnten besonders schwierig werden, und alle auditieren gerade ihre AI-Installationen oder sollten es tun. Angreifer werden voraussichtlich mit den Zugriffsrechten arbeiten, die sie bereits haben, bevor diese gesperrt werden. Zur Einordnung: Ich bin Security-Verantwortlicher in der Tech-Branche

  • Ich sage schon seit Jahren, dass wir noch viele seltsame Sicherheitsvorfälle in den Nachrichten sehen werden
  • Ich sehe das genauso. Es fühlt sich an, als würde gerade eine ziemlich interessante Zeit beginnen

• Wenn ich die Zusammenfassung lese, wonach „die OAuth-Vertrauensbeziehung in eine Offenlegung der gesamten Plattform überging, der CEO die Angriffsgeschwindigkeit auf AI schob und die Verzögerung zwischen Erkennung und Offenlegung ebenfalls Fragen aufwirft“, dann wirken die zentralen Fehlleistungen für mich ziemlich typisch. Es gab ein Benutzerkonto mit übermäßigen Berechtigungen, und möglicherweise noch weitere ähnliche Konten. Wahrscheinlich gab es entweder kein 2FA oder ZeroTrust oder nur in sehr begrenztem Umfang. Auch die allgemeine Security-Hygiene scheint nicht gut gewesen zu sein

  • Ich glaube, künftig wird AI die gleiche universelle Ausrede für Sicherheitsvorfälle sein wie früher die reflexhafte DDoS-Ausrede, wenn eine Website kompromittiert wurde

• Es gibt einen Punkt, den viele übersehen. Selbst wenn man bei Vercel Umgebungsvariablen rotiert, werden alte Deployments nicht automatisch ungültig, sodass frühere Deploys mit den alten Zugangsdaten weiterlaufen, bis sie neu deployt oder gelöscht werden. Selbst wenn nach der Bekanntmachung also Schlüssel ausgetauscht wurden, könnten geleakte Werte noch aktiv sein, sofern nicht alle Deployments neu ausgerollt wurden. Außerdem sollte man unbedingt die OAuth-Freigaben in Google Workspace prüfen. Unter Admin Console > Security > API Controls > Third-party app access kann gut sein, dass dort noch eine App aus einer Demo von vor zwei Jahren volle Rechte auf Mail und Drive hat

  • Aus genau diesem Grund nutzen wir mehrere Google-Konten getrennt voneinander. Viele Organisationen können sich das wegen der Kosten pro Nutzer in Google Workspace allerdings nicht leisten. Ich bin in einem früheren Job auch schon damit gescheitert, durchzusetzen, dass solche OAuth-Freigaben nicht über das Hauptkonto, sondern über ein separates Konto erteilt werden
  • Bei credential rotation gehe ich normalerweise davon aus, dass auch die Ungültigmachung der alten Zugangsdaten dazugehört. Nur neue zu erstellen und die alten aktiv zu lassen, habe ich fast nie gehört
  • Dieser Satz im Bericht hat mich ebenfalls ziemlich verwirrt. Dass alte Deployments noch alte env vars verwenden, entscheidet für sich genommen ja nicht darüber, ob diese Zugangsdaten noch gültig sind. Das wirkt eher wie eine footgun für die Verfügbarkeit als ein Problem der Vertraulichkeit. Auch der Abschnitt „Environment variable enumeration (Stage 4)“ liest sich merkwürdig. Besonders bei der Formulierung, man solle darauf achten, ob Umgebungsvariablen von einem Konto aus abgerufen werden, das kein service account ist oder normalerweise nicht mit dem Projekt interagiert, fragte ich mich, ob Leute wirklich Zugangsdaten aus Vercel-env-vars ziehen und dann in anderen Systemen verwenden
  • Preview-Deploys sind noch problematischer. Für jeden PR entsteht eines mit denselben env vars, und niemand räumt sie auf. Selbst wenn man Schlüssel rotiert und Prod neu deployt, können Hunderte von Zombie-Previews mit alten Werten übrig bleiben
  • Beim Rotieren muss man selbstverständlich auch die alten Variablen ablaufen lassen

• Einige Details in diesem Bericht, vor allem die Timeline, die 2024~2025 beginnt, wirkten auf mich wie Informationen, die anderswo nicht breit berichtet wurden. Zum Beispiel Sätze wie „Ende 2024 bis Anfang 2025 pivotierte der Angreifer von Context.ai-OAuth-Zugriff auf das Google-Workspace-Konto eines Vercel-Mitarbeiters“ oder „Anfang bis Mitte 2025 begann der Zugriff auf interne Vercel-Systeme und die Aufzählung von Kunden-Umgebungsvariablen“. Ich frage mich, woher diese Daten stammen

  • Meiner Ansicht nach sind diese Daten komplett erfunden und wahrscheinlich Halluzinationen