Direkt zum Hauptinhalt

Vercel + Lovable Sicherheitslücken: Wie KI-Tools zum neuen Supply-Chain-Risiko für Web3 wurden

· 14 Min. Lesezeit
Dora Noda
Dora Noda
Software Engineer

In einer einzigen Woche im April 2026 kollidierten zwei scheinbar nicht zusammenhängende SaaS-Vorfälle auf eine Weise, die das Bedrohungsmodell jedes Web3-Teams zurücksetzen sollte. Vercel – die Deployment-Plattform hinter Tausenden von Wallet-Benutzeroberflächen und dApp-Frontends – gab bekannt, dass ein Angreifer über ein kompromittiertes KI-Produktivitätstool namens Context.ai in seine Umgebung eingedrungen war. Tage später wurde die Vibe-Coding-Plattform Lovable dabei ertappt, wie sie Quellcode, Datenbank-Anmeldeinformationen und KI-Chat-Verläufe von Tausenden von Projekten vor November 2025 durch einen nicht behobenen Autorisierungsfehler preisgab. Die beiden Geschichten teilen keine gemeinsame Infrastruktur. Sie teilen etwas Schlimmeres: das gleiche Schadensmuster, bei dem KI-Tools stillschweigend zu privilegierten Identitäten innerhalb der Entwickler-Toolchain wurden – und Web3 erbte das Risiko, ohne es jemals einzupreisen.

Smart-Contract-Audits, Multisig-Governance, Signierung mit Hardware-Wallets – keine dieser Verteidigungsmaßnahmen liegt auf dem Pfad, den ein Angreifer wählt, wenn er die Build-Pipeline kompromittiert, die die Benutzeroberfläche für Transaktionsgenehmigungen Ihrer Benutzer ausliefert. Der April 2026 hat diese Lücke sichtbar gemacht. Ob die Branche dies als Weckruf oder als einen weiteren hingenommenen Verlust betrachtet, hängt davon ab, wie das nächste Quartal aussieht.

Die Vercel-Context-Kette: Ein OAuth-Klick, Hunderte von Frontends​

Vercels Incident-Bericht vom 19. April 2026 liest sich wie ein Lehrbuchbeispiel für OAuth-Wildwuchs (OAuth sprawl). Der Angriff begann nicht bei Vercel. Er begann Monate zuvor, im Februar 2026, als ein Mitarbeiter von Context.ai einen Roblox-Cheat installierte, der den Lumma-Stealer enthielt und seine Google Workspace-Anmeldedaten sowie Secrets für Supabase, Datadog und Authkit verlor.

Das allein ist eine routinemäßige Geschichte von Anmeldedaten-Diebstahl. Was daraus einen organisationsübergreifenden Supply-Chain-Angriff machte, war der OAuth-Scope. Mindestens ein Vercel-Mitarbeiter hatte sich zuvor mit seinem Vercel-Enterprise-Google-Konto für die „AI Office Suite“ von Context.ai angemeldet und auf „Alles zulassen“ geklickt – was Context.ai dauerhafte, weitreichende Berechtigungen für den Google Workspace von Vercel gewährte. Als der Angreifer die OAuth-App von Context.ai übernahm, erbte er dieses Vertrauen automatisch. Von dort aus drang er in das Vercel-Workspace-Konto des Mitarbeiters vor und gelangte in Vercel-Umgebungen, in denen er nicht sensible Umgebungsvariablen auflistete und entschlüsselte.

Ein Bedrohungsakteur namens ShinyHunters bot die daraus resultierende Datenbank für 2 Millionen $ auf BreachForums zum Verkauf an. Vercel betont, dass als „sensibel“ markierte Variablen verschlüsselt und ungelesen blieben. Diese Unterscheidung ist weniger wichtig als die Frage: Wie viele Web3-Projekte, die auf Vercel deployen, haben ihre RPC-Keys, API-Token und Indexer-Secrets tatsächlich als sensibel markiert? Die Antwort lautete, nach dem Ansturm auf die Rotation von Anmeldedaten zu urteilen: nicht alle.

Die Solana-DEX Orca bestätigte, dass ihr Frontend auf Vercel läuft, und rotierte vorsorglich alle Deployment-Zugangsdaten. Der CTO von Cork Protocol forderte die Nutzer öffentlich auf, die Interaktion mit auf Vercel gehosteten DeFi-Apps zu pausieren, bis die Projekte Zeit für die Rotation hatten. Die On-Chain-Protokolle und Benutzergelder waren nicht direkt betroffen – aber der Weg von einem kompromittierten Vercel-Deployment zu einer bösartigen „approve unlimited“-Transaktion (unbegrenzte Genehmigung), die einem verbundenen Wallet präsentiert wird, führt nicht über ein Smart-Contract-Audit. Er umgeht jede Verteidigung, die Web3 aufgebaut hat.

