Incidente de seguridad de Zeabur de octubre de 2026 (informe preliminar)

Todas las horas de este artículo se expresan en tiempo universal coordinado (UTC). La investigación sigue en curso y este artículo se actualizará a medida que avance.

Resumen

• Qué ocurrió: entre el 14 y el 15 de octubre de 2026, un atacante utilizó credenciales internas de Zeabur filtradas para comprometer los clústeres compartidos, parte de los servidores dedicados y sistemas internos de Zeabur, y finalmente leyó la base de datos de la plataforma.
• Puntos de entrada cerrados: se han revocado o eliminado el token de administración del clúster, las claves de AWS y GCP y el nodo de la red interna que utilizó el atacante, y se ha bloqueado el acceso desde Internet a las interfaces de administración y al SSH de los servidores. Se ha cerrado la sesión de todos los usuarios y se han revocado todos los tokens de acceso a la plataforma. Según los registros actuales, la última actividad del atacante fue el 15 de octubre a las 21:05.
• A quién afecta: principalmente a los servicios en clústeres compartidos y a los servidores dedicados de GCP. También se leyeron las variables de entorno almacenadas en la base de datos de la plataforma Zeabur; en los proyectos que, siguiendo nuestras indicaciones, migraron después de agosto sus variables de entorno a su propio servidor dedicado, esas variables quedan fuera del alcance de la lectura de la base de datos de la plataforma.
• Qué tienes que hacer: los datos filtrados todavía pueden utilizarse. Sustituye todas las contraseñas y claves almacenadas en Zeabur, aunque ya las hayas cambiado después del incidente de agosto. Los pasos están en Qué tienes que hacer.
• Causa raíz: la causa raíz de este incidente está en Zeabur: se guardaban credenciales de administración de larga duración en texto plano, y podían utilizarse desde Internet. Más detalles en Por qué ocurrió.
• Relación con el incidente de agosto: la rotación de agosto no cubrió las credenciales utilizadas esta vez; los proyectos que migraron sus variables de entorno siguiendo las indicaciones de agosto evitaron la filtración de la base de datos de la plataforma. Más detalles en Relación con el incidente de agosto.

Terminología de este artículo: «Confirmado» significa que hay un registro directo; «Evaluado» significa que coinciden la fecha y el contenido, pero falta un registro directo; «No se puede confirmar» significa que no hay registros que consultar, y en esos casos lo tratamos siempre como filtrado; «Hipótesis» significa una posible explicación respaldada solo por pruebas indirectas, y se recogen todas en Hipótesis no demostradas.

Qué ocurrió

El atacante siguió dos rutas, que finalmente convergieron en la red interna de Zeabur.

Ruta A: clústeres compartidos y AWS

1. Desde el 14 de octubre a las 01:36, el atacante utilizó claves de AWS internas de Zeabur y, desde las 01:40, el token de administración de los clústeres compartidos. Estas credenciales se guardaban en texto plano en un repositorio de configuración privado de Zeabur. Cómo las obtuvo el atacante no se puede confirmar por ahora; nuestra hipótesis es que guarda relación con la clave privada de la GitHub App filtrada en el incidente de agosto, véase Hipótesis no demostradas.
2. La interfaz de administración de los clústeres compartidos estaba entonces abierta a Internet, y el token de administración no caducaba. Por eso el atacante pudo acceder desde fuera a los clústeres compartidos de 9 regiones.
3. Desde las 01:51, el atacante leyó parte de los secretos del sistema. Desde las 12:39, el alcance se amplió a la configuración y los secretos de todos los servicios, incluidas las variables de entorno. En las regiones con registros de lectura completos se ha confirmado que se leyó el contenido; en las demás faltan registros, y las tratamos todas como filtradas.
4. Desde las 13:40, el atacante ejecutó comandos de lectura dentro de los contenedores de bases de datos de los usuarios. Primero en unos pocos new-api／one-api; desde las 15:41, lecturas masivas de n8n; desde las 16:50, lectura tabla por tabla de parte de las bases de datos PostgreSQL; el último comando fue a las 17:04. En total, el atacante ejecutó comandos en 865 servicios de bases de datos, aunque no todos los comandos se completaron correctamente.
5. El atacante utilizó otra clave del clúster con permisos excesivos para leer una copia de seguridad de un clúster antiguo (Evaluado). La copia contenía una clave con la que se podía leer el servicio de gestión de secretos de Zeabur.
6. El 15 de octubre, de 14:52 a 16:51, el atacante leyó unos 53 secretos del entorno de producción (Confirmado). Entre ellos había credenciales de administración de la red interna, la cuenta de la base de datos de la plataforma y la clave privada de la GitHub App.

