Los incidentes de Railway, Zeabur, LiteLLM, OpenCode, Fireworks AI y OVHcloud muestran diferentes maneras de comprometer servicios que almacenan credenciales, administran infraestructura o distribuyen software. Los informes forenses revelan intrusiones que comenzaron antes de su divulgación pública, accesos capaces de extenderse a terceros y fallas en los controles de seguridad. No existe evidencia suficiente para atribuir los seis casos a una campaña coordinada.
El 21 de octubre de 2026, los desarrolladores que descargaron determinadas versiones de LiteLLM pudieron recibir programas maliciosos desde los canales oficiales de distribución del proyecto. Durante aproximadamente dos horas, el paquete litellm==1.107.0 permaneció disponible en el repositorio PyPI, mientras imágenes de contenedores comprometidas también circularon por Docker Hub y GitHub Container Registry. La distribución se realizó mediante mecanismos legítimos, pero el software había sido construido a partir de un repositorio controlado por un atacante.
La intrusión no comenzó ese día. Según el informe forense publicado por LiteLLM el 23 de octubre, los responsables habían obtenido acceso privilegiado a su organización de GitHub desde el 10 de octubre, utilizando una credencial derivada de una clave maestra expuesta accidentalmente casi cinco meses antes. Durante ese intervalo consiguieron obtener más credenciales, modificar procesos de automatización y preparar la distribución maliciosa que finalmente ocurrió el día 21.
Las características más relevantes de los incidentes tecnológicos investigados durante octubre fueron: la posibilidad de utilizar el acceso legítimo de una organización para alcanzar recursos que dependen de ella. En ocasiones, el objetivo no es únicamente robar información de la empresa inicialmente comprometida, sino obtener permisos para operar servicios externos o introducir programas maliciosos en los equipos de otros usuarios.
Una revisión de los comunicados e informes técnicos de seis proveedores realizada por EstadoRed identifica dos mecanismos recurrentes: el acceso no autorizado a depósitos de credenciales y el compromiso de canales confiables de distribución de software. Aunque los incidentes presentan características diferentes y no existe evidencia pública suficiente para relacionar a sus responsables, todos permiten examinar las consecuencias de concentrar accesos y funciones operativas en intermediarios tecnológicos.
LiteLLM: una credencial olvidada permitió comprometer la distribución de software
El informe publicado por LiteLLM el 23 de octubre corrigió una explicación inicial que sugería que los atacantes habían obtenido credenciales mediante registros de una instalación interna de la propia herramienta. La reconstrucción posterior identificó un origen diferente.
El 27 de mayo, una configuración publicada accidentalmente en el repositorio LiteLLM-Labs/lite-harness contenía la clave maestra de LiteLLM Agent Platform, un proyecto experimental utilizado para coordinar agentes capaces de trabajar con repositorios de GitHub. El error fue identificado rápidamente y el cambio dejó de estar disponible en la versión pública del repositorio, pero la clave comprometida no fue revocada.
El 10 de octubre, un atacante utilizó esa credencial para consultar la plataforma de agentes y recuperar un token de GitHub asociado con una cuenta propietaria de la organización. La configuración permitía al agente realizar operaciones sobre repositorios y, por ello, incluía credenciales con privilegios elevados. Una vez obtenido ese acceso, el intruso ejecutó procesos de automatización que extrajeron otras dos credenciales pertenecientes a desarrolladores.
Los registros reconstruidos por LiteLLM muestran que el atacante utilizó posteriormente las diferentes identidades para modificar el procedimiento de publicación, aprobar una versión y eliminar evidencias de algunas ejecuciones. El 21 de octubre, cambió el origen del código que procesaba el sistema de distribución y consiguió que los mecanismos oficiales construyeran una versión procedente de un repositorio que imitaba al legítimo.
La distinción es importante: el código fuente del repositorio oficial de LiteLLM no contenía los archivos maliciosos distribuidos a los usuarios. La modificación se encontraba en la ruta utilizada para construir los paquetes y contenedores.
El 23 de octubre, Microsoft Security Research publicó un análisis independiente de los programas distribuidos. Sus investigadores identificaron mecanismos que permitían ejecutar código malicioso durante el inicio del intérprete de Python, sin necesidad de que una aplicación importara directamente LiteLLM. El software buscaba información de autenticación relacionada con herramientas de desarrollo, servicios de nube, aplicaciones de IA, navegadores y otros componentes del sistema.
Microsoft también documentó actividad compatible con la recopilación y transmisión de credenciales en equipos observados. Esto proporciona evidencia adicional sobre el funcionamiento de los programas maliciosos, aunque no determina cuántas instalaciones o usuarios resultaron comprometidos en todo el mundo.
LiteLLM retiró las versiones afectadas y comenzó a sustituir credenciales internas. Su investigación muestra que las protecciones de los repositorios y los controles de aprobación no bastaron para impedir el ataque cuando el intruso disponía de una credencial con privilegios de propietario.
Railway: cerca de 100,000 espacios de trabajo potencialmente expuestos
Otro incidente afectó a Railway, una plataforma utilizada para construir y alojar aplicaciones. Según su informe preliminar del 22 de octubre, la actividad sospechosa comenzó a detectarse el 20 de octubre a las 13:58 UTC, cuando sus sistemas de monitoreo registraron anomalías de rendimiento. Durante las horas posteriores, los ingenieros identificaron intentos de escalamiento de privilegios y comenzaron a restringir componentes de la infraestructura.
Los atacantes consiguieron acceder a sistemas internos y recuperar información cifrada de variables de entorno de clientes. Posteriormente, mediante otras credenciales comprometidas, pudieron descifrar una parte de esos datos. Estas variables pueden contener claves API, contraseñas de bases de datos y permisos utilizados por las aplicaciones para conectarse con servicios externos.
Railway estimó que, como máximo, el 1.85% de sus espacios de trabajo presentaba variables de entorno potencialmente comprometidas, equivalentes a unos 100,000 espacios de trabajo. La cifra representa una estimación máxima de unidades potencialmente expuestas, no 100,000 usuarios confirmados como víctimas de robo de credenciales. La compañía explicó que sus registros no permitían determinar con precisión cuáles de todas las claves almacenadas habían sido descifradas.
La respuesta tuvo consecuencias más amplias que ese conjunto de espacios de trabajo. Railway informó que solicitó preventivamente la revocación de credenciales a empresas como GitHub, GitLab, Anthropic, OpenAI, OpenRouter y otros proveedores. En algunos casos compartió listas de claves almacenadas en la plataforma, aunque no existiera confirmación de que todas hubieran sido comprometidas. Como resultado, más usuarios experimentaron revocaciones preventivas que aquellos incluidos en la estimación inicial de posible exposición.
Para contener el ataque, Railway suspendió temporalmente la creación de nuevas versiones y despliegues de aplicaciones, pero señaló que los servicios de clientes que ya estaban ejecutándose permanecieron disponibles.
La empresa también presentó una hipótesis sobre el objetivo de los atacantes. Según su investigación preliminar, buscaban claves de proveedores de inteligencia artificial para realizar ataques de extracción de modelos mediante consultas masivas, una práctica conocida como distillation. Railway señaló además indicios de que el atacante disponía de modelos modificados para reducir sus restricciones de seguridad y de importantes recursos de cómputo.
Estas afirmaciones proceden de la evaluación inicial de Railway. La compañía no presentó públicamente una atribución definitiva del ataque ni documentación suficiente para identificar a los responsables o relacionarlos con los incidentes de otros proveedores.
Zeabur: millones de registros expuestos y una empresa que anuncia su cierre
El caso de Zeabur permite observar un alcance diferente. Entre el 14 y el 15 de octubre, atacantes utilizaron credenciales internas para acceder a clústeres compartidos, servidores dedicados y componentes administrativos de la plataforma. El informe preliminar de Zeabur, publicado el 19 de octubre, distingue entre datos cuya lectura pudo confirmarse mediante registros y otros recursos cuya exposición continúa bajo evaluación.
La compañía confirmó la lectura de 3,218,965 registros de variables de entorno almacenadas en su base de datos, además de información correspondiente a 321,810 cuentas. Entre los sistemas examinados identificó también accesos confirmados a 101 servidores dedicados de Google Cloud pertenecientes a 92 usuarios. Estas magnitudes corresponden a diferentes unidades de observación: registros de configuración, cuentas y servidores. No deben sumarse ni interpretarse como un número único de personas afectadas.
El informe también reconoce que una clave privada de la aplicación de Zeabur para GitHub estuvo disponible para el atacante durante varias horas. Esa credencial permitía, potencialmente, acceder a repositorios que los clientes habían autorizado a la plataforma a utilizar. Sin embargo, Zeabur informó que no había detectado un uso efectivo de esa clave para acceder a dichos repositorios durante el incidente de octubre.
Una de las particularidades del caso es su relación con una intrusión anterior. Zeabur había sufrido otro incidente en agosto de 2026 y, durante la respuesta, no sustituyó todas las credenciales que posteriormente fueron utilizadas en octubre. Entre ellas se encontraban claves de administración almacenadas sin protección suficiente y un token con permisos sobre los clústeres compartidos.
La compañía reconoció que su declaración anterior, según la cual había revocado o sustituido todas las claves administrativas internas afectadas, era incompleta. También identificó una posible relación entre las credenciales expuestas durante agosto y los mecanismos utilizados en octubre, aunque aclaró que la información forense disponible todavía no demostraba de manera concluyente esa ruta de acceso.
Existe además un indicio de posibles consecuencias fuera de Zeabur. La empresa documentó que el 16 de octubre una clave API de OpenAI almacenada por uno de sus usuarios fue utilizada para aproximadamente 1,107 solicitudes de generación de imágenes. Zeabur considera posible que la credencial procediera de las variables de entorno filtradas, pero no ha demostrado esa relación y reconoce que podrían existir otras vías de exposición.
El 17 de octubre, Yuanlin Lin, fundador de Zeabur, anunció el cierre progresivo de la plataforma. Según su comunicado, algunos servicios comenzarán a detenerse el 1 de diciembre y todos los servidores dedicados y clústeres compartidos dejarán de operar antes de finalizar el año.
Lin explicó que la decisión respondió a una combinación de dificultades operativas, complejidad acumulada de la arquitectura, cambios en el mercado y las consecuencias de los dos incidentes de seguridad. Por tanto, no sería preciso atribuir exclusivamente el cierre al ataque de octubre.
Este caso introduce una consecuencia adicional del riesgo de dependencia: cuando un proveedor deja de operar, sus clientes no solo deben recuperar credenciales y proteger información, sino también trasladar aplicaciones, servidores, bases de datos y procesos a otras infraestructuras.
Fireworks AI: las variables de evaluación como depósito de accesos
Un incidente anterior afectó a Fireworks AI, proveedor de infraestructura para ejecutar modelos de inteligencia artificial. La compañía informó oficialmente que el 6 de octubre detectó el uso no autorizado de credenciales internas y el acceso de un tercero a variables de entorno asociadas con trabajos de evaluación de un número limitado de cuentas de clientes.
Las variables incluían información de autenticación, como claves API y tokens. Fireworks comenzó las medidas de contención el mismo día y notificó a los clientes identificados entre el 7 y el 9 de octubre. Posteriormente revocó credenciales adicionales mientras continuaba examinando el alcance del incidente.
La empresa indicó que, hasta la última actualización pública consultada, no había encontrado evidencia de accesos no autorizados a modelos de clientes, conjuntos de datos, información de entrenamiento, datos personales ni tráfico de inferencia bajo su control. Esta limitación importa porque impide presentar el incidente como un robo confirmado de modelos o información de entrenamiento.
El caso ilustra que los secretos empleados durante trabajos auxiliares, como pruebas y evaluaciones, también pueden representar una superficie de exposición. Aunque no formen parte del funcionamiento principal de una aplicación, las credenciales utilizadas para esas tareas pueden mantener permisos válidos sobre servicios externos.
OpenCode: una intrusión con consecuencias en cuentas de modelos de IA
El 17 de octubre, OpenCode comunicó un incidente que, según la propia empresa, afectó al 1.4% de los usuarios de OpenCode Console que habían vinculado proveedores externos de modelos. El equipo notificó a los usuarios afectados y explicó que trabajaba con Anthropic, OpenAI y Google para atender el problema.
De acuerdo con una investigación publicada por TechCrunch el 19 de octubre, algunos usuarios comenzaron a recibir alertas por consumo no autorizado de sus cuentas de IA después de la exposición de claves almacenadas en Console. El medio también recogió declaraciones de Dax Raad, cofundador de OpenCode, quien precisó que el problema afectaba al servicio Console y no a la aplicación de código abierto utilizada localmente por los desarrolladores.
La distinción es fundamental. OpenCode Console podía almacenar claves proporcionadas por usuarios para conectar servicios de terceros. Por ello, un incidente contra la infraestructura que administraba esas claves podía afectar el consumo y la facturación de los proveedores correspondientes sin que los atacantes hubieran comprometido directamente los sistemas de OpenAI, Anthropic o Google.
Según TechCrunch, OpenAI colaboró en la restauración del acceso de clientes afectados y en el reembolso de créditos consumidos durante el ataque.
OpenCode describió el incidente como relacionado con una operación de extracción de modelos a gran escala. Sin embargo, la empresa no publicó una explicación técnica completa que permita comprobar independientemente cómo se relacionaban la intrusión inicial, la exposición de credenciales y el supuesto proceso de extracción. Por ahora, la evidencia permite confirmar una brecha en Console y sus consecuencias sobre determinadas credenciales de usuarios, pero no atribuirla a los mismos responsables del ataque contra Railway.
OVHcloud: software malicioso distribuido desde un repositorio oficial
El sexto caso corresponde a OVHcloud, cuya herramienta de línea de comandos permite administrar recursos de infraestructura mediante instrucciones automatizadas. El 19 de octubre, un atacante utilizó credenciales comprometidas de un desarrollador para sustituir los archivos ejecutables de cinco versiones de OVHcloud CLI por programas modificados.
Según el aviso técnico publicado por la empresa el 20 de octubre, los archivos maliciosos permanecieron disponibles durante una hora y 33 minutos y registraron aproximadamente 250 descargas. No existe evidencia pública suficiente para afirmar que todas las descargas terminaron en ejecuciones o compromisos de equipos.
OVHcloud determinó que los programas buscaban recopilar información de distintas herramientas utilizadas por desarrolladores, incluidas configuraciones de servicios de nube, claves SSH, credenciales de Docker, Kubernetes y otras plataformas. También examinaban archivos locales de herramientas de asistencia con IA, como Cursor, Claude y OpenCode.
Este último dato describe los objetivos de recopilación del software malicioso, pero no constituye una prueba de conexión operativa con la intrusión sufrida por OpenCode Console días antes.
La investigación retrospectiva de OVHcloud identificó antecedentes de compromiso de la cuenta del desarrollador desde octubre de 2025, cuando instaló una extensión maliciosa en su computadora personal. La empresa encontró indicadores asociados con la campaña GlassWorm y evidencias de actividad posterior en repositorios personales durante marzo de 2026. Sin embargo, no estableció que todos los acontecimientos correspondieran necesariamente a un mismo operador.
OVHcloud aclaró que sus sistemas internos principales de distribución y la cadena de compilación de producción no fueron comprometidos. El ataque afectó a los archivos publicados en el repositorio público del proyecto, no a toda la infraestructura de la compañía.
El incidente muestra cómo una cuenta individual puede convertirse en una vía de distribución de programas maliciosos cuando conserva permisos para modificar archivos que los usuarios consideran legítimos.
El problema común: credenciales, permisos y relaciones de dependencia
Los seis casos no presentan un mecanismo de intrusión idéntico. En Fireworks, Railway y Zeabur, los ataques involucraron sistemas que almacenaban credenciales o información necesaria para operar servicios externos. En LiteLLM y OVHcloud, las credenciales comprometidas permitieron alterar programas distribuidos mediante canales legítimos. OpenCode Console, por su parte, expuso el riesgo de administrar claves que los usuarios proporcionan para consumir modelos de diferentes empresas.
La relación entre estos acontecimientos es funcional, no necesariamente operativa. En todos ellos, los proveedores ocupaban una posición intermedia entre personas, aplicaciones y otros servicios tecnológicos. Esa posición les permitía administrar permisos que sus usuarios necesitaban, pero también concentraba recursos que podían resultar valiosos para un atacante.
Una clave API puede representar la autorización para consumir servicios de IA, acceder a una base de datos o administrar infraestructura. Un token de GitHub puede permitir modificar repositorios o ejecutar procesos de automatización. Una cuenta con permisos sobre sistemas de distribución puede facilitar la publicación de software que otros usuarios instalarán confiando en su procedencia.
La exposición de uno de estos accesos no garantiza que el atacante consiga utilizarlo. Su capacidad depende de los permisos concedidos, la vigencia de las credenciales, los controles adicionales y la respuesta de las organizaciones afectadas. Sin embargo, los incidentes muestran que el compromiso de un intermediario puede abrir rutas de acceso hacia recursos administrados por terceros.
El caso de LiteLLM es especialmente ilustrativo. Una clave maestra publicada accidentalmente no bastaba por sí sola para distribuir programas maliciosos. El atacante tuvo que utilizarla para obtener una credencial privilegiada, aprovechar los permisos de GitHub, extraer nuevos tokens y manipular los mecanismos de publicación. Cada etapa dependió de autorizaciones que ya existían en la infraestructura.
En Railway, la arquitectura permitió limitar el alcance potencial del incidente, pero la incertidumbre sobre las credenciales descifradas obligó a coordinar revocaciones preventivas con otros proveedores. En Zeabur, la persistencia de credenciales administrativas sin sustituir después de un incidente anterior facilitó nuevas rutas de acceso.
Estos casos indican que la seguridad de un sistema no depende únicamente de corregir vulnerabilidades en su código. También exige controlar qué credenciales almacena, qué permisos concede, durante cuánto tiempo siguen siendo válidos y qué otros sistemas pueden alcanzarse mediante ellos.
¿Ataques independientes o una campaña contra proveedores de IA?
Existen coincidencias que justifican continuar investigando. Railway y OpenCode relacionaron sus incidentes con intentos de obtener recursos para la extracción de modelos de inteligencia artificial. LiteLLM identificó entre los objetivos del atacante credenciales de proveedores de inferencia. Fireworks, Zeabur y otros servicios afectados almacenaban claves que podían permitir el acceso a infraestructura externa.
Sin embargo, los informes públicos no demuestran que las seis intrusiones fueran coordinadas. OVHcloud identificó indicadores relacionados con GlassWorm, mientras que LiteLLM reconstruyó una ruta específica de compromiso de credenciales y distribución de software. Railway todavía investiga las herramientas utilizadas por sus atacantes, y OpenCode no ha publicado suficientes detalles forenses para establecer una conexión.
La coincidencia de objetivos tampoco implica identidad de responsables. Las claves de servicios de IA, las credenciales de nube y los permisos de repositorios son recursos valiosos para múltiples clases de atacantes. Su presencia en diferentes incidentes puede responder tanto a operaciones relacionadas como a estrategias independientes.
Lo que sí demuestra la documentación es que algunos ataques comenzaron mucho antes de que sus consecuencias se hicieran públicas. En LiteLLM, la credencial inicial estuvo expuesta desde mayo y la intrusión privilegiada comenzó el 10 de octubre. En OVHcloud, los antecedentes identificados se remontan a 2025. Zeabur reconoció deficiencias que persistieron después del incidente de agosto. Estas cronologías contradicen la idea de que todos los compromisos surgieron repentinamente durante la tercera semana de octubre.
La arquitectura del riesgo digital
Los incidentes investigados permiten plantear una cuestión que va más allá de los proveedores afectados. A medida que las aplicaciones dependen de servicios externos para almacenar información, ejecutar modelos, desplegar infraestructura y distribuir código, también aumenta la importancia de las relaciones de confianza que permiten conectar esos componentes.
La concentración de credenciales y permisos puede reducir la complejidad operativa para los desarrolladores, pero también convierte a ciertos intermediarios en puntos relevantes de exposición. Su compromiso puede afectar a usuarios, aplicaciones y proveedores que no participaron directamente en la intrusión inicial.
Esto no significa que todas las plataformas tecnológicas representen el mismo riesgo ni que una dependencia compartida produzca automáticamente una falla sistémica. Su impacto debe evaluarse según los privilegios comprometidos, los recursos realmente accesibles y las posibilidades de contener o sustituir los servicios afectados.
Los acontecimientos de octubre muestran por qué esa evaluación resulta necesaria. Algunos proveedores pudieron contener sus incidentes y restablecer operaciones; otros distribuyeron programas maliciosos antes de detectar el compromiso; y uno de ellos, Zeabur, decidió abandonar progresivamente el mercado después de enfrentar dos incidentes y revisar sus capacidades operativas.
La investigación de EstadoRed no encuentra, hasta ahora, evidencia suficiente para describir todos estos acontecimientos como una campaña coordinada. Sin embargo, sí identifica diferentes rutas mediante las cuales una credencial comprometida o un proveedor vulnerado pueden afectar recursos de terceros.
La pregunta que deja abierta esta segunda entrega de «Octubre Negro» es si la concentración de incidentes contra proveedores representa un incremento excepcional durante 2026 o forma parte de un fenómeno anterior que ahora resulta más visible.
Para responderla será necesario comparar la frecuencia de compromisos confirmados, sus fechas de primera intrusión y los tipos de sistemas afectados durante periodos equivalentes de años anteriores. Lo que ya puede observarse es que las consecuencias de una intrusión no dependen únicamente del sistema donde comienza el ataque, sino de los permisos y las relaciones tecnológicas que ese sistema concentra.
