OpenCode hackeado: claves de API expuestas, qué hacer ya

Si una herramienta de programación con IA guarda tus claves de API de OpenAI, Anthropic o Google, esto va contigo. El 17 de octubre de 2026, OpenCode (el popular agente de programación de código abierto para terminal de Anomaly Innovations, antes SST) envió un correo a un subconjunto de usuarios para avisarles de que un intruso había accedido a un sistema heredado que estaba retirando y podía haber expuesto claves de API de proveedores guardadas en los espacios de trabajo de los usuarios. Hay desarrolladores que informan de pérdidas de dinero reales. Esta es la versión tranquila y precisa: qué está confirmado, qué no y qué hacer exactamente.

Qué se ha informado

• Quién: OpenCode, mantenido por Anomaly Innovations (el equipo antes conocido como SST). Es un agente de programación con IA de código abierto para terminal que se usa con tus propias claves de API de proveedores, con más de 75 proveedores de modelos y sin recargo: pagas directamente al proveedor.
• Qué: Según se informa, un intruso accedió a un sistema heredado en proceso de retirada. Las claves de API de proveedores guardadas en los espacios de trabajo de los usuarios pueden haber quedado expuestas.
• Alcance (cifra de OpenCode): Descrito como un «ataque de destilación a gran escala» que afecta a ~1,4 % de los usuarios de OpenCode Console. Según se informa, OpenCode dijo que envió un correo a cada usuario afectado y que quien no recibió el correo no estaba afectado: se trataba de un subconjunto que tenía vinculados proveedores externos.
• Claves mencionadas: OpenAI, Anthropic y Google.
• Impacto real (informes de usuarios): Desarrolladores en X informan de gasto de inferencia fraudulento en claves que solo usaban en OpenCode: un hilo cita 281 $ (OpenAI) + 168 $ (Anthropic) a partir de las 2 de la madrugada, hora del Este, otro 1.700 $ y otros más de 400 $. El hilo común: otras claves que tienen esas mismas personas no se tocaron, lo que apunta directamente a las claves guardadas en OpenCode.
• Lo que OpenCode NO pudo confirmar: si las claves expuestas se usaron de verdad con fines maliciosos. (Los informes de usuarios sugieren con fuerza que algunas sí).

Actualización: lo que añaden informaciones posteriores (17–18 de octubre de 2026)

Desde los primeros avisos han surgido más detalles de investigadores y usuarios afectados. Todo ello es información atribuida, no verificada de forma independiente por nosotros, y OpenCode sigue sin publicar un post-mortem técnico:

• Cronología y una confirmación con nombre. Los primeros informes de la brecha aparecieron hacia las 22:30, hora del Este, del 17 de octubre de 2026. El investigador de seguridad Matt Johansen publicó que los clientes de OpenCode estaban recibiendo avisos de brecha mientras sus claves acumulaban cargos, y después escribió «Confirmed. OpenCode hacked. Keys stolen», instando a los clientes a revocarlas; la publicación alcanzó unas 158.000 visualizaciones.
• Qué claves se filtraron, con más precisión. Según informes de usuarios (incluido Reddit), las claves guardadas solo en local parecen seguras, mientras que las claves añadidas para proveedores externos (por ejemplo, mediante OpenCode «Zen») son las que se informa que se filtraron. Además de OpenAI y Anthropic, al menos un usuario informa de que también se vieron afectadas sus claves de Google AI. Coincide con el planteamiento anterior del «subconjunto que tenía vinculados proveedores externos».
• Pérdidas con nombre. El desarrollador Max Weinbach informa de que se vaciaron sus saldos de OpenAI y Anthropic y de que su cuenta de Google quedó limitada y parcialmente vaciada, y dice que OpenCode le envió un correo. Un usuario, Martynas, informa de que le vaciaron ~50 $ de Anthropic y ~70 $ de OpenAI en tokens de claves añadidas a OpenCode Zen; otros informan de cargos nocturnos de 65–281 $. Al menos un usuario pide un reembolso o crédito de Zen.
• Una coincidencia, explícitamente NO una causa. Un usuario señaló que OpenCode 2.0 se lanzó ~14 horas antes de sus cargos, y varios dicen que las alertas de gasto saltaron durante la noche, pero no se ha establecido ninguna relación entre el lanzamiento de la 2.0 y la brecha, y no estamos insinuando que la haya.

Nada de esto cambia la respuesta: revoca y vuelve a emitir cada clave de proveedor que hayas guardado alguna vez en OpenCode (OpenAI, Anthropic, Google y cualquier otra), en el panel de cada proveedor, y revisa las facturas de tus proveedores al menos desde el 17 de octubre.

Por qué lo llamamos compromiso de credenciales y no «ataque de destilación»

«Ataque de destilación» es la expresión que, según se informa, usó el propio correo de OpenCode, así que se la atribuimos a ellos en lugar de ponerles palabras en la boca. Pero fíjate en los hechos observables: claves de proveedores que solo existen dentro de OpenCode se están usando para ejecutar grandes volúmenes de inferencia de pago en otro lugar. Esa es la firma de manual del robo y la reutilización de credenciales o claves de API: un secreto guardado quedó expuesto y los atacantes lo están gastando como un token al portador.

La destilación de modelos (entrenar un modelo más barato con las salidas de un modelo de frontera) puede muy bien ser el objetivo final del atacante para toda esa inferencia robada (es un móvil de fraude en rápido crecimiento: robar claves y generar datos de entrenamiento a costa de otro). Pero la brecha en sí es una exposición de secretos. Empezamos por el mecanismo porque el mecanismo te dice qué hay que arreglar. Esta es nuestra lectura de las pruebas públicas, no una determinación oficial.

