OpenCode-Datenleck: API-Keys mit Synthorai Trusted IPs schützen

Am 17. Oktober 2026 informierte OpenCode seine Nutzer über einen Einbruch in ein Altsystem hinter seinem gehosteten Dienst OpenCode Console. Dort gespeicherte Keys externer Provider seien „möglicherweise offengelegt worden“. Nutzer meldeten daraufhin Belastungen von einigen Hundert Dollar bis zu $1,700 auf ihren Konten bei OpenAI, Anthropic und Google. Ein Provider-Key ist der API-Key, den man von OpenAI oder Anthropic erhält. Wer ihn bei einem gehosteten Tool hinterlegt, damit dieses den Provider aufrufen kann, nutzt BYOK (bring your own key). Wie teuer ein gestohlener Key wird, hängt von zwei Dingen ab: von wo aus er sich nutzen lässt und wie viel er ausgeben kann, bevor eine Sperre greift.

TL;DR

• Laut OpenCode waren 1.4% der Console-Nutzer vom Einbruch betroffen. Keys im lokalen OpenCode CLI waren nicht betroffen.
• IP-Regeln und Ausgabenlimits eines Gateways erfassen nur dessen eigenen Traffic. Für einen offengelegten Provider-Key braucht es deshalb ein hartes Limit beim Provider.
• Ist „Neue IPs erst nach Freigabe zulassen“ aktiviert, lehnt Synthorai Aufrufe eines API-Keys von nicht für diesen Key freigegebenen Adressen mit HTTP 403 und ip_not_trusted ab.
• Jeder Synthorai-Key kann ein Ausgabenlimit, Limits für Requests und Tokens pro Minute sowie ein Ablaufdatum erhalten.

Was ist beim Einbruch in OpenCode Console passiert?

Laut der E-Mail von OpenCode an betroffene Nutzer hatte sich ein Unbefugter Zugang zu „einem Altsystem verschafft, das wir gerade außer Betrieb nahmen“. Dabei könnten die Provider-Keys aus den Console-Workspaces dieser Nutzer ausgelesen worden sein. Als frühestmöglichen Zeitpunkt der Offenlegung nannte OpenCode den 17. Oktober um 00:30 UTC. Der Ablauf nach Beiträgen von OpenCode und Provider-Mitarbeitern sowie Presseberichten:

Bei einem Destillationsangriff werden die Antworten eines Modells in großem Umfang gesammelt, um damit ein anderes Modell zu trainieren. Gestohlene Keys sind eine Möglichkeit, die dafür nötigen Aufrufe zu bezahlen. Wie der Einbruch mit Destillation zusammenhängt, hat OpenCode nicht erklärt. Mitgründer Dax Raad erklärte, betroffen sei „OpenCode Console, nicht OpenCode selbst“. Im lokalen CLI hinterlegte Keys würden nie an das Unternehmen übertragen. Bis zum 21. Oktober hatte OpenCode weder die Ursache noch Angaben zur Verschlüsselung der gespeicherten Keys veröffentlicht. Auch die Zahl der Konten hinter den 1.4%, eine Erstattungsregelung und ein Post-Mortem fehlten (The Hacker News, BleepingComputer).

Welche Keys wurden offengelegt, und welche Schutzmaßnahmen helfen?

Offengelegt wurden Provider-Keys. Ein gestohlener Provider-Key wird direkt beim Provider eingesetzt, nicht über das Tool, in dem er gespeichert war. Das begrenzt die Schutzmöglichkeiten eines LLM-Gateways. Ein Gateway sitzt zwischen deinem Code und den Modell-Providern und leitet Requests weiter. Es sieht und begrenzt daher nur den Traffic, der durch das Gateway läuft. Die beiden Arten von Keys müssen getrennt betrachtet werden:

Die nächsten beiden Abschnitte zu Trusted IPs und Ausgabenlimits betreffen die erste Zeile. Für die zweite Zeile ist das harte Limit bei OpenAI, Anthropic oder Google die letzte Absicherung. Der Abschnitt danach führt die entsprechenden Einstellungen auf.

Wie schützt Synthorai Plattform-Keys und BYOK-Keys?