Ruta B: servidores dedicados de GCP

1. Desde el 14 de octubre a las 13:40, el atacante inició sesión como root en 101 servidores dedicados que Zeabur gestiona en GCP.
2. La configuración de inicialización de estos servidores guardaba la contraseña de root en texto plano. El atacante tenía una clave de GCP antigua que podía leer esa configuración. Evaluamos que el atacante obtuvo las contraseñas con esa clave.
3. Desde el 15 de octubre a las 14:26, el atacante utilizó la clave de GCP antigua para modificar la configuración de los servidores y añadir su propia clave SSH. A las 15:05, el atacante obtuvo además una clave de GCP de producción del servicio de gestión de secretos. Después de que desactiváramos la clave antigua a las 17:17, el atacante pasó a usar esta otra clave a las 17:28 para volver a añadir claves SSH, y también la desactivamos a las 17:31. El primer inicio de sesión en los servidores de GCP, el 14 de octubre, es anterior a la primera lectura conocida de secretos de producción, el 15 de octubre; esta última no puede presentarse como el origen del primero.
4. Antes de eso, entre el 1 y el 5 de septiembre, un origen desconocido ya había iniciado sesión con la contraseña de root en el mismo grupo de servidores, unos 98 de ellos el 5 de septiembre. Si se trata del mismo atacante no se puede confirmar por ahora.

Convergencia de las dos rutas

1. El 15 de octubre a las 15:30, en un servidor de GCP comprometido, el atacante utilizó las credenciales de administración de la red interna obtenidas en la ruta A para unir un nodo a la red interna de Zeabur.
2. Las reglas de la red interna permitían que este tipo de nodo se conectara a la base de datos de la plataforma. De 16:10 a 16:47, el atacante leyó la base de datos de la plataforma con una cuenta interna de solo lectura (Confirmado). Cotejamos los registros de conexión de ambos extremos de la red interna con los registros de la base de datos. Las 29 conexiones a la base de datos de ese periodo pueden atribuirse a este nodo, y los inicios de sesión y las consultas de esas conexiones pueden rastrearse uno por uno: en total, 8.903 registros de operaciones.
3. A las 17:58 eliminamos este nodo.

Algunas credenciales rotadas durante el incidente se usaron después sin autorización. La copia de seguridad diaria de los clústeres de Zeabur guarda todos los secretos, y el atacante leyó la clave de acceso a las copias de seguridad el 15 de octubre a las 15:04. La nueva clave que pusimos a las 15:40 quedó incluida en la copia de seguridad de las 16:00, y el atacante la utilizó a las 20:30. A las 18:51 eliminamos la clave de acceso a las copias de seguridad y a las 21:47 volvimos a rotar las credenciales afectadas. Está confirmado que la nueva clave quedó incluida en la copia de seguridad y que después se utilizó; que el atacante descargara esa copia de seguridad es una evaluación. El atacante pudo haber obtenido la copia antes de las 18:51, por lo que el uso de las 20:30 no significa que siguiera pudiendo descargarla después de las 18:51.

Qué datos se vieron afectados

Base de datos de la plataforma. El 15 de octubre, de 16:10 a 16:47, el atacante leyó los datos de la tabla anterior. Los datos de cuenta incluyen la información de la página de perfil, como el correo electrónico, el nombre de usuario y el número de teléfono. El atacante también buscó claves de API y claves privadas en las variables de entorno y los archivos de configuración. A juzgar por el contenido de los comandos y el comportamiento posterior, el atacante buscaba sobre todo claves de API que pudiera usar directamente, en especial claves de servicios de IA: buscó claves en la base de datos de la plataforma, leyó de forma masiva las credenciales de n8n y de new-api／one-api, y también intentó llamar a Amazon Bedrock con las claves de AWS de Zeabur. Esto es solo una observación sobre la intención del atacante; el atacante también leyó los datos de cuenta, y seguimos tratando todos los datos leídos como filtrados. De las tablas de verificación en dos pasos y de llaves de acceso (passkeys) solo se consultaron estadísticas; no hay registros de lectura de su contenido. Hemos revocado los tokens de acceso a la plataforma de todos los usuarios, y ningún token antiguo puede volver a utilizarse.

