Un dashboard de terceros te quemó las llaves de OpenAI, Anthropic y Google, y la factura llegó a tu tarjeta, no a la suya. El OpenCode Console breach no fue un hackeo de película: fue un sistema legacy olvidado, un 1,4% de usuarios expuestos y developers amaneciendo con cargos de 281, 700 y hasta más de 1.700 dólares en sus cuentas de proveedor.
Si tu producto, tu equipo o tu agencia vive de claves API, esto te toca. No porque uses OpenCode, sino porque probablemente guardas llaves maestras en algún dashboard de conveniencia y confías en que el proveedor las cuida. Spoiler: no.
Qué pasó con el OpenCode Console breach
OpenCode —el agente de coding open source, model-agnostic, que compite con Claude Code y Cursor— confirmó el 17 de octubre de 2026 que un intruso accedió a un sistema legacy de OpenCode Console, el dashboard alojado donde los equipos centralizaban claves de OpenAI, Anthropic y Google por workspace. El acceso ocurrió la noche del 16 de octubre y la exposición más temprana posible de credenciales se fijó a las 00:30 UTC del día 17, según la comunicación que la compañía envió a los usuarios.
El alcance oficial: 1,4% de los usuarios de Console con proveedor externo vinculado. Ojo con esa métrica, porque mide usuarios, no llaves, y OpenCode no ha divulgado el número absoluto de cuentas ni de credenciales comprometidas. Los atacantes usaron las llaves para lanzar peticiones facturables —lo que la compañía llamó un distillation attack— y los reportes de cargos no autorizados empezaron a llegar antes del primer email de aviso.
Anthropic y Google bloquearon las claves señaladas; Google incluso suspendió proyectos de algunos usuarios tras detectar abusive activity consistent with hijacked resources en Google Cloud. OpenAI trabajó con OpenCode para restaurar el servicio y reembolsar créditos. El cofundador Dax Raad aclaró que el vector fue el sistema legacy, no la app open source ni el CLI: en el caso del binario local, dijo, «esas claves nunca llegan a nosotros».
Qué significa: el gasto en API es superficie de ataque
Aquí está el punto que casi nadie está subrayando. Durante años tratamos el gasto en API como una línea de coste. Un número que se optimiza, se negocia, se recorta. Después de esto, hay que tratarlo como una superficie de ataque con un ROI clarísimo para el atacante: si robo tu llave, genero datos de entrenamiento con tu tarjeta y no dejo rastro en mi infraestructura. Tú pagas, yo entreno.
El modelo bring your own key de OpenCode es la razón por la que el daño fue directo al bolsillo del cliente. La capa alojada existía justamente para que los equipos no compartieran llaves a mano, y esa conveniencia es la que creó el punto único de fallo. Cualquier herramienta que guarde credenciales de proveedor en tu nombre es, por definición, un proveedor crítico. Y casi nadie la evalúa como tal.
El segundo problema es la divulgación. OpenCode dijo a los usuarios que «no podía confirmar» si las claves expuestas se usaron maliciosamente y que «a la fecha» no había evidencia de otros datos sustraídos. Ese lenguaje condicional choca de frente con los reportes de cargos en cientos de dólares que llegaron antes del aviso. Investigadores citados por LavX News cuestionan incluso si el término distillation attack describe el mecanismo del breach o solo el uso posterior de las credenciales. Traducción: nadie ha explicado cómo se obtuvo el acceso ni cuántas claves se comprometieron de verdad.
Y hay un detalle que debería helarte la sangre: según David Sacks en X, la propia investigación de OpenCode se trabó porque los modelos de frontera se negaron a analizar los exploits por sus filtros de seguridad. Los defensores jugando con las manos atadas por las mismas herramientas que los atacantes usan sin freno. Ese es el estado real del juego.
Qué hacer al respecto: blinda tus claves API robadas hoy
No esperes confirmación de nadie. Si tienes llaves de OpenAI, Anthropic o Google en cualquier dashboard de terceros, asume compromiso y actúa en este orden:
- Rota hoy, no mañana. Revoca y reemite claves en los tres dashboards. Después busca reutilización en CI secrets, archivos .env locales, configs de agentes y cualquier repo que las tenga hardcodeadas. Una llave rotada en el dashboard pero viva en un pipeline sigue siendo una llave regalada.
- Pon topes duros de gasto y alertas de presupuesto por clave y por proyecto en cada proveedor. El daño se mide en factura, y los límites son la única defensa que actúa en minutos, no en días. Una alerta de presupuesto a las 3 a.m. no te salva; un hard cap sí.
- Trata cualquier dashboard de terceros que almacene claves de proveedor como proveedor crítico. Exige SOC 2 o ISO 27001, fecha concreta de retirada de sistemas legacy y cláusula de responsabilidad por cargos fraudulentos antes de conectar llaves. Si no te lo firman, no conectas.
- Prefiere claves efímeras o con scope mínimo: por proyecto, por entorno, con caducidad. Nunca llaves maestras de organización en herramientas de conveniencia. El costo de rotar diez llaves con scope acotado es cero comparado con una factura de 1.700 dólares.
- Mete detección de anomalías de consumo al runbook de incidentes: picos nocturnos, modelos caros, volúmenes de tokens fuera de patrón. Y define por escrito quién apaga la clave y en cuánto tiempo. Si no sabes quién tiene el botón, no tienes runbook.
Un último punto que casi nadie hace: mide tu exposición real. Saca la lista de llaves activas por proveedor, cuánto consumió cada una en los últimos 30 días y cuáles no tienen tope. Esa hoja de cálculo es tu mapa de riesgo, y probablemente te va a asustar más que el breach.
El cierre
El OpenCode Console breach no es una historia sobre OpenCode. Es una historia sobre todos los que conectamos llaves de proveedor a herramientas que prometen conveniencia y no preguntamos qué pasa cuando esa conveniencia se rompe. La pregunta no es si te va a pasar, es cuántas llaves tienes hoy sin tope de gasto y sin fecha de caducidad. Cuéntame en los comentarios cuántas encontraste: apuesto a que más de una.
Preguntas frecuentes
¿El breach afectó a todos los usuarios de OpenCode? No. OpenCode reportó que el 1,4% de los usuarios de Console con proveedor externo vinculado se vieron afectados. La app open source y el CLI no fueron el vector; el acceso fue a un sistema legacy del dashboard alojado. Aun así, la compañía no divulgó el número absoluto de cuentas ni de claves comprometidas.
¿Me van a devolver el dinero de los cargos? OpenAI trabajó con OpenCode para reembolsar los créditos consumidos, y Anthropic y Google bloquearon las claves señaladas. Pero no existe un total verificado por los proveedores de cargos no autorizados, así que documenta tus consumos, abre tickets y no asumas que el reembolso llega solo.
¿Qué es un distillation attack y por qué me afecta? Es el uso de créditos ajenos para generar datos de entrenamiento a costa de la factura de otro. Te afecta porque convierte tu gasto en API en un objetivo rentable: el atacante no necesita infraestructura propia, solo tu llave. De ahí que los topes de gasto sean la defensa más importante.
¿Debo dejar de usar herramientas que guardan mis claves? No necesariamente, pero cámbiales el estatus. Exige certificaciones, fecha de retirada de sistemas legacy, cláusula de responsabilidad y, sobre todo, conecta solo claves con scope mínimo y caducidad. Si la herramienta no acepta llaves acotadas, es una señal de alerta.
Fuentes
- Hackers hit AI coding tool OpenCode, running up charges on users’ AI accounts — TechCrunch
- OpenCode hack exposes API keys amid AI distillation attacks — BleepingComputer
- OpenCode Breach Could Affect OpenAI, Anthropic and Google — Infosecurity Magazine
- OpenCode Console Breach May Have Exposed OpenAI, Anthropic, and Google API Keys — The Hacker News
- OpenCode breach let hackers burn users’ AI credits for model theft — Startup Fortune