Provider-Keys im BYOK Vault werden mit AES-256-GCM verschlüsselt gespeichert, einem etablierten Verfahren für authentifizierte Verschlüsselung. Nach dem Speichern gibt weder eine API noch ein MCP-Tool oder eine Konsolenseite den Key zurück. Die Konsole zeigt nur die letzten vier Zeichen. Das Gateway entschlüsselt einen Key ausschließlich im Arbeitsspeicher und nur für den Request, der ihn benötigt. Nur der Workspace-Inhaber kann Keys hinzufügen, rotieren oder entfernen. Die Provider-Keys, die Synthorai für seine eigenen Kapazitäten nutzt, werden genauso gespeichert. Keine Konsolenseite und keine API zeigt sie an, auch nicht die Admin-Konsole. Die Verschlüsselung schützt Kopien der Datenbank. Wird der laufende Dienst kompromittiert, kann ein Angreifer weiterhin auf Keys zugreifen, während sie genutzt werden. Deshalb bleibt das weiter unten beschriebene Provider-Limit die letzte Absicherung für BYOK-Keys.

Die API-Keys, die Synthorai dir ausstellt, werden nur als Hash gespeichert. Aus diesem Einweg-Fingerabdruck lässt sich der Key nicht zurückgewinnen. Der vollständige Key wird genau einmal beim Erstellen angezeigt. Jeder spätere Abruf über die Konsole, die Management-API oder den MCP-Server liefert nur sein Präfix. Ein Inferenz-Key kann ausschließlich Modelle aufrufen. Die Management-API akzeptiert ihn nicht. Mit einem gestohlenen Inferenz-Key lassen sich daher weder Logs noch Nutzungsdaten oder andere Keys auslesen (API keys, admin keys).

Wie stoppen Trusted IPs einen gestohlenen Key?

Trusted IPs lehnen Aufrufe eines API-Keys von allen Adressen ab, die nicht für diesen Key freigegeben sind. Wird ein Key aus einem CI-Log oder von einem Laptop kopiert und anderswo eingesetzt, liefert der Aufruf einen Fehler statt einer Antwort. Ein Inhaber oder Admin aktiviert die Funktion unter Settings › Security mit „Neue IPs erst nach Freigabe zulassen“. Der Dialog listet alle Adressen auf, von denen der jeweilige Key in den letzten sieben Tagen aufgerufen wurde. Alle sind zur Freigabe vorausgewählt. Prüfe diese Liste vor dem Bestätigen und entferne die Auswahl bei unbekannten Adressen: Wurde ein Key bereits gestohlen und benutzt, steht auch die Adresse des Angreifers darin.

Danach liefert ein Aufruf von einer neuen Adresse HTTP 403. Die hier gezeigte Adresse ist eine Beispieladresse für Dokumentationszwecke:

{
  "error": {
    "type": "permission_error",
    "code": "ip_not_trusted",
    "ip": "203.0.113.9",
    "message": "Requests from IP address 203.0.113.9 are held until this address is approved for the key. ...",
    "approve_url": "https://synthorai.io/console/settings?tab=security"
  }
}

Wer den Key erstellt hat, erhält eine E-Mail mit Adresse, Standort, Client und angefordertem Modell. Die Freigabe erfolgt nach der Anmeldung in der Konsole. Eine weitergeleitete E-Mail allein bewirkt also keine Freigabe. Freigeben lässt sich eine einzelne Adresse oder ihr /24-Netz (256 benachbarte IPv4-Adressen), falls sich die Adresse eines Clients ändert. Das Gateway ermittelt die Quelladresse anhand der Verbindung, wie sie seine eigenen Proxys sehen. Ein Client kann daher nicht durch einen eigenen X-Forwarded-For-Header eine andere Adresse vortäuschen. Diesen Header verwenden Proxys, um die ursprüngliche Client-Adresse weiterzugeben. Wir haben das mit einem gefälschten Header geprüft: Die Ablehnung nannte weiterhin die tatsächliche Adresse.

# From an address not yet approved for the key, with a forged header:
curl -s https://synthorai.io/v1/models \
  -H "Authorization: Bearer $SYNTHORAI_API_KEY" \
  -H "X-Forwarded-For: 203.0.113.9"
# The 403's "ip" field is the caller's real address, not 203.0.113.9.