Las variables de entorno migradas quedan fuera del alcance de la lectura de la base de datos de la plataforma. Después del incidente de agosto, Zeabur ofreció a los usuarios de servidores dedicados indicaciones y funciones para rotar credenciales, eliminar las variables de entorno y los archivos de configuración almacenados en Zeabur, y migrarlos con un clic a su propio servidor. En los proyectos que completaron la migración, estos datos solo se almacenan en el servidor del usuario y Zeabur no los guarda, por lo que no forman parte de los datos leídos de la base de datos de la plataforma en este incidente. En los proyectos que no han migrado, las variables de entorno siguen almacenadas en Zeabur y también se leyeron esta vez. Esto no descarta filtraciones causadas por el compromiso del host; a los servidores dedicados de GCP comprometidos se les siguen aplicando las recomendaciones que figuran más abajo.

Suplantación de cuentas. El atacante leyó la clave que se utiliza para emitir credenciales de inicio de sesión, y evaluamos que la utilizó para falsificar credenciales de inicio de sesión. El atacante no leyó de forma masiva los tokens de acceso a la plataforma hasta las 16:47, y los tokens solo se guardan como hashes, lo que no explica una suplantación que empezó ya a las 16:12. El 15 de octubre, de 16:12 a 17:19, el atacante llamó a la API de Zeabur con la identidad de dos cuentas para leer listas de cuentas y proyectos; una de ellas era la cuenta de un empleado de Zeabur. Estas solicitudes no modificaron ningún recurso. A las 20:25 rotamos la clave de firma y se cerró la sesión de todos los usuarios.

Bases de datos de los clústeres compartidos. El atacante ejecutó comandos de lectura dentro de los contenedores de 865 bases de datos. Los registros de auditoría solo recogen los comandos, no su salida, y algunos comandos fallaron por errores, por lo que no se puede confirmar cuántos datos se leyeron realmente de cada base de datos. Según el contenido de los comandos, estimamos:

De las instancias de n8n con PostgreSQL, 602 (de las 607 revisadas) tenían la clave de cifrado en una variable de entorno, por lo que las credenciales de terceros dentro de n8n se filtraron, en la práctica, en texto plano. Como la lectura se produjo dentro del contenedor, la rotación de contraseñas de base de datos posterior al incidente de agosto no bloqueó esta vía de acceso.

Además, en la región de Tokio (hnd1), al menos 2 bases de datos PostgreSQL tenían instalado desde el 14 de octubre a las 01:51 un programa que se conectaba a un servidor externo, y una de ellas seguía conectándose el 15 de octubre a las 16:24. Si su punto de entrada fue una contraseña filtrada en agosto no se puede confirmar por ahora. En cuanto lo detectamos, avisamos a los usuarios afectados para que sustituyeran sus credenciales.

Servidores dedicados de GCP. La investigación confirmó que el atacante inició sesión con privilegios de root en 101 servidores; el último inicio de sesión fue el 15 de octubre a las 20:36. En 50 de ellos, el atacante añadió además claves públicas SSH bajo su control para mantener un acceso persistente. También creó 5 máquinas virtuales en el proyecto de GCP de Zeabur y montó en ellas 16 copias de discos de servidores de clientes.

Dado este alcance, los 101 servidores se clasifican como equipos afectados con posible filtración de datos y posibles mecanismos de acceso no autorizado. Hemos notificado por correo electrónico a los usuarios afectados y restablecido la contraseña de root de estos servidores.

Hetzner y DigitalOcean. Los tokens con los que se administran los servidores de clientes en estos dos proveedores estaban en código interno y en variables de entorno, y se filtraron junto con la base de datos de la plataforma. Con esos tokens se puede restablecer la contraseña, reinstalar el sistema o copiar discos. El 16 de octubre a la 01:09 revocamos todos los tokens. Ninguno de los dos proveedores tiene registros de auditoría de operaciones; todos los eventos de la cuenta de Hetzner pueden atribuirse al propio usuario o a tareas programadas del sistema, y los de DigitalOcean todavía se están cotejando.

