Angriff auf OpenCode Console trifft API-Konten
Angreifer sind über ein älteres System in OpenCode Console eingedrungen. Auf der Online-Plattform konnten Nutzer ihre API-Schlüssel für externe KI-Dienste hinterlegen. Betroffen waren nach Angaben des Unternehmens 1,4 % der Console-Nutzer.
Mit den gestohlenen Schlüsseln wurden Modelle von OpenAI, Anthropic und Google AI abgerufen. Einzelne Nutzer meldeten dadurch Kosten von mehreren hundert bis über 1.000 US-Dollar. Wie hoch der Gesamtschaden ausfällt, ist bislang nicht bekannt.
„Wir hatten eine Sicherheitsverletzung im Zusammenhang mit einem groß angelegten Destillationsangriff, der 1,4 % der OpenCode Console-Nutzer betraf“, erklärte OpenCode sinngemäß.
OpenCode vermutet hinter den Abrufen eine groß angelegte Modelldestillation. Dabei wird das Ausgabeverhalten eines Modells genutzt, um ein anderes Modell zu trainieren oder anzupassen. Ob die gestohlenen Schlüssel tatsächlich zu diesem Zweck eingesetzt wurden, ist jedoch nicht bestätigt.
Open-Source-Anwendung selbst nicht kompromittiert
Der Vorfall betrifft nach Angaben von OpenCode ausschließlich die Online-Plattform. Die Open-Source-Anwendung und das Command-Line-Tool waren nicht kompromittiert. Dort verbleiben die API-Schlüssel lokal und werden nicht an OpenCode übertragen.
„Das betrifft OpenCode Console, nicht OpenCode selbst. Diese Schlüssel erreichen uns nie“, stellte Mitgründer Dax Raad sinngemäß klar.
| Bereich | Auswirkung |
|---|---|
| OpenCode Console | API-Schlüssel von 1,4 % der Nutzer betroffen |
| Open-Source-Anwendung | Laut OpenCode nicht kompromittiert |
| Command-Line-Tool | Schlüssel verbleiben lokal |
| Angriffsdauer | 48 Stunden ununterbrochene Angriffsversuche |
| Gemeldete Einzelkosten | Mehrere hundert bis über 1.000 US-Dollar |
Welche konkrete Schwachstelle im älteren System ausgenutzt wurde, ist offen. OpenCode machte auch keine Angaben dazu, wie die Schlüssel gespeichert oder verschlüsselt waren. Aussagen über die technische Ursache wären daher derzeit Spekulation.
Anbieter sperren Schlüssel und kündigen Erstattungen an
Anthropic und Google blockierten Schlüssel, die als mutmaßlich kompromittiert eingestuft wurden. OpenAI arbeitete nach eigenen Angaben mit OpenCode zusammen, um Zugänge wiederherzustellen und missbrauchte API-Guthaben zu erstatten. OpenCode bereitet ebenfalls Erstattungen für unbefugte Belastungen vor.
| Anbieter | Reaktion |
|---|---|
| Anthropic | Mutmaßlich betroffene API-Schlüssel gesperrt |
| Mutmaßlich betroffene API-Schlüssel gesperrt | |
| OpenAI | Erstattung missbrauchter API-Guthaben angekündigt |
| OpenCode | Erstattungen für unbefugte Kosten in Arbeit |
Der Fall unterstreicht, wie schnell entwendete API-Schlüssel zu einem direkten finanziellen Schaden führen. Auch ohne Sicherheitsvorfall können fehlende Limits hohe Rechnungen verursachen, wie eine Claude-Rechnung über 17.600 US-Dollar aus Azure-Credits zeigt.
KI-Sicherheitsfilter behindern die Verteidigung
Während der 48 Stunden andauernden Angriffsversuche setzte das OpenCode-Team KI-Modelle zur Analyse des Schadcodes ein. Die Modelle unterstützten die Untersuchung zunächst, verweigerten später aber Teile der Arbeit. Der bösartige Code löste eingebaute Sicherheitsfilter aus.
Diese Schutzmechanismen sollen verhindern, dass Modelle bei Angriffen oder der Entwicklung von Schadsoftware helfen. Im laufenden Sicherheitsvorfall konnten sie jedoch nicht zuverlässig zwischen Angreifern und Verteidigern unterscheiden. Ein ähnliches Problem hatte zuvor Hugging Face beschrieben.
OpenCode erhielt anschließend Zugang zu OpenAIs Daybreak Blue. Das Programm stellt geprüften Nutzern Modelle mit reduzierten Einschränkungen für defensive Sicherheitsarbeit bereit. Nach Angaben von Raad verbesserte dies die Untersuchung des Angriffs.
Frontier-Modelle hätten sich geweigert, genau die Exploits zu analysieren, die für die Verteidigung benötigt wurden, weil deren Inhalte die Sicherheitsfilter aktivierten, erklärte David Sacks sinngemäß.
Für Sicherheitsteams entsteht daraus eine zusätzliche Anbieterabhängigkeit. Ohne gesonderte Freigabe entscheidet der Betreiber eines proprietären Modells, welche Analyse im Ernstfall möglich ist. Lokal betriebene Open-Weight-Modelle können deshalb als Rückfallebene sinnvoll sein, bringen aber eigenen Betriebs-, Prüfungs- und Absicherungsaufwand mit sich.
Konsequenzen für Unternehmen im DACH-Raum
Zentral gespeicherte API-Schlüssel in einer fremden Cloud-Konsole erweitern die Angriffsfläche. Lokale Schlüsselhaltung oder ein eigenes Secrets-Management, also eine kontrollierte Verwaltung von Zugangsdaten, reduziert dieses spezielle Risiko. Vollständige Sicherheit entsteht dadurch nicht, denn auch lokale Systeme und Entwicklerrechner müssen geschützt werden.
Je nach erreichbaren Systemen und verarbeiteten Daten können bei einem Schlüsseldiebstahl zusätzlich Dokumentations-, Melde- und Haftungsfragen nach der DSGVO entstehen. Bei internen Agentenplattformen kommen weitere Risiken hinzu, etwa durch Sicherheitslücken in MCP-Integrationen.
Praktisch sollten API-Schlüssel nur minimale Berechtigungen erhalten, getrennt nach Anwendung und Umgebung ausgegeben sowie regelmäßig ausgetauscht werden. Harte Ausgabenlimits, Quoten und Echtzeitwarnungen begrenzen den finanziellen Schaden. Kompromittierte Schlüssel müssen unmittelbar widerrufen und bei jedem betroffenen Anbieter ersetzt werden.
Der Unterschied zwischen OpenCode Console und der lokal betriebenen Anwendung ist dabei entscheidend. Nicht das Open-Source-Werkzeug selbst wurde kompromittiert, sondern ein ergänzender Cloud-Dienst. Der Vorfall zeigt damit konkret, dass Bequemlichkeit durch zentrale SaaS-Funktionen neue Abhängigkeiten und zusätzliche Sicherheitskosten schaffen kann.