Ein Key lässt sich auch mit einer festen ip_allowlist erstellen. Diese Liste gehört allerdings zu den Einstellungen des Keys: Für jedes neue Büro, jeden neuen Server und jeden neuen VPN-Ausgang muss der Key angepasst werden. Ein vergessener Eintrag bleibt freigegeben. Trusted IPs übernehmen zunächst die Adressen, von denen ein Key bereits aufgerufen wird, verlangen vor dem Vertrauen einer neuen Adresse eine Bestätigung und führen die Adressen aller Keys in einer Liste zusammen. Eine bekannte Adresse lässt sich dort mit einem Klick freigeben. Hat ein Key eine eigene Allowlist, entscheidet ausschließlich diese Liste. Verwende pro Key also nur eine der beiden Varianten.

Das Vertrauen gilt jeweils für einen Key. Serverless Functions und CI-Runner, die bei jedem Lauf eine neue Quelladresse nutzen, würden jedes Mal blockiert. Gib nicht die veröffentlichten IP-Bereiche eines gehosteten CI-Anbieters frei: Alle Kunden dieses Anbieters teilen sich diese Adressen. Jeder, der dort einen Job ausführt, käme damit durch. Leite solche Aufrufer über eine feste Ausgangsadresse, etwa einen selbst gehosteten Runner oder ein NAT-Gateway, und gib diese Adresse frei. Alternativ kannst du ihnen einen kurzlebigen Key mit niedrigem Limit geben.

Wie begrenzen Ausgabenlimits die Kosten eines gestohlenen Keys?

Jeder Synthorai-API-Key kann ein eigenes Ausgabenlimit erhalten. Wird er trotz aller Vorkehrungen gestohlen, stoppt er bei dem von dir festgelegten Betrag. In der Konsole legst du beim Erstellen eines Keys das Limit, die erlaubten Modelle und das Ablaufdatum fest:

Rate Limits pro Key und die weiteren Einstellungen unten werden über die Management-API gesetzt:

Ein Key für einen einzelnen Dienst, beschränkt auf dessen Bedarf und erstellt mit einem Admin-Key. Dieser Management-Key kann Keys erstellen und begrenzen, aber keine Modelle aufrufen:

curl https://synthorai.io/api/v1/keys \
  -H "Authorization: Bearer sk-syn-admin-..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "support-bot prod",
    "limit_usd": 50,
    "limit_reset": "daily",
    "rate_limit": {"rpm": 60, "tpm": 200000},
    "allowed_models": ["claude-haiku-5-5"],
    "expires_at": "2027-01-31T00:00:00Z"
  }'

Workspace-Inhaber können außerdem pro Mitglied ein tägliches und ein monatliches Ausgabenlimit setzen. Erreicht ein Mitglied das Monatslimit, erhält es bis zum nächsten Monat HTTP 402. Diese Limits gelten für Traffic über Synthorai. Wenn BYOK auf das Limit angerechnet wird, erfassen sie auch BYOK-Requests über das Gateway. Sie greifen aber nicht, wenn ein gestohlener Provider-Key direkt beim Provider eingesetzt wird.

Was verhindern diese Schutzmaßnahmen nicht?

Trusted IPs stoppen einen Key, der von einer neuen Adresse aus genutzt wird. Wird er von einem vertrauenswürdigen Rechner aus eingesetzt, greifen sie nicht. Genau dort finden die häufigsten Diebstähle statt: durch Schadsoftware auf einem Entwickler-Laptop, einen kompromittierten CI-Job oder einen Server, der dazu gebracht wird, Requests für einen Angreifer zu senden. In diesen Fällen begrenzen das Ausgabenlimit des Keys, seine Modellliste und eine kurze Gültigkeit den Schaden.

Über die Freigabe entscheidet ein Mensch. Ein Angreifer kann deshalb einen blockierten Request auslösen und darauf hoffen, dass er aus Gewohnheit freigegeben wird. Die Freigabeseite zeigt Adresse, Standort, Client und Modell. Gib den Aufruf nur frei, wenn diese Angaben zu einem von dir ausgelösten Aufruf passen.

Ein täglich zurückgesetztes Ausgabenlimit erlaubt einem gestohlenen Key jeden Tag Ausgaben bis zu diesem Limit, bis jemand den Missbrauch bemerkt. Kombiniere Limits daher mit Erkennung: der E-Mail für jede blockierte Adresse, den Ausgaben pro Key in der Konsole und dem Audit-Log für Key-Änderungen. Könnte ein Key offengelegt worden sein, lösche ihn in der Konsole und erstelle einen Ersatz. Um Keys vor einem Leck zu erkennen, hinterlege bei deinem Code-Host ein Secret-Scanning-Muster für das Präfix sk-syn-, etwa ein benutzerdefiniertes GitHub-Muster mit Push Protection.