Linode y Tencent Cloud. De los 890 servidores de Linode, en los 847 que tienen registros no hay inicios de sesión del atacante. No hay registros de uso de las credenciales de administración de Tencent Cloud.

GitHub App. El 15 de octubre a las 15:05, el atacante leyó la clave privada de la GitHub App de Zeabur. Con la clave privada se puede acceder a los repositorios a los que los usuarios han autorizado el acceso de Zeabur. A las 18:54 rotamos la clave privada y, por ahora, no hemos detectado que se utilizara. Hemos solicitado a GitHub Support los registros de auditoría completos y todavía no hemos recibido respuesta.

Sistemas internos de Zeabur. El atacante utilizó varias claves de AWS de Zeabur. La mayoría de las solicitudes se rechazaron, pero el atacante listó las copias de seguridad de bases de datos de usuarios de dos regiones y el contenido de las subidas de código fuente; si los descargó no se puede confirmar. El atacante intentó llamar a Amazon Bedrock, sin éxito en todos los casos y sin generar cargos.

Qué hemos hecho

Completado

También desactivamos las credenciales de Tencent Cloud, Alibaba Cloud y Linode que estaban escritas directamente en el código, eliminamos las claves SSH del atacante de los servidores de GCP y preservamos los registros de auditoría de cada sistema.

Después completamos además lo siguiente:

• Revocación de los tokens de acceso a la plataforma de todos los usuarios.
• Rotación del resto de secretos de producción leídos, incluidos la cuenta y la contraseña de la base de datos de la plataforma, y revocación de las demás credenciales filtradas.
• Envío de un correo a los usuarios de servidores dedicados de GCP y restablecimiento de la contraseña de root de los servidores.
• Restricción de las conexiones a la base de datos de la plataforma a servicios designados.
• Las copias de seguridad de los clústeres ya no guardan secretos en texto plano, y la clave de las copias de seguridad se guarda por separado del resto de secretos.
• Eliminación de las copias de discos, las instantáneas y los recursos de prueba que dejó el atacante.

En curso

• Investigación del origen de la filtración del repositorio de configuración, de la clave de GCP antigua y de los inicios de sesión en servidores de principios de septiembre.
• Nuevas alertas: uso inusual de permisos de administración, ejecución de comandos dentro de contenedores, lecturas masivas de secretos o bases de datos, unión de nuevos nodos a la red interna y uso de claves de la nube desde orígenes desconocidos.

Impacto en el servicio

Qué tienes que hacer

Hazlo ahora, sin esperar al correo de aviso. Las credenciales que ya cambiaste después del incidente de agosto también tienen que volver a cambiarse.

Todos los usuarios

1. Sustituye todas las credenciales de tus variables de entorno. Incluye claves de API, claves de la nube, contraseñas de bases de datos y claves de firma y cifrado. Primero revoca las antiguas en el proveedor del servicio y, después, crea otras nuevas y vuelve a desplegar. En los proyectos que migraron después de agosto sus variables de entorno a su propio servidor dedicado, esas variables quedan fuera del alcance de esta lectura de la base de datos de la plataforma; si el propio host se ha visto comprometido, sigue siendo necesario sustituir las credenciales guardadas en él.
2. Vuelve a iniciar sesión y crea de nuevo tus Access Tokens. Todos los tokens de acceso a la plataforma antiguos se han revocado. Crea un token nuevo en la página de gestión de Access Tokens y comprueba si hay solicitudes que no reconozcas.
3. Usuarios de zSend: vuelve a crear tus claves de API de zSend.
4. Usuarios de GitHub: revisa en el registro de auditoría de GitHub las operaciones de la GitHub App de Zeabur del 15 de octubre de 15:05 a 18:54. Presta atención a lo siguiente:
   • clones o envíos (push) inesperados
   • deploy keys añadidas
   • webhooks modificados
5. Revisa la facturación. Revisa el uso y la facturación de cada servicio desde el 14 de octubre de 2026; si usas servidores dedicados de GCP, remóntate al 1 de septiembre. El 14 de octubre es el momento más temprano en el que, según lo que sabemos ahora, el atacante utilizó credenciales; no significa que las credenciales no se hubieran filtrado antes. Si tienes registros anteriores, revísalos también.

Usuarios de clústeres compartidos