Puede que ya existiera una corrección para esa misma superficie, y un bot la cerró

Este es el detalle que convierte la historia en una cuestión de proceso, y no solo de brecha. El 28 de agosto de 2026, unas ocho semanas antes de la brecha, un colaborador de OpenCode abrió la pull request #45919, «fix(console): protect legacy auth with turnstile», que añadía un desafío de Cloudflare Turnstile al worker de autenticación de la consola heredada, verificaba la petición (acción, hostname, token, IP de origen) antes de que empezara el OAuth de GitHub o Google y bloqueaba que las rutas directas de los proveedores se saltaran el desafío. Alrededor de un mes después, un bot de GitHub Actions la cerró automáticamente con una regla de «Automated PR Cleanup» que indicaba los criterios: creada hace más de un mes y con menos de dos reacciones positivas. Según se informa, la brecha llegó después a través de un sistema heredado.

La lección sistémica es la que merece citarse: un bot que cierra pull requests por antigüedad y número de reacciones no tiene ni idea de qué es una «corrección de seguridad». Las reacciones miden popularidad, no riesgo, y una PR de endurecimiento discreta y poco vistosa es justo la que no recibe pulgares arriba y caduca. Automatiza el triaje de PR si no queda más remedio (la avalancha de PR generadas por IA es real), pero no dejes nunca que una regla de antigüedad cierre automáticamente una PR que toque autenticación, secretos, criptografía o control de acceso sin una revisión de seguridad humana. Etiqueta las PR de seguridad al crearlas y excluye esas etiquetas de cualquier bot de limpieza.

Reconozcamos lo que corresponde: según OpenCode, la corrección se escribió unas ocho semanas antes del incidente y, cuando ocurrió, lo detectaron rápido, lo divulgaron ellos mismos y dicen que están trabajando en ello con los tres proveedores de modelos. El fallo que queda a la vista es un pipeline incapaz de distinguir un parche de seguridad del ruido, una trampa que casi todos los repositorios con mucho movimiento se han tendido en silencio. (Algunos informes citan también que los términos de OpenCode limitan su responsabilidad y excluyen los daños causados por modelos de terceros; no pudimos cargar la página de términos para confirmar la redacción exacta, así que tómalo como no verificado).

La lección para los responsables de seguridad

Una herramienta que funciona con tu propia clave es un punto de agregación de credenciales. Reúne en un solo sistema las claves de API de modelos de frontera de cada desarrollador que la usa, así que una única brecha de ese sistema expone a la vez cientos de tokens al portador de alto valor. Es un problema de radio de impacto, y se puede conocer de antemano.

1. Una clave de API es un token al portador. Tenerla equivale a estar autorizado; sigue gastando tu dinero hasta que la rotas. Limita el daño antes de un incidente con límites de alcance por clave y topes de gasto duros. Nuestro laboratorio de ciclo de vida de claves de API recorre la emisión, el alcance, la rotación y la revocación de claves para que una filtración sea sobrevivible.
2. Inventaría dónde viven realmente las credenciales de IA de los desarrolladores: herramientas de línea de comandos, plugins del IDE, secretos de CI y «sistemas heredados en proceso de retirada» (justo lo que, según se informa, sufrió la brecha aquí). No puedes rotar lo que no has mapeado.
3. Trata la cadena de suministro de IA como cadena de suministro. Cada herramienta y cada servidor MCP que conectas puede leer o exfiltrar lo que le das. Nuestro escáner de servidores MCP maliciosos y el generador de modelos de amenazas para LLM te ayudan a razonar qué integraciones de IA tocan tus secretos y qué podrían hacer con ellos.
4. Los sistemas en proceso de retirada son un vector de brecha recurrente. Se quedan fuera del parcheo y la monitorización mientras siguen guardando datos vivos. Pon en tu runbook de retirada una puerta firme de «datos purgados antes del apagado».
5. Excluye los cambios de seguridad de la automatización de «PR obsoletas». El número de reacciones y la antigüedad son señales de popularidad, no de riesgo. Cualquier PR que toque autenticación, secretos, criptografía o control de acceso debería llevar una etiqueta que ningún bot de limpieza pueda cerrar automáticamente, porque la que acabe cerrando será la corrección que necesitabas. (Mira la sección anterior: una corrección con Turnstile para la autenticación de la consola heredada se cerró automáticamente ocho semanas antes de la brecha).

Nada de esto depende de saber quién fue el atacante ni del post-mortem final de OpenCode. La solución para un token al portador filtrado es siempre la misma: rótalo, limita su alcance, ponle un tope y vigílalo.

Mira este vídeo

En nuestro canal hay un resumen de 45 segundos del incidente de robo de claves de OpenCode y de la respuesta en seis pasos: consulta el blog de PlayCISO y nuestro YouTube para ver el short.

Fuentes y créditos

Gracias a los desarrolladores que lo hicieron público y a los medios que lo están cubriendo. Este artículo recoge su información; no origina ninguna de las cifras de OpenCode.

• Notebookcheck: OpenCode hacked, users urged to revoke their API keys
• Startup Fortune: OpenCode breach exposes stored OpenAI and Anthropic keys, prompts urgent key rotation
• Soups Ranjan en X: hilo sobre el robo de tokens de IA y el incidente de OpenCode
• Informes públicos de usuarios en X (desarrolladores que informan de claves vinculadas a OpenCode vaciadas).

Incidente en desarrollo, última actualización el 18 de octubre de 2026. Actualizaremos si OpenCode publica un post-mortem técnico oficial. Si recibiste el correo de OpenCode, sigue sus instrucciones como fuente autorizada para tu cuenta.