De OpenCode Console-breuk staat bij OpenCode (optionele hosted service) centraal: een aanvaller bereikte op 16 oktober een zogenoemd legacy-systeem en kan daarbij keys van externe AI-providers hebben blootgesteld die gebruikers in Console hadden opgeslagen. Voor wie een key via Console gebruikte, is dit vooral riskant omdat een API-key een zogeheten bearer credential is: wie de key heeft, kan er namens het account kosten mee veroorzaken.
OpenCode geeft aan dat de impact beperkt lijkt—het gaat om circa 1,4% van de Console-gebruikers—maar de gevolgen kunnen financieel en operationeel flink zijn. In dit artikel zetten we de belangrijkste feiten op een rij en wat je praktisch kunt doen.
Wat is OpenCode Console en waarom zijn API-keys zo gevoelig?
Console is een optionele hosted service van OpenCode. In een workspace kun je per team of project een eigen key van een AI-provider opslaan. Vervolgens gebruikt Console die key om calls naar de provider te doen, zodat teamleden de key niet telkens zelf hoeven te zien of te beheren.
Maar juist die opgeslagen provider key vormt een belangrijk aanvalspunt. OpenCode legt ook uit dat het bij een provider key om een bearer credential gaat: zodra iemand een kopie heeft, kan die persoon (of partij) billable requests uitvoeren totdat de provider de key revokt.
Daarbij komt een complicatie die veel teams over het hoofd zien: het verwijderen van de key uit Console revokt hem niet. Console kan bovendien een uitgavenplafond niet afdwingen voor misbruik dat niet via Console zelf loopt, omdat providerverkeer doorgaans via de provider gaat op basis van de key.
Wie is geraakt en hoe weet je dat?
OpenCode meldt dat de getroffen groep 1,4% van de Console-gebruikers betreft. Binnen die groep geldt volgens het bedrijf dat alle betrokken workspaces een externe provider gekoppeld hadden.
Volgens OpenCode zijn gebruikers op 17 oktober per e-mail geïnformeerd. In de mail stond als onderwerp: “Action Required: Potential provider key breach.” Wie die e-mail niet kreeg, zou volgens OpenCode niet zijn beïnvloed.
Verder benadrukt OpenCode—via een toelichting van medeoprichter Dax Raad—dat het gaat om Console en de opgeslagen sleutels, niet om “OpenCode itself” als geheel. In dezelfde context geeft Raad aan dat de keys “nooit” bij OpenCode zelf terechtkomen. De details over hoe precies het legacy-systeem werd bereikt of hoe groot de set keys was, noemt OpenCode niet.
Wat zegt OpenCode precies over de blootstelling?
OpenCode stelt dat keys “may have been exposed”. Dat is bewust geformuleerd: het bedrijf zegt niet dat een key daadwerkelijk is gekopieerd of gebruikt. Wel blijft de onzekerheid relevant, omdat het dreigingsmodel bij API keys simpel is: als een aanvaller ze eenmaal heeft, kan misbruik snel ontstaan.
Ook benadrukt OpenCode dat het incident doorloopt en dat het bedrijf samenwerkt met de providers (Anthropic, OpenAI en Google) om het probleem te verhelpen.
In een update van 17 oktober beschrijft OpenCode de breuk als “related to a large-scale distillation attack”. De term “distillation” wordt in AI-context gebruikt voor scenario’s waarin grote aantallen antwoorden worden verzameld om een rivaliserend model te trainen.
Waarom distillation en API-keys elkaar raken
Distillation-achtige campagnes zijn volgens verklaringen van AI-providers in het verleden gekoppeld aan het misbruiken van accounts, gestolen inloggegevens en ook geoogste of gestolen API keys. Het idee is dat een aanvaller enorme volumes aan model-antwoorden kan verzamelen om training of nabootsing mogelijk te maken.
Los daarvan zijn provider keys niet alleen bruikbaar voor trainingscampagnes. In criminele markten worden tokens en sleutels vaak doorverkocht of ingezet om rekeningen op te lopen. Dat verklaart waarom een key-breach voor veel organisaties als een direct financieel en operationeel risico voelt.
OpenCode geeft daarnaast aan dat een aanvaller volgens Raad op 18 oktober nog steeds pogingen deed om in de systemen te komen en dat er hardening plaatsvond.
Waarom “key verwijderen” niet genoeg is
Een van de meest praktische punten: het verwijderen van de key uit OpenCode Console revokt de key niet. OpenCode’s context is dat Console een gateway is voor requests, maar dat een gestolen key ook buiten Console om schade kan doen.
In dezelfde lijn geldt dat een Console-budget het misbruik niet afremt: Console “ziet” immers niet alle providercalls, omdat de providerrequests direct op basis van de key worden geautoriseerd.
Daarom verschuift de focus van “ruim je werkruimte op” naar “revoke en vervang op provider-niveau”.
Wat je nu moet doen (stappenplan)
OpenCode noemt voor sleutels die in Console zijn geplakt en vervolgens in een workspace zijn opgeslagen een aantal stappen. Dit kun je gebruiken als checklist voor je eigen incident response.
1) Revok en vervang de provider-key
- Revok de key in het dashboard van de provider.
- Maak een nieuwe key aan volgens de instructies van OpenAI, Anthropic of Google.
- Herstel daarna je Console-configuratie met de nieuwe key.
2) Werk alle toepassingen en scripts bij
Als je een oude key gebruikte in code, automation, CI/CD, notebooks of scripts, dan moet je die updates doorvoeren. Anders draait je tooling alsnog door op een verouderde key en krijg je mislukte calls of onnodige foutmeldingen.
3) Controleer provider-usage en billing
Bekijk de provider-statistieken en facturatie over een periode met als startpunt minstens 16 oktober, omdat OpenCode niet heeft aangegeven wanneer ongeautoriseerde toegang precies begon.
Als je afwijkende of niet-herkende requests ziet, behandel dat als mogelijk misbruik tot het moment waarop je de key revoket.
4) Zet spend limits, alerts en gescheiden sleutels in
OpenCode raadt aan om bij de provider spend limits of alerts in te stellen. Daarnaast: geef elk hulpmiddel (tool, service of integratie) een eigen key. Dat verkleint de impact als er één key uitlekt en maakt het eenvoudiger om het gebruik te herleiden tot de juiste bron.
Financiële signalen: wat gebruikers melden
Hoewel OpenCode zelf formeel zegt dat keys mogelijk zijn blootgesteld, zijn er via meldingen van gebruikers indicaties opgedoken van ongeautoriseerde besteding.
Dealroom rapporteerde bijvoorbeeld claims op X: bij één gebruiker zou de OpenAI-key zijn gebruikt voor $281 en de Anthropic-key voor $168. Een andere persoon zou verliezen rond $1.700 hebben genoemd.
Daarnaast noemde Notebookcheck ook Reddit-meldingen van claims met bedragen rond $400 (Anthropic) en circa €200 (Google), waarna het account of project werd opgeschort.
Let op: dit zijn claims van gebruikers, niet een officiële bevestiging van OpenCode dat in alle gevallen daadwerkelijk misbruik heeft plaatsgevonden. Maar het onderstreept wel waarom het advies om te revoken prioriteit heeft.
Vergelijkbare aanpak: incident response bij key-compromis
Als je eerder te maken kreeg met een compromis waarbij toegangssleutels of credentials een rol speelden, zul je de rode draad herkennen: revoken, rotaten, scopes beperken en herleidbaarheid verbeteren. Voor teams die willen opschalen in hun aanpak kan het helpen om ook breder te kijken naar eerdere praktijkgevallen.
Zo beschrijft onze site bijvoorbeeld een aanpak voor het omgaan met gecompromitteerde ConnectWise toegang—met nadruk op wat je direct moet doen en hoe je de impact beperkt. Hoewel de context anders is, sluit de incident-logica sterk aan op credential-compromis.
Conclusie: neem de OpenCode Console-breuk serieus, ook als je geen bewijs hebt
De OpenCode Console-breuk laat zien hoe kwetsbaar het is als AI API-keys niet alleen lokaal worden beheerd, maar ook centraal in een serviceomgeving worden opgeslagen. OpenCode geeft aan dat keys mogelijk zijn blootgesteld voor een relatief kleine groep gebruikers, maar juist bij bearer credentials kan de schade snel oplopen.
Als je een e-mail van OpenCode ontving, is de kernactie: revok de provider-key, vervang hem, update je toepassingen en controleer billing. Daarna helpt het om sleutels te scheiden en limieten en alerts in te stellen, zodat toekomstige incidenten minder schade veroorzaken.
Bron: https://thehackernews.com/2026/10/opencode-console-breach-may-have.html