1. Cambia las contraseñas dentro de la base de datos. Cambiar solo las variables de entorno en Zeabur no cambia la contraseña dentro de la base de datos. Cambiar la contraseña tampoco invalida los datos ya filtrados; si la base de datos guarda hashes de contraseñas, sesiones de inicio de sesión o tokens de tus usuarios, revócalos y vuelve a generarlos también.
2. n8n: sustituye la clave de cifrado de n8n y vuelve a crear todas las credenciales de terceros dentro de n8n.
3. new-api／one-api: revoca las claves de los servicios de IA de origen y vuelve a generar los tokens de acceso.
4. PostgreSQL: comprueba si hay roles, funciones, triggers, tareas programadas o extensiones que no reconozcas. Si tienes dudas, crea una base de datos nueva e importa solo los datos.
5. Regiones de Taipéi (tpe1) y Hong Kong (hkg1): trata los datos de las copias de seguridad de bases de datos como filtrados.

Usuarios de servidores dedicados de GCP

Trata el servidor como comprometido:

1. Haz una copia de seguridad de los datos y reconstruye el servidor. Es la forma más fiable de eliminar puertas traseras.
2. Si por ahora no puedes reconstruirlo, como mínimo:
   • Elimina de /root/.ssh/authorized_keys las claves con el comentario @zeabur-pentest o que no reconozcas.
   • Revisa el grupo google-sudoers, las cuentas del sistema, crontab, los servicios de systemd y las cargas de trabajo de k3s.
   • Cambia la contraseña de root y desactiva el inicio de sesión SSH con contraseña.
3. Sustituye todas las credenciales del servidor, incluidas tus propias credenciales de la nube, y revisa la facturación correspondiente.
4. Revisa los registros de inicio de sesión con los indicadores de compromiso, remontándote al 1 de septiembre de 2026.

Usuarios de servidores dedicados de Hetzner y DigitalOcean

Comprueba en la consola si después del 14 de octubre se restableció la contraseña de root o se reinstaló el sistema, y confirma, con las comprobaciones indicadas arriba para GCP, que no hay métodos de inicio de sesión desconocidos.

Por qué ocurrió

Desencadenante: el atacante tenía el token de administración de los clústeres de Zeabur y varias claves de la nube. Estas credenciales se guardaban en texto plano en el repositorio de configuración. Cómo las obtuvo el atacante no se puede confirmar por ahora; la vía más probable figura en Hipótesis no demostradas.

Factores que ampliaron el impacto:

• Ciclo de vida de los tokens de administración y control de acceso a la interfaz. Los tokens de administración no tenían caducidad, no se habían rotado desde su creación en enero de 2024 y no se incluyeron en la rotación posterior al incidente de agosto. La interfaz de administración era accesible desde Internet.
• Almacenamiento de secretos y estado de las mejoras. Había claves guardadas en texto plano en el repositorio de configuración, en el código y en la configuración de servicios y tareas de compilación de los clústeres compartidos. La configuración de inicialización de los servidores de GCP también guardaba contraseñas de root; el problema se identificó el 3 de septiembre, pero no se había corregido antes del incidente. El cambio de migración de secretos iniciado el 3 de octubre no se había fusionado en la rama principal cuando ocurrió el incidente.
• Contenido de las copias de seguridad y aislamiento de claves. Las copias de seguridad de los clústeres contenían todos los secretos, y la clave de acceso a las copias se guardaba en el mismo entorno que otros secretos, lo que abría una vía adicional hacia su contenido. Algunas credenciales rotadas durante el incidente quedaron además incluidas en copias posteriores.
• Permisos de acceso y alcance de los recursos.
  • Una clave que solo necesitaba leer un espacio de almacenamiento podía leer en realidad todos los de la cuenta de AWS.
  • La cuenta de servicio predeterminada de los servidores de GCP tenía permisos de modificación a nivel de proyecto.
  • Las reglas de la red interna permitían que los nodos con ciertas etiquetas se conectaran a la base de datos de la plataforma.
  • La cuenta interna de solo lectura de la base de datos podía leer todos los datos.
  • Una clave de despliegue de un servicio dado de baja seguía siendo válida cuatro meses después de su retirada.