Was solltest du beim Provider für einen BYOK-Key einstellen?

Gib jedem Tool einen eigenen Provider-Key in einem eigenen Projekt oder Workspace mit hartem Ausgabenlimit. So kann ein gestohlener Key höchstens das Budget dieses Projekts verbrauchen. Widerrufe einen offengelegten Key im Dashboard des Providers. Ihn aus dem Tool zu löschen, das ihn gespeichert hat, widerruft ihn nicht. Keiner der drei Provider bietet Limits für einzelne Keys. Die kleinste Einheit ist das Projekt oder der Workspace:

Ausgabenwarnungen und Budgets, die nur E-Mails versenden, stoppen keinen laufenden Angriff. Als zusätzliches Signal neben einem harten Limit sind sie dennoch sinnvoll. Auf der BYOK-Seite der Synthorai-Konsole sind die Limit-Einstellungen der Provider unter den Keys verlinkt:

Lässt sich OpenCode mit Synthorai nutzen?

Ja. Keys des lokalen OpenCode CLI bleiben auf deinem Rechner. Diese Konfiguration war vom Einbruch nicht betroffen. Mit opencode auth login https://synthorai.io meldest du OpenCode über den Browser mit einem Einmalcode an. OpenCode erhält einen eigenen API-Key, der nach 7, 30 oder 90 Tagen abläuft (Einrichtungsanleitung). Ist „Neue IPs erst nach Freigabe zulassen“ aktiviert und bestätigst du die Anmeldung aus demselben Netzwerk, wird die Anmeldeadresse automatisch für diesen Key freigegeben. Aufrufe von anderen Adressen warten auf Freigabe. Kommt die Anmeldeanfrage aus einem anderen Netzwerk als dein Browser, warnt die Bestätigungsseite. Die Adresse gilt dann erst als vertrauenswürdig, wenn ihr erster Aufruf freigegeben wurde. Hast du den Befehl nicht selbst ausgeführt, brich die Anfrage ab.

Der Key erscheint auf der Seite für API-Keys als „OpenCode“. Dort kannst du ein Ausgabenlimit ergänzen oder ihn löschen. Ein Key auf einem Laptop kann weiterhin durch Schadsoftware auf diesem Laptop gestohlen werden. Wähle deshalb eine Gültigkeit von 7 oder 30 Tagen und lasse „Neue IPs erst nach Freigabe zulassen“ aktiviert: Ein kopierter Key funktioniert dann von keiner anderen Adresse aus und läuft bald darauf ab.

FAQ

Wurden beim Einbruch Keys aus dem OpenCode CLI offengelegt?

Nein. Laut OpenCode war der Einbruch auf OpenCode Console beschränkt. Keys, die im lokalen CLI oder in der Desktop-App hinterlegt werden, bleiben auf dem Rechner des Nutzers und werden nie an OpenCode gesendet.

Wird ein Provider-Key widerrufen, wenn ich ihn aus einem gehosteten Tool lösche?

Nein. Das Löschen entfernt nur die Kopie des Tools. Der Key funktioniert beim Provider weiter, bis du ihn im Dashboard des Providers widerrufst und einen neuen erstellst.

Schützt das Ausgabenlimit eines Gateways einen offengelegten Provider-Key?

Nein. Die Limits eines Gateways zählen nur Requests, die durch das Gateway laufen. Ein gestohlener Provider-Key wird direkt beim Provider eingesetzt. Deshalb greift hier nur das Ausgabenlimit des Providers.

Weiterführend: Trusted IPs, BYOK Vault, Admin-Keys und Key-Limits, OpenCode einrichten.

Quellenstand 21. Oktober 2026: Beiträge und E-Mails von OpenCode, wie in der Presse zitiert, Beiträge von Provider-Mitarbeitern und die oben verlinkte Provider-Dokumentation. Der Test mit gefälschtem Header wurde am 21. Oktober 2026 am produktiven Synthorai-Gateway durchgeführt.

← Zurück zum Blog