OpenCode-Einbruch: Hinterlegte API-Keys offen

Das Team hinter dem Coding-Agenten OpenCode hat am 17.10.2026 einen Einbruch in seine gehostete Console gemeldet. Betroffen sind laut OpenCode rund 1,4 Prozent der Console-Nutzer, und zwar die, die dort externe Anbieter verknüpft hatten. Deren hinterlegte API-Keys für OpenAI, Anthropic und Google könnten abgeflossen sein. Alle Betroffenen seien per Mail informiert worden, wer keine bekommen habe, sei nicht betroffen.

Die Mail selbst ist knapp. Ein Nutzer hat ihren Wortlaut auf Hacker News veröffentlicht: Es habe einen unbefugten Zugriff auf ein Altsystem gegeben, das gerade abgeschaltet werden sollte. Im Workspace gespeicherte Keys von Drittanbietern "may have been exposed". Betroffene sollen die Keys beim jeweiligen Anbieter widerrufen, ersetzen und die letzte Nutzung auf fremde Aktivität prüfen.

Was bisher bekannt ist und was nicht

OpenCode bringt den Vorfall mit einem "large scale distillation attack" in Verbindung. Was damit gemeint ist, erklärt das Team nicht. Naheliegend ist, dass jemand die Keys nutzen wollte, um massenhaft Antworten großer Modelle abzugreifen und damit ein eigenes Modell zu trainieren, auf Kosten der Key-Inhaber. Das ist aber eine Deutung, keine Aussage von OpenCode. Laut OfficeChai arbeitet OpenCode mit Anthropic, OpenAI und Google an der Aufarbeitung. Weitere Details gibt es nicht, weil der Vorfall laut OpenCode noch läuft.

Offen ist damit vor allem, ob und in welchem Umfang die Keys schon missbraucht wurden, denn in der Diskussion auf Hacker News berichten einzelne Nutzer zwar von Abbuchungen, die sie nicht veranlasst haben, aber ein Zusammenhang mit dem Einbruch ist nicht belegt. Wie die Angreifer in das Altsystem kamen und wie die Keys dort gespeichert waren, hat OpenCode bisher nicht gesagt.

Wer betroffen ist

OpenCode gibt es in zwei Formen. Das Open-Source-Werkzeug läuft lokal im Terminal. Wer dort mit /connect einen eigenen Key einträgt, speichert ihn laut Dokumentation in ~/.local/share/opencode/auth.json auf dem eigenen Rechner. Daneben gibt es die gehostete Console mit getesteten Modellen und Abrechnung pro Anfrage. Dort können Owner und Admins eines Team-Workspace auch eigene Anbieter verbinden, und genau diese hinterlegten Keys sind das Problem.

Wer OpenCode nur lokal mit eigenen Keys nutzt, ist nach allem, was bekannt ist, nicht betroffen. OpenCode hat das allerdings nicht ausdrücklich gesagt, sondern nur, dass die Console betroffen ist. Wer ganz sicher gehen will, tauscht die Keys trotzdem. Das kostet ein paar Minuten.

Was du jetzt tun solltest

Wenn eine Mail von OpenCode kam oder dein Team die Console mit eigenen Anbieter-Keys genutzt hat:

Keys beim Anbieter widerrufen, nicht nur in OpenCode löschen. Ein Key, der einmal abgeflossen ist, bleibt gültig, bis er beim Anbieter gesperrt wird. Neue Keys direkt im Dashboard von OpenAI, Anthropic oder Google erzeugen, nicht über Links in Mails.
Alles umstellen, was den alten Key nutzt. CI-Jobs, Skripte, Konfigurationen anderer Werkzeuge. Wer denselben Key an mehreren Stellen hinterlegt hat, merkt das spätestens jetzt.
Nutzung der letzten Tage prüfen. In den Usage-Ansichten der Anbieter nach Modellen und Mengen suchen, die nicht zu deinem Team passen. Auffällige Kosten beim Anbieter melden, mit Verweis auf den Vorfall.
Prüfen, was am Key noch hängt. Mit einem Key lassen sich nicht nur Tokens verbrauchen. Bei Anthropic etwa sind hochgeladene Dateien laut Dokumentation für jeden Key des Workspace erreichbar, sie lassen sich auflisten und in eigenen Anfragen verwenden. Lagen dort Kundendaten, ist das ein Fall für die Datenschutzbeauftragten.

Was der Fall über hinterlegte Keys lehrt

Ein Werkzeug bietet an, die eigenen Anbieter-Keys zentral zu verwalten. Das ist bequem, und viele Teams nehmen es gern an. Der Key liegt dann aber bei einem weiteren Dienstleister, dessen Sicherheit man nicht prüfen kann. Bei OpenCode traf es ausgerechnet ein Altsystem, das schon abgeschaltet werden sollte. Die Keys lagen dort offenbar trotzdem noch.

Ein paar Gewohnheiten begrenzen den Schaden, egal bei welchem Werkzeug. Bekommt jedes Werkzeug einen eigenen Key, lässt sich genau dieser sperren, und die Nutzung ist eindeutig zuzuordnen. Ein Ausgabelimit pro Projekt oder Workspace beim Anbieter sorgt dafür, dass ein Key in falschen Händen nicht beliebig teuer wird. Und wo der Anbieter Projekte oder Workspaces trennt, bekommt das Werkzeug am besten einen eigenen, damit ein abgeflossener Key nicht an Dateien und Daten aus anderen Projekten herankommt. Wer einen Agenten ohnehin nur lokal nutzt, braucht keinen zweiten Ort, an dem der Key liegt.

Wie Coding-Agenten im Alltag sonst noch an Zugangsdaten kommen und wie man sie davon fernhält, steht in unserem Artikel KI-Tools sicher nutzen. Wenn OpenCode einen ausführlichen Bericht nachreicht, verlinken wir ihn hier.