• Aislamiento entre servicios internos y servicios de usuarios. Ambos estaban desplegados en el mismo clúster, por lo que al leer la configuración de los usuarios el atacante también podía obtener credenciales de servicios internos.
• Cobertura de la detección y de los registros de auditoría. Más de 16 horas de actividad del atacante el 14 de octubre no activaron alertas; el equipo identificó el incidente al día siguiente tras el informe de un usuario. Como los registros de acceso de almacenamiento, GCP y GitHub están incompletos, parte del acceso y del alcance del impacto aún no se puede confirmar.

Relación con el incidente de agosto

Este es el segundo incidente de seguridad de Zeabur en menos de dos meses. Muchos usuarios hicieron cambios después de agosto siguiendo nuestras indicaciones, y querrán saber por qué volvió a ocurrir pese a esas medidas y si los dos incidentes están relacionados.

Qué se hizo después de agosto. Rotamos las claves internas que entonces se confirmó que se habían filtrado y desactivamos las Legacy API Keys. En el producto, los proyectos de servidores dedicados pueden migrar sus variables de entorno y archivos de configuración a su propio servidor, eliminar las credenciales SSH que guarda Zeabur y consultar los registros de inicio de sesión SSH. En los avisos y el anuncio del incidente de agosto también recomendamos a los usuarios rotar sus credenciales, eliminar las variables de entorno y los archivos de configuración almacenados en Zeabur, y migrarlos a su propio servidor.

Por qué volvió a ocurrir. La rotación de agosto no cubrió el token de administración de los clústeres ni las claves de AWS guardadas en texto plano en el repositorio de configuración, y la contraseña de root de la configuración de inicialización de los servidores de GCP tampoco se había corregido. Esas son precisamente las credenciales que utilizó el atacante esta vez. El informe del incidente de agosto decía que se habían «desactivado o rotado todas las claves administrativas internas»; esa afirmación no era completa, y aquí la corregimos. Cómo obtuvo el atacante estas credenciales no se puede confirmar por ahora; nuestras hipótesis figuran en Hipótesis no demostradas.

Lo que sí funcionó. En los proyectos que completaron la migración siguiendo las indicaciones de agosto, las variables de entorno y los archivos de configuración solo se almacenan en el propio servidor del usuario, y no forman parte de los datos leídos de la base de datos de la plataforma en este incidente.

Cronología

Cuestiones pendientes y limitaciones de la investigación

Los siguientes puntos no se pueden confirmar todavía debido a limitaciones en la cobertura o la integridad de los registros disponibles. Para los datos y credenciales en los que no se puede descartar un acceso no autorizado, aplicamos medidas de respuesta como si se hubieran filtrado.

• Cómo se obtuvieron las credenciales iniciales. Los registros de auditoría de GitHub disponibles no cubren las operaciones de clone; solo registran descargas de archivos comprimidos. Muestran que el repositorio de configuración se descargó mediante la autorización de GitHub de un empleado el 30 de agosto y el 2 de septiembre, pero todavía no se puede confirmar quién lo hizo. Hemos pedido a GitHub los registros completos. Nuestra evaluación actual está en Hipótesis no demostradas.
• Alcance real de la lectura de datos en las bases de datos de los clústeres compartidos. Los registros de auditoría conservan los comandos ejecutados, pero no su salida, por lo que no se puede confirmar por completo qué datos se obtuvieron.
• Alcance de las descargas de copias de seguridad y objetos de almacenamiento. Las pruebas en un servidor comprometido confirman que el 15 de octubre a las 15:42 el atacante obtuvo una copia de seguridad de una base de datos de un cliente mediante una URL de descarga prefirmada. Esta prueba es distinta de la copia de seguridad del clúster que se evalúa como implicada en la filtración de credenciales internas; no se ha confirmado si esta última se descargó. Como en ese momento no estaba activado el registro de acceso a objetos, el alcance real de las descargas de otros objetos y de las copias de seguridad de los clústeres sigue sin poder confirmarse por completo.
• Alcance de las lecturas en recursos de GCP. Los registros disponibles del proyecto de GCP no cubren las operaciones de lectura; por ahora solo se pueden confirmar las de escritura.
• Uso de los tokens de Hetzner y DigitalOcean. Ninguno de los dos proveedores ofrece registros de auditoría de operaciones utilizables en esta investigación, por lo que no se puede confirmar si esos tokens se usaron.
• Contenido devuelto por las consultas a la base de datos de la plataforma. Están confirmadas las consultas que ejecutó el atacante y el número de registros devueltos por 7 de las consultas principales. Sin embargo, los registros de la base de datos no guardan el contenido devuelto, y tampoco se puede confirmar cómo guardó o usó después el atacante esos datos.
• Alcance de la actividad en algunos clústeres. Los registros de auditoría del clúster de Taipéi (tpe0) y del clúster dedicado en el que el atacante creó recursos están incompletos, lo que limita la verificación de esa actividad.
• Actividad e impacto antes del 14 de octubre. En los registros disponibles de los clústeres compartidos y de AWS no hay actividad con credenciales válidas antes del 14 de octubre a las 01:36. Algunas IP que después participaron en el abuso de credenciales aparecen desde el 10 de octubre en registros de acceso a la API de Zeabur sin sesión iniciada; no obstante, esas IP pueden estar compartidas por servicios de proxy, por lo que la coincidencia de IP no basta para confirmar la identidad del operador. El 13 de octubre hubo además intentos de inicio de sesión SSH en servidores dedicados, todos sin éxito. Todavía no se puede confirmar si hubo filtración de datos durante ese periodo.