Warum „Frontend-Sicherheit“ die Ebene ist, deren Audit Web3 vergessen hat​

Seit fünf Jahren lautet das vorherrschende Sicherheitsnarrativ im Kryptobereich: „Smart Contracts halten die Gelder, also auditiert die Smart Contracts.“ Das ergab Sinn, als DeFi noch klein war und Frontends einfache statische Seiten auf IPFS waren. Es beschreibt nicht die heutige Branche, in der Wallet-Benutzeroberflächen von Vercel, Netlify, Cloudflare Pages und AWS Amplify ausgeliefert werden; in der Signing-Payloads in JavaScript konstruiert werden, das über CDNs ankommt; und in der ein einziges bösartiges Bundle Benutzer ausrauben kann, ohne TLS zu verletzen.

Die Geschichte der Web3-Frontend-Kompromittierungen ist kurz, aber teuer genug, um daraus Schlüsse zu ziehen:

  • August 2022, Slope Wallet: Eine falsch konfigurierte Sentry-Integration übertrug stillschweigend Private-Key-Material von Slope-Mobile-Wallet-Nutzern an einen Anwendungsüberwachungsdienst. Ein Angreifer entwendete 4,1 Mio. $ aus 9.231 Wallets in etwa vier Stunden. Die „Schwachstelle“ war ein routinemäßiges Telemetrie-Tool mit zu viel Zugriff – genau das Muster des OAuth-Wildwuchses.
  • Dezember 2023, Ledger Connect Kit: Ein ehemaliger Ledger-Mitarbeiter wurde mittels Phishing um sein NPM-Session-Token gebracht, wodurch die 2FA umgangen wurde. Der Angreifer schleuste einen bösartigen Wallet-Drainer-Payload als @ledgerhq/connect-kit-Versionen 1.1.5–1.1.7 ein. Das Paket war fünf Stunden lang live, zwei Stunden lang aktiv beim Stehlen und erreichte über 100 dApp-Frontends. Ungefähr 600.000 $ wurden gestohlen – nur deshalb so wenig, weil es schnell bemerkt wurde.
  • Juli 2024, Squarespace-DNS-Hijack: Ein Migrationsfehler bei der Erstellung von Squarespace-Domainkonten ermöglichte es Angreifern, Admin-E-Mails für Domains zu registrieren, die von Google Domains ohne E-Mail-Verifizierung umgezogen waren. Die Frontends von Compound und Celer Network wurden auf Wallet-Drainer umgeleitet. Decrypt berichtete, dass über 220 DeFi-Protokolle noch Wochen danach gefährdet waren.

Jeder dieser Vorfälle weist das gleiche Schema auf: Eine Nicht-Blockchain-Ebene des Stacks – Telemetrie, Paketregister, DNS – wurde kompromittiert, und das Smart-Contract-Audit hatte dazu nichts zu sagen. Der April 2026 fügte dieser Liste zwei neue Ebenen hinzu: KI-Produktivitätstools, die als OAuth-Identitäten fungieren (Vercel), und KI-Coding-Plattformen, die Kundencode und Anmeldedaten speichern (Lovable).

Lovables BOLA-Bug: 48 Tage, 8 Millionen Nutzer und „beabsichtigtes Verhalten“​

Während Vercel seinen OAuth-Explosionsradius rekonstruierte, gab Lovable — eine mit 6,6 Mrd. $ bewertete Vibe-Coding-Plattform mit acht Millionen Nutzern — einen eigenen Vorfall bekannt. Die Schwachstelle war ein Broken Object Level Authorization (BOLA)-Fehler: Ein API-Endpunkt gab Nutzerdaten ohne Validierung der Urheberschaft preis. Ein kostenloser Account plus fünf API-Aufrufe reichten aus, um die Profile anderer Nutzer, den Quellcode von Projekten und die in diesen Quellcode eingebetteten Datenbank-Zugangsdaten auszulesen.

Der Bug wurde Berichten zufolge 48 Tage vor der Offenlegung von HackerOne-Triagern geschlossen, da die exponierten Daten unter einem „Public“-Flag standen, dessen Bedeutung Lovable später als „unklar“ einräumte. Während dieses Zeitfensters war jedes Projekt auf der Plattform von vor November 2025 erreichbar. KI-Chatverläufe, Quellcode von Kunden und die darin eingebetteten Zugangsdaten — für Datenbanken, Zahlungs-APIs und ja, auch Blockchain-RPC-Endpunkte — konnten von jedem, der bereit war, den Aufruf zu skripten, abgefragt werden.

Lovables erste Reaktion auf X — das Leugnen einer „Datenpanne“ und das Umdeuten der Exposition als „beabsichtigtes Verhalten“ — ist der Teil, der Web3-Entwickler am meisten beunruhigen sollte. Es signalisiert, dass die Betriebsannahmen von KI-Coding-Plattformen das Bedrohungsmodell, das ihre Nutzer geerbt haben, noch nicht absorbiert haben. Wenn ein Web3-Team Lovable verwendet, um ein Frontend zu entwerfen, verschwinden die während des Prototyping eingebetteten Zugangsdaten nicht. Sie bleiben in der Plattform gespeichert, indiziert, abrufbar und waren im April 2026 — für mindestens 48 Tage — für jeden mit einem kostenlosen Account zugänglich.

Der OAuth-Sprawl-Multiplikator: Warum „einfaches Key-Rotieren“ nicht ausreicht​

Beide Vorfälle lassen sich auf dieselbe Grundursache zurückführen: KI-Tools werden persistente OAuth-Berechtigungen über mehrere Apps hinweg innerhalb von Organisationen gewährt, die keine Bestandsaufnahme darüber haben, welche Berechtigungen welchen Apps gewährt wurden. Jüngste Unternehmensdaten unterstreichen das Ausmaß: 98 % der Organisationen berichten von nicht autorisierter KI-Nutzung, und das durchschnittliche Unternehmen betreibt mittlerweile mehr als 830 Anwendungen, wobei 61 % außerhalb der formellen IT-Aufsicht agieren. Wenn ein KI-Tool kompromittiert wird, wird jede ihm jemals gewidmete OAuth-Berechtigung Teil der Reichweite des Angreifers.

Die Analyse von Push Security zum Vercel-Vorfall bringt es auf den Punkt: Der Angriff war erfolgreich, weil das Identitätsmodell von Vercel eine KI-App eines Drittanbieters genauso behandelte wie einen Mitarbeiter. Es gab keine Einschränkung der Berechtigungen (Scope-down) nach dem Motto „dieses Tool darf Kalender lesen, aber keine Umgebungsvariablen auflisten“. Das ist kein Vercel-spezifisches Versagen. Es ist der Standardzustand fast jedes Google Workspace-, Microsoft 365- und Okta-Tenants, der in den letzten 18 Monaten KI-Assistenten integriert hat.

Für Web3-Teams bedeutet dies, dass das Rotieren von Schlüsseln nach einer Sicherheitsverletzung der Vercel-Klasse zwar notwendig, aber nicht ausreichend ist. Der Angriffsvektor — überprivilegierte OAuth-Berechtigungen für KI-Tools — bleibt bei jedem SaaS-Anbieter in der Lieferkette bestehen. Ein Team, das im April die Vercel-Deployment-Zugangsdaten rotiert hat, aber immer noch eine KI-App für Besprechungsnotizen mit vollem Drive-Zugriff nutzt, ist nur eine Infostealer-Infektion von demselben Ergebnis entfernt.

Wie ein wirklich verteidigtes Web3-Frontend aussieht​

Es gibt heute eine Handvoll Verteidigungsmuster, die, wenn sie kombiniert worden wären, Vorfälle der Vercel- und Lovable-Klasse neutralisiert hätten. Keine davon ist derzeit obligatorisch.

Subresource Integrity (SRI)-Hashes für Wallet-UI-Bundles. SRI ist eine W3C-Empfehlung, die es Browsern ermöglicht, zu überprüfen, ob eine abgerufene Ressource mit einem kryptografischen Hash übereinstimmt, bevor sie ausgeführt wird. Wenn ein Vercel-Deployment nach der Veröffentlichung des Integrity-Hashes geändert wird — etwa durch einen Angreifer, der in die Build-Pipeline eingedrungen ist —, verweigert der Browser das Laden. SRI existiert seit 2016 und wird trivial unterstützt. Fast keine Web3-Frontends nutzen es für ihre Haupt-Bundles, da sich diese bei jedem Deploy ändern und jemand die Hash-Rotation verwalten müsste.

On-Chain-Frontend-Manifeste. ENS-Contenthash-Einträge und IPFS-CIDs ermöglichen es einem Projekt, die Aussage „dies ist das kanonische Frontend für Protokoll X“ On-Chain zu verankern. Eine Wallet, die das Manifest vor dem Laden der Benutzeroberfläche konsultiert, kann erkennen, wenn das bereitgestellte Bundle nicht mit der veröffentlichten CID übereinstimmt. EIP-2477 untersuchte dies für Token-Metadaten, und dieselbe Idee lässt sich auf dApp-Frontends verallgemeinern. Die Akzeptanz konzentriert sich heute auf Projekte, die bereits ausschließlich über IPFS versenden — das IPFS-Deployment von Uniswap ist das offensichtliche Beispiel — und fehlt ansonsten fast überall.

Client-seitige Transaktionssimulation. Wallets wie Rabby und Wallet Guard simulieren jede Transaktion vor der Unterzeichnung und zeigen dem Nutzer die tatsächliche Asset-Bewegung an. Dies hätte die Drain-Logik des Ledger Connect Kit-Angreifers nicht am Ausführen gehindert, aber es hätte den Nutzern die Chance gegeben, zu sehen: „Dies überträgt Ihr gesamtes USDC-Guthaben an 0xunknown“, bevor sie auf Bestätigen klicken. Die Akzeptanz steigt, erfolgt aber immer noch Wallet für Wallet und nicht Protokoll für Protokoll.

Hardware-Wallet-Anzeigen nach dem Prinzip „Was du siehst, ist das, was du unterschreibst“. Geräte wie Ledger Stax und Keystone parsen Calldata und rendern die Absicht in menschenlesbarer Form auf dem Gerätedisplay, was Phishing auf der UI-Ebene vereitelt. Dies funktioniert nur, wenn für den Contract ein Clear-Signing-Schema veröffentlicht wurde. Die meisten Verträge haben dies nicht.

Das Muster bei allen vier Verteidigungsmaßnahmen: Sie existieren, sie funktionieren und sie werden standardmäßig nicht eingesetzt. Sie kosten Entwicklungszeit, die mit der Bereitstellung von Produktfeatures konkurriert, und das schlimmste Szenario, das sie verhindern — ein massiver Abfluss von Geldern —, ist bis April 2026 meist „anderen Leuten“ passiert.

Die Frage des Wendepunkts​

Web3 hat in der Vergangenheit in der Regel einen Verlust von Nutzergeldern in Höhe von über 50 Mio. $ + erfordert, um neue defensive Standardeinstellungen zu übernehmen. Audits wurden nach dem DAO-Hack von 2016 zur Grundvoraussetzung. Die Multisig-Governance entwickelte sich nach den Ronin- und Wormhole-Exploits von 2022 von einer Option zur Pflicht. Hardware-Wallets normalisierten sich nach Mt. Gox und Dutzenden von Kompromittierungen von Krypto-Börsen.

Die doppelten Sicherheitsverletzungen vom April 2026 führten zu keinem Verlust von 50 Mio. $. Der Vercel-Angreifer wurde in Umgebungsvariablen „bezahlt“, nicht in Nutzergeldern. Die Offenlegung von Lovable brachte den Quellcode ans Licht, keine signierten Transaktionen. Beides waren Warnschüsse — das Äquivalent einer Offenlegung von Schwachstellen ohne Ausnutzung, mit der Ausnahme, dass die Schwachstellen in den Vertrauensverhältnissen selbst lagen und nicht in einer behebbaren Codebasis.

Die Frage für das nächste Quartal ist, ob Web3-Entwickler die Warnung richtig einpreisen oder auf das Verlustereignis warten. Frontend-Sicherheit — SRI, On-Chain-Manifeste, Transaktionssimulation, Clear Signing — hat die gleiche Form wie Smart-Contract-Audits im Jahr 2017: technisch verfügbar, kulturell optional, aber kurz davor, als offensichtlich notwendig neu eingestuft zu werden. Der Unterschied besteht darin, dass die Kosten der Lektion von den Nutzern getragen werden, nicht von den Protokollen.

Die Teams, die zuerst handeln, werden ein Quartal an Entwicklungskosten absorbieren. Die Teams, die warten, werden alles absorbieren müssen, was der erste Drain der Vercel-Klasse über 50 Mio. $ + sie an Nutzern, regulatorischen Risiken und den Post-Mortems kosten wird, die sie monatelang schreiben werden.

BlockEden.xyz betreibt Produktions-RPC- und Indexierungs-Infrastruktur über 12 + Blockchains hinweg, mit Umgebungstrennung, Scoped API-Keys und Rotations-Tooling, die für Teams entwickelt wurden, die Frontend-Sicherheit als erstklassiges Anliegen behandeln. Bauen Sie auf einer Infrastruktur auf, die davon ausgeht, dass die Lieferkette feindselig ist.

Quellen​

Share on Twitter