In der Nacht zum 16. Oktober verschaffte sich ein Angreifer Zugriff auf ein veraltetes System des Unternehmens OpenCode, was nach Angaben des Unternehmens zur Offenlegung von API-Schlüsseln externer AI-Provider – OpenAI, Anthropic und Google – geführt haben könnte, die von Nutzern im Dienst OpenCode Console gespeichert wurden. Das Unternehmen teilte mit, dass 1,4 % der Console-Nutzer betroffen seien, bei denen externe Provider angebunden waren. Alle Betroffenen erhielten Benachrichtigungen mit der Aufforderung, die kompromittierten Schlüssel auf Seiten des Providers unverzüglich zu widerrufen und zu ersetzen. Die absolute Zahl der Betroffenen wurde nicht offengelegt.
Zeitlicher Ablauf und Umfang des Vorfalls
Nach Angaben von OpenCode erfolgte der unautorisierte Zugriff in der Nacht zum 16. Oktober. Am Morgen des 17. Oktober verschickte das Unternehmen an die betroffenen Nutzer eine E-Mail mit dem Betreff „Action Required: Potential provider key breach“. Am selben Tag präzisierte das Unternehmen in einem Beitrag auf X: Wer keine E-Mail erhalten habe, sei nicht betroffen.
OpenCode-Mitgründer Dax Raad betonte, dass der Vorfall konkret OpenCode Console betreffe, nicht jedoch die eigentliche OpenCode-Anwendung. Laut Dokumentation speichern die lokalen Versionen – CLI und Desktop-Anwendung – die API-Schlüssel der Provider in einer lokalen SQLite-Datenbank auf dem Rechner des Nutzers, und diese Schlüssel werden „niemals“ an die Server von OpenCode übertragen.
Console hingegen arbeitet als gehosteter Dienst: Der Nutzer fügt den Provider-Schlüssel in den Workspace ein, und das Console-Gateway fügt diesen Schlüssel den Anfragen beim Weiterleiten an den Provider hinzu, sodass Teammitglieder die Modelle nutzen, ohne den Schlüssel selbst zu sehen. Genau diese auf Seiten von Console gespeicherten Schlüssel gerieten in den Risikobereich.
Wichtiger Vorbehalt: OpenCode verwendet die Formulierung, die Schlüssel könnten offengelegt worden sein, und hat nicht bestätigt, dass ein Schlüssel tatsächlich vom Angreifer kopiert oder genutzt wurde. Das Unternehmen legte außerdem nicht offen, worin das „veraltete System“ genau bestand, auf welche Weise der Zugriff erfolgte und wie viele Schlüssel es enthielt.
Offene Fragen zum Umfang
Die Angabe von 1,4 % stammt von OpenCode selbst, und die absolute Zahl der Nutzer bleibt unbekannt. Der angegebene Rahmen des Vorfalls umfasst nur Console-Nutzer mit angebundenem externem Provider. In einer Diskussion auf GitHub behauptet jedoch ein Nutzer, sein Schlüssel sei widerrufen worden, obwohl in seinem Workspace kein einziger Drittanbieter-Provider angebunden gewesen sei. Dies ist eine einzelne, nicht verifizierte Aussage, die nichts mit diesem Vorfall zu tun haben könnte, aber die Frage nach den genauen Grenzen der Kompromittierung offenlässt.
Bezug zu Distillation und andauernden Angriffen
In der Veröffentlichung vom 17. Oktober bezeichnete OpenCode den Vorfall als „im Zusammenhang mit einem groß angelegten Distillation-Angriff stehend“. Distillation ist ein Begriff, mit dem AI-Provider Kampagnen zur massenhaften Extraktion von Modellantworten beschreiben, um konkurrierende Systeme zu trainieren. Anthropic hatte zuvor darauf hingewiesen, dass solche Kampagnen Netze aus Fake-Accounts, gestohlenen Zahlungsdaten und entwendeten API-Schlüsseln nutzen.
OpenCode nannte jedoch keinen konkreten Angreifer und erläuterte nicht, wie der Hack der Console technisch mit der mutmaßlichen Distillation-Kampagne zusammenhängt. Diese Einordnung ist daher als Version des Unternehmens zu verstehen, nicht als gesicherte Attribution.
Am 18. Oktober berichtete Raad, dass Angreifer „ununterbrochen versuchen, in die Systeme einzudringen – in den letzten 48 Stunden“, und fügte hinzu, der „Nebeneffekt sei, dass alles sicherer werde“.
Berichte über unautorisierte Ausgaben
Mehrere Sekundärquellen geben Aussagen von Nutzern über finanzielle Verluste wieder. Nach Angaben von Dealroom berichtete ein Nutzer von 281 US-Dollar unautorisierter Nutzung bei OpenAI und 168 US-Dollar bei Anthropic, ein anderer schätzte seine Verluste auf 1 700 US-Dollar. Notebookcheck zitiert Aussagen von Reddit-Nutzern über 400 US-Dollar Ausgaben bei Anthropic und rund 200 Euro bei Google. Diese Beträge sind von den Providern nicht bestätigt und bleiben Nutzerangaben.
Praktische Empfehlungen
Ein API-Schlüssel ist eine Inhaber-Berechtigung (bearer credential): Jeder, der über eine Kopie verfügt, kann kostenpflichtige Anfragen im Namen des Inhabers ausführen, bis der Provider den Schlüssel widerruft. Das Löschen des Schlüssels aus Console ist nicht gleichbedeutend mit seinem Widerruf beim Provider. Budget-Limits in Console schützen ebenfalls nicht, da Console nur Anfragen kontrolliert, die über das eigene Gateway laufen.
Für Nutzer, deren Schlüssel in Console gespeichert waren:
- Widerrufen Sie den Schlüssel im Dashboard des Providers und erstellen Sie einen neuen. Anleitungen finden Sie bei OpenAI, Anthropic und Google.
- Aktualisieren Sie alle Anwendungen und Skripte, die den alten Schlüssel verwendet haben.
- Prüfen Sie Nutzungsverlauf und Abrechnung beim Provider auf Anfragen, die nicht von Ihnen stammen, mindestens seit dem 16. Oktober. OpenCode hat nicht präzisiert, wann genau der unautorisierte Zugriff begann.
- Richten Sie Ausgabenlimits oder Benachrichtigungen auf Seiten des Providers ein und verwenden Sie für jedes Tool einen eigenen Schlüssel – das begrenzt den Schaden bei Kompromittierung eines einzelnen Schlüssels und erleichtert die Prüfung.
Wir haben bereits über Sicherheitsprobleme im Zusammenhang mit OpenAI im Kontext des Überblicks zu Cyberbedrohungen im Oktober 2026 berichtet.
Der Vorfall mit OpenCode Console verdeutlicht das konkrete Risiko einer Architektur, bei der ein Drittanbieterdienst Inhaber-Zugangsdaten im Namen des Nutzers speichert: Die Kompromittierung einer einzelnen Zwischenstelle gefährdet die Schlüssel mehrerer Provider gleichzeitig. Vorrangige Maßnahme ist jetzt die Rotation der Schlüssel auf Seiten des Providers, nicht in Console. Langfristig sollte die Praxis, API-Schlüssel an Drittdienste zu übergeben, überdacht und auf Authentifizierungsmodelle umgestellt werden, die es nicht erfordern, dass ein Vermittler Geheimnisse speichert – etwa OAuth-Flows mit begrenztem Geltungsbereich.