Hipótesis no demostradas

A continuación figuran las explicaciones que actualmente consideramos más probables. Están respaldadas por pruebas indirectas, pero carecen de registros directos y no deben citarse como hechos. Si obtenemos nuevas pruebas, las actualizaremos o las retiraremos.

1. Las credenciales iniciales podrían proceder del incidente de agosto

• Hipótesis: el atacante utilizó la clave privada de la GitHub App filtrada en el incidente de agosto para obtener el contenido del repositorio de configuración privado de Zeabur, incluidas las claves de AWS y el token de administración del clúster utilizados el 14 de octubre.
• Por ahora no hay ninguna prueba que demuestre directamente esta vía. Lo que sigue son solo indicios indirectos que coinciden en fechas y capacidades.
• Qué se sustituyó y qué no:
  • Clave privada de la GitHub App: sustituida. En el incidente de agosto, esta clave privada se leyó el 27 de agosto. Según el registro de auditoría de GitHub y las fechas de las versiones del servicio de gestión de secretos, la clave privada se sustituyó el 31 de agosto, por lo que pudo aprovecharse durante unos 4 días. Esta App está instalada en la organización de GitHub de Zeabur, y con la clave privada se pueden leer todos los repositorios de la organización.
  • Credenciales en texto plano del repositorio de configuración: no sustituidas. Las claves de AWS y el token de administración del clúster que el atacante utilizó primero el 14 de octubre ya estaban en texto plano en el repositorio de configuración el 27 de agosto. Después del incidente de agosto solo sustituimos la clave privada, no estas credenciales, que no se desactivaron hasta la respuesta al incidente del 15 de octubre. Por eso, aunque la clave privada ya se hubiera sustituido, si alguien obtuvo el contenido del repositorio entre el 27 y el 31 de agosto, las credenciales que contenía seguían siendo válidas en octubre.
• Otros indicios indirectos:
  • Algunos de los nombres de secretos internos que el atacante intentó leer solo aparecen en otro repositorio interno. El atacante podría tener el contenido de ambos repositorios, lo que encaja con los permisos de nivel de organización de la clave privada de la App.
  • Antes del 14 de octubre a las 01:36 no hay registros de uso de credenciales válidas en los clústeres compartidos ni en AWS, y las IP que después abusaron de las credenciales tampoco iniciaron sesión en la API de Zeabur. Esto encaja con la situación de «tener solo las credenciales del repositorio».
• Indicios en contra: las IP del atacante del incidente de agosto y de este incidente no coinciden.
• Estado de la investigación forense: hemos solicitado a GitHub Support los registros correspondientes, incluidos los tokens de acceso emitidos por esta App entre el 27 y el 31 de agosto, los registros de clones y descargas del repositorio de configuración, y el origen de las descargas del repositorio de configuración realizadas con la autorización de un empleado el 30 de agosto y el 2 de septiembre. A fecha de esta actualización, todavía no hemos recibido respuesta. Hasta obtener esos registros, esta vía es solo una hipótesis; tampoco puede descartarse que las descargas con la autorización del empleado sean otra vía de obtención.

2. Los sondeos anteriores al 14 de octubre podrían ser un reconocimiento del mismo atacante

• Hipótesis: los sondeos anónimos y los intentos de SSH del 10 al 13 de octubre fueron un reconocimiento del mismo atacante antes de usar las credenciales.
• Pruebas a favor:
  • 103.237.102.191: el 10 de octubre a las 18:27 navegó por Zeabur sin iniciar sesión, y el 14 de octubre accedió a los clústeres compartidos con el token de administración.
  • 23.106.46.239: desde el 12 de octubre a las 12:52 hizo numerosos intentos en la API de Zeabur sin iniciar sesión, el 13 de octubre intentó iniciar sesión por SSH en servidores dedicados y el 14 de octubre a las 01:36 utilizó por primera vez las claves de AWS filtradas.
• Pendiente de demostrar: el atacante utilizó de forma masiva servidores proxy, y una misma IP puede estar compartida por distintas personas; que la IP coincida no basta para confirmar que se trate de la misma persona.

3. El acceso con la clave de despliegue del 15 de octubre podría ser del atacante

• Hipótesis: el 15 de octubre a las 15:02, una clave de despliegue de un servicio desactivado leyó el repositorio de configuración; evaluamos que fue obra del atacante.
• Pruebas a favor: este acceso se produjo mientras el atacante leía secretos de producción (de 14:52 a 16:51); el servicio al que pertenece la clave llevaba cuatro meses desactivado y no debería tener accesos normales.
• Pendiente de demostrar: por ahora no hay registros que vinculen directamente este acceso con el atacante.

4. Las claves de usuarios filtradas podrían haberse utilizado ya de forma abusiva

• Hipótesis: el 16 de octubre, de 01:50 a 02:56, la clave de API de OpenAI que un usuario tenía almacenada en Zeabur se utilizó para enviar unas 1.107 solicitudes de generación de imágenes. Nuestra hipótesis es que esta clave procede de las variables de entorno filtradas en este incidente.
• Pendiente de demostrar: no se puede descartar que la clave se filtrara por otra vía. Este es también el motivo por el que este artículo recomienda a todos los usuarios sustituir sus claves; véase Qué tienes que hacer.

Indicadores de compromiso

Si encuentras alguno de los siguientes indicadores en tus sistemas o en los registros de tu proveedor de servicios, trata las credenciales relacionadas como filtradas y ponte en contacto con nosotros. El atacante utilizó de forma masiva servidores proxy rotativos; la tabla solo recoge direcciones representativas.

Glosario

• Clúster compartido (Shared Cluster): clúster de Kubernetes en el que se ejecutan juntos los servicios de varios usuarios. Anunciamos su retirada en febrero de 2026, y todos los servicios afectados se desplegaron antes de ese anuncio.
• Servidor dedicado (Dedicated Server): servidor gestionado por Zeabur que solo ejecuta los servicios de un único usuario.
• Token de administración: credencial con la que se puede administrar todo un clúster; quien la tiene puede leer la configuración de todos los servicios y ejecutar comandos en cualquier contenedor.
• Servicio de gestión de secretos: servicio de AWS que Zeabur utiliza para guardar de forma centralizada los secretos de producción.
• Red interna: red privada (Tailscale) que conecta los servicios de producción de Zeabur; la base de datos de la plataforma solo acepta conexiones desde esta red.
• Base de datos de la plataforma: base de datos de producción de Zeabur que guarda todas las cuentas, proyectos, servicios y variables de entorno.

Más información

Si necesitas ayuda, o detectas accesos inusuales o cargos que no puedas explicar, ponte en contacto con nosotros a través de Zeabur Support. Antes de escribirnos, revoca las credenciales afectadas y facilita únicamente información enmascarada; no incluyas claves ni contraseñas todavía válidas en un ticket de soporte ni en ningún canal público.

Si tus claves de API de terceros o tus cuentas en la nube generaron cargos adicionales a causa de este incidente, solicita una compensación mediante un ticket de soporte. Revisaremos los registros de uso y los cargos del proveedor y te explicaremos el resultado de la revisión.

Zeabur ha anunciado que cesará su actividad el 31 de diciembre de 2026, una decisión de carácter operativo. Hasta entonces, seguiremos tramitando las solicitudes de soporte y compensación relacionadas con este incidente, y seguiremos actualizando este artículo y la página de estado. Pedimos disculpas a todos los usuarios afectados.

Zeabur Team