Incidente de seguridad de Zeabur de octubre de 2026

Todas las horas de este artículo se expresan en tiempo universal coordinado (UTC).

El 15 de octubre de 2026 a las 13:56 recibimos el aviso de un usuario y abrimos una investigación. Al cotejar después los registros vimos que el atacante ya usaba credenciales internas de Zeabur desde el 14 de octubre a la 01:36, unas 36 horas antes de que nos diéramos cuenta. Durante todo ese tiempo usó credenciales válidas y los canales de acceso legítimos de Zeabur, y no saltó ninguna alerta.

El atacante entró por dos rutas que el 15 de octubre convergieron en la red interna de Zeabur, desde donde leyó la base de datos de la plataforma. Ninguna de las rotaciones posteriores al incidente de agosto cubrió las credenciales que usó esta vez.

Qué tienes que hacer

Hazlo ahora, sin esperar al correo de aviso. Los datos filtrados todavía pueden utilizarse, y 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 después de agosto migraron sus variables de entorno a su propio servidor dedicado, esas variables quedan fuera de la lectura de la base de datos de la plataforma; aun así, si el propio host se ha visto comprometido, hay que 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 la fecha más temprana en la que sabemos que el atacante usó credenciales, pero estas pudieron filtrarse 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 como filtrados los datos de las copias de seguridad de bases de datos.

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.

Alcance

A continuación se detalla cada sistema.

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. De las tablas de verificación en dos pasos y de llaves de acceso solo se consultaron estadísticas; no hay registros de lectura de su contenido. Los tokens de acceso a la plataforma solo se guardan como hashes, pero aun así los hemos revocado todos.

Lo que más buscaba el atacante eran claves de API que pudiera usar directamente, sobre todo de servicios de IA: buscó claves de API y claves privadas en las variables de entorno y los archivos de configuración, 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 lo deducimos del contenido de los comandos y del comportamiento posterior. El atacante también leyó los datos de cuenta, y tratamos como filtrado todo lo que leyó.

Después del incidente de agosto, Zeabur ofreció a los usuarios de servidores dedicados indicaciones y una función de migración con un clic: rotar las credenciales, eliminar las variables de entorno y los archivos de configuración almacenados en Zeabur y guardarlos en su propio servidor. En los proyectos que completaron la migración, estos datos solo están en el servidor del usuario y quedan fuera de lo que se leyó esta vez; en los que no migraron, las variables de entorno seguían almacenadas en Zeabur y también se leyeron. Esto no cubre las filtraciones causadas por el compromiso del propio host: en los servidores dedicados de GCP comprometidos hay que seguir los pasos de Qué tienes que hacer.

Suplantación de cuentas

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.

El atacante leyó la clave con la que se emiten las credenciales de inicio de sesión, y evaluamos que falsificó las credenciales con ella: los tokens de acceso a la plataforma solo se guardan como hashes, y el atacante no los leyó de forma masiva hasta las 16:47, lo que no explica una suplantación que empezó a las 16:12. 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, así que no se puede confirmar cuántos datos se leyeron realmente de cada base de datos. Esta es nuestra estimación según el contenido de los comandos:

Revisamos 607 instancias de n8n con PostgreSQL, y 602 tenían la clave de cifrado en una variable de entorno, así que las credenciales de terceros guardadas en n8n quedaron tan expuestas como si estuvieran en texto plano. Estas lecturas se hicieron dentro del contenedor, por lo que rotar las contraseñas de base de datos después del incidente de agosto no protegía frente a ellas.

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 la 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 el punto de entrada fue una contraseña filtrada en agosto no se puede confirmar. Al descubrirlo avisamos a los usuarios afectados para que sustituyeran sus credenciales.

Servidores dedicados de GCP

El atacante inició sesión como root en 101 servidores; el último inicio de sesión fue el 15 de octubre a las 20:36. En 50 de ellos añadió claves públicas SSH bajo su control para poder volver a entrar más adelante. 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.

Tratamos los 101 servidores como si sus datos se hubieran filtrado y pudieran tener puertas traseras. Hemos avisado por correo electrónico a los usuarios afectados y restablecido la contraseña de root de estos servidores.

Hetzner, DigitalOcean, Linode y Tencent Cloud

Los tokens con los que se administran los servidores de clientes en Hetzner y DigitalOcean estaban en código interno y en variables de entorno, y se filtraron junto con la base de datos de la plataforma. Con ellos 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 ofrece una API de auditoría de operaciones, así que no se puede confirmar si se usaron. Solo hemos podido descartar una cosa: los restablecimientos de contraseña y la creación de imágenes del 15 de octubre en Hetzner los hicieron los propios clientes y tareas programadas del sistema. En DigitalOcean no tenemos resultados del cotejo.

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 ella se puede acceder a los repositorios a los que los usuarios han dado acceso a Zeabur. A las 18:54 rotamos la clave privada. No se puede confirmar si llegó a usarse: no tenemos los registros de auditoría completos de la organización de GitHub, y GitHub Support nunca respondió a nuestra solicitud de registros.

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. Todos sus intentos de llamar a Amazon Bedrock fallaron y no generaron cargos.

Impacto en el servicio

Qué ocurrió

El atacante siguió dos rutas: la ruta A entró desde los clústeres compartidos en AWS y en el servicio de gestión de secretos de Zeabur, y la ruta B consiguió acceso root a los servidores dedicados de GCP. El 15 de octubre, las dos rutas convergieron en la red interna de Zeabur. Las técnicas de MITRE ATT&CK de cada paso figuran en el anexo.

Ruta A: de los clústeres compartidos al servicio de gestión de secretos

1. Obtención de credenciales. El 14 de octubre a la 01:36, el atacante empezó a usar claves de AWS internas de Zeabur, y a la 01:40, el token de administración de los clústeres compartidos. Las dos credenciales estaban en texto plano en el repositorio de configuración privado de Zeabur, en la misma configuración que las direcciones de conexión de cada clúster. Cómo las obtuvo el atacante no se puede confirmar; las hipótesis figuran en Hipótesis no demostradas.
2. Entrada en los clústeres compartidos. El token de administración no caducaba y la interfaz de administración de los clústeres estaba entonces abierta a Internet, así que el atacante pudo entrar desde fuera en los clústeres compartidos de 9 regiones. Desde la 01:51 leyó parte de los secretos del sistema, y desde las 12:39 amplió la lectura a la configuración y los secretos de todos los servicios, incluidas las variables de entorno. En las regiones con registros de lectura completos está confirmado que leyó el contenido; las demás las tratamos todas como filtradas.
3. Lectura de bases de datos de usuarios. 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, y 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 fueron 865 servicios de bases de datos, aunque no todos los comandos se completaron.
4. Clave del servicio de gestión de secretos, sacada de una copia de seguridad. Con otra clave del clúster que tenía permisos excesivos, el atacante leyó 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.
5. Lectura de secretos de producción. El 15 de octubre, de 14:52 a 16:51, el atacante leyó unos 53 secretos de producción (Confirmado), entre ellos 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: acceso root a los servidores dedicados de GCP

1. Inicio de sesión en los servidores. Desde el 14 de octubre a las 13:40, el atacante inició sesión como root en los servidores dedicados que Zeabur gestiona en GCP, 101 en total. Al crear estos servidores, la contraseña de root se escribía en texto plano en la configuración de inicialización y no se borraba al terminar. La propia plataforma usa esa contraseña para entrar en los servidores, por eso se guardaba en texto plano y no como hash. La clave de GCP antigua que tenía el atacante podía leer esa configuración, y evaluamos que así obtuvo las contraseñas.
2. Adición de claves SSH. Desde el 15 de octubre a las 14:26, el atacante usó la clave de GCP antigua para modificar la configuración de los servidores y añadir su propia clave SSH. A las 15:05 obtuvo además una clave de GCP de producción del servicio de gestión de secretos.
3. Nuevo intento con otra clave. Desactivamos la clave antigua a las 17:17 y, 11 minutos después, el atacante volvió a añadir claves SSH con la clave que acababa de obtener. A las 17:31 desactivamos también esa.

Estos inicios de sesión se produjeron el 14 de octubre, más de un día antes de la primera lectura conocida de secretos de producción en la ruta A (15 de octubre, 14:52), así que el origen de la ruta B no puede explicarse con los secretos leídos en la ruta A. 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.

Convergencia de las dos rutas

1. Unión a la red interna. El 15 de octubre a las 15:30, en un servidor de GCP comprometido, el atacante usó 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. Lectura de la base de datos de la plataforma. 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).
3. Eliminación del nodo. A las 17:58 eliminamos este nodo.

La conclusión de que se leyó la base de datos de la plataforma se basa en los registros de conexión de ambos extremos de la red interna y en los registros de la base de datos: las 29 conexiones a la base de datos de ese periodo corresponden a este nodo, y los inicios de sesión y las consultas de esas conexiones pueden rastrearse uno por uno, con un total de 8.903 registros de operaciones.

Detección

El 15 de octubre a las 13:56 recibimos el aviso de un usuario y solo entonces abrimos la investigación. Habían pasado unas 36 horas desde que el atacante usó credenciales por primera vez (14 de octubre, 01:36), y su actividad del 14 de octubre había durado más de 16 horas.

En todo ese tiempo no saltó ninguna alerta:

• El atacante usó credenciales válidas y los canales de acceso legítimos de Zeabur; en los registros, su actividad no se distinguía de las operaciones de administración normales.
• No teníamos alertas para este tipo de comportamiento, como el uso inusual de permisos de administración, la ejecución de comandos dentro de contenedores, la lectura masiva de secretos, la unión de nodos nuevos a la red interna o el uso de claves de la nube desde orígenes desconocidos.

Respuesta

Contención

Unas 4 horas después de abrir la investigación eliminamos el nodo del atacante en la red interna. Estas fueron las medidas del 15 y el 16 de octubre:

Claves sustituidas durante el incidente que se volvieron a usar

El atacante llegó a usar parte de las credenciales que pusimos el mismo día de la respuesta, y el problema estaba en la copia de seguridad diaria de los clústeres. Esa copia incluye todos los recursos del clúster, secretos incluidos, y el atacante había leído la clave de acceso a las copias de seguridad el 15 de octubre a las 15:04:

1. A las 15:40 pusimos una clave nueva.
2. A las 16:00, la copia de seguridad diaria incluyó esa clave nueva.
3. A las 18:51 eliminamos la clave de acceso a las copias de seguridad.
4. A las 20:30, el atacante usó la clave nueva.
5. A las 21:47 volvimos a rotar las credenciales afectadas.

Está confirmado que la copia de seguridad incluyó la clave nueva y que después se usó; que el atacante descargara esa copia es una evaluación. La clave usada a las 20:30 también pudo salir de una copia que el atacante ya tuviera antes de las 18:51.

Erradicación y recuperación

• Eliminamos las claves SSH del atacante de los servidores dedicados de GCP, restablecimos la contraseña de root y avisamos por correo a los usuarios afectados.
• Eliminamos las copias de discos, las instantáneas y los recursos de prueba que dejó el atacante.
• Revocamos los tokens de acceso a la plataforma de todos los usuarios.
• Desactivamos las credenciales de Tencent Cloud, Alibaba Cloud y Linode que estaban escritas directamente en el código.
• Rotamos el resto de secretos de producción leídos, incluidas la cuenta y la contraseña de la base de datos de la plataforma, y revocamos las demás credenciales filtradas.
• Preservamos los registros de auditoría de cada sistema.
• Todas las funciones afectadas se han restablecido; el periodo afectado de cada una figura en Impacto en el servicio.

Causas raíz

El atacante tenía desde el principio el token de administración de los clústeres de Zeabur y varias claves de la nube. Estas credenciales estaban en el repositorio de configuración privado de Zeabur y, como se había hecho siempre, se guardaban en texto plano. Lo más probable es que se filtrara este repositorio, pero la vía no se puede confirmar; las hipótesis figuran en Hipótesis no demostradas.

Carencias que dejaron al atacante llegar a la base de datos de la plataforma

• Token de administración sin caducidad e interfaz de administración abierta a Internet. El token se creó en enero de 2024 y nunca se rotó; la rotación posterior al incidente de agosto tampoco lo incluyó.
• Secretos en texto plano. Había claves guardadas en texto plano en el repositorio de configuración, en el código, en la configuración de servicios de los clústeres compartidos y en las tareas de compilación. La configuración de inicialización de los servidores de GCP guardaba la contraseña de root; detectamos el problema el 3 de septiembre y no estaba corregido cuando ocurrió el incidente. La migración de secretos iniciada el 3 de octubre tampoco se había fusionado aún en la rama principal.
• Copias de seguridad con todos los secretos, y su clave guardada junto a los demás secretos. Por eso el atacante pudo sacar más credenciales de las copias, y algunas credenciales que pusimos durante el incidente acabaron en copias posteriores.
• Permisos mayores de lo necesario.
  • Una clave que solo necesitaba leer un espacio de almacenamiento podía leer 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 cierta etiqueta se conectaran a la base de datos de la plataforma, y con las credenciales de administración de la red interna un nodo nuevo podía llevar esa etiqueta directamente.
  • La cuenta interna de solo lectura de la base de datos podía leer todos los datos.
  • La clave de despliegue de un servicio dado de baja seguía siendo válida cuatro meses después de la baja.
• Servicios internos y servicios de usuarios en el mismo clúster. Al leer la configuración de los usuarios, el atacante obtuvo también credenciales de servicios internos.
• Detección y registros insuficientes. El ataque duró unas 36 horas sin activar ninguna alerta; véase Detección. Los registros de acceso de almacenamiento, GCP y GitHub están incompletos, y parte de los accesos y del alcance no se ha podido determinar.

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.

Lecciones aprendidas

Qué hicimos bien

• En los proyectos que completaron la migración siguiendo las indicaciones de agosto, las variables de entorno y los archivos de configuración solo estaban en el servidor del propio usuario y no forman parte de los datos leídos de la base de datos de la plataforma.
• Unas 4 horas después de abrir la investigación eliminamos el nodo del atacante en la red interna, y ese mismo día bloqueamos el acceso desde Internet a la interfaz de administración de los clústeres y a los servidores dedicados de GCP.
• Los registros de conexión de ambos extremos de la red interna y los de la base de datos estaban completos, y con ellos pudimos confirmar registro a registro el alcance de la lectura de la base de datos de la plataforma.

Qué hicimos mal

• La rotación posterior al incidente de agosto no cubrió las credenciales usadas esta vez, y lo que decía el informe de agosto no era completo; véase Relación con el incidente de agosto.
• El 3 de septiembre detectamos que la configuración de inicialización de los servidores de GCP guardaba la contraseña de root y no lo corregimos antes del incidente.
• La copia de seguridad diaria incluyó las claves que pusimos el día de la respuesta, y parte de ellas se usaron después; véase Claves sustituidas durante el incidente que se volvieron a usar.
• El ataque duró unas 36 horas y lo descubrimos por el aviso de un usuario; véase Detección.

Acciones de mejora

Zeabur cesará su actividad el 31 de diciembre de 2026, por lo que aquí solo figuran las mejoras ya aplicadas.

Cuestiones sin resolver

Limitaciones de la investigación

Con los registros disponibles, los puntos siguientes seguían sin poder determinarse al cerrar este informe. Tratamos como filtrados todos los datos y credenciales en los que no se puede descartar un acceso.

• De dónde salieron las credenciales iniciales. Los registros de auditoría de GitHub solo recogen descargas de archivos comprimidos, no operaciones de clone. Muestran que el 30 de agosto y el 2 de septiembre alguien descargó el repositorio de configuración con la autorización de GitHub de un empleado, pero no se puede confirmar quién. Pedimos a GitHub Support los registros completos y no llegamos a recibir respuesta.
• Por dónde se filtró la clave de GCP antigua. Revisamos el historial de git, el servicio de gestión de secretos y las copias de seguridad del clúster antiguo, y no encontramos el punto de filtración. Tampoco hemos llegado a una conclusión sobre si 31.57.201.201, que inició sesión con la contraseña de root en servidores dedicados de GCP a principios de septiembre, es el mismo atacante.
• Cuántos datos se leyeron realmente de las bases de datos de los clústeres compartidos. Los registros de auditoría conservan los comandos, pero no su salida; solo sabemos qué comandos ejecutó el atacante.
• Alcance de las descargas de copias de seguridad y objetos de almacenamiento. Las pruebas halladas en un host 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. Esa copia es distinta de la copia de seguridad del clúster que contenía credenciales internas. De las copias de seguridad de bases de datos de Taipéi (tpe1) y Hong Kong (hkg1), y del almacenamiento de las subidas de código fuente, solo está confirmado que se listaron los objetos. Como entonces no estaba activado el registro de acceso a objetos, no se puede confirmar si se descargaron. Tampoco hay pruebas directas de que se leyera la copia de seguridad del clúster antiguo, que sigue siendo una evaluación.
• Alcance de las lecturas en recursos de GCP. El proyecto de GCP no tenía activados entonces los registros de auditoría de acceso a datos; solo hay registros de las operaciones de escritura, y no hay otra forma de comprobarlo a posteriori.
• Si se usaron los tokens de Hetzner y DigitalOcean. Ninguno de los dos proveedores ofrece una API de auditoría de operaciones. Aparte de las operaciones del 15 de octubre en Hetzner, que se ha confirmado que hicieron los propios clientes y tareas programadas del sistema, no se puede confirmar nada.
• Si se usó la clave privada de la GitHub App. No tenemos los registros de auditoría completos de la organización de GitHub, y GitHub Support no respondió.
• Qué devolvieron las consultas a la base de datos de la plataforma. Hemos confirmado las consultas que ejecutó el atacante, el número de registros que devolvieron 7 de las consultas principales y que 14 colecciones devolvieron datos; las consultas principales llegaron hasta el último registro. Los registros de la base de datos no guardan el contenido devuelto, y tampoco podemos saber 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 de los clústeres dedicados en los que el atacante creó recursos están incompletos, y no se siguieron investigando.
• Qué ocurrió antes del 14 de octubre. En los registros de los clústeres compartidos y de AWS no hay actividad con credenciales válidas antes del 14 de octubre a la 01:36. Algunas IP que después abusaron de las credenciales aparecen desde el 10 de octubre en los registros de acceso a la API de Zeabur sin sesión iniciada, pero pueden ser servidores proxy que comparten muchas personas, y que la IP coincida no basta para confirmar que se trate de la misma persona. El 13 de octubre hubo además intentos de inicio de sesión SSH en servidores dedicados, todos sin éxito. No se puede confirmar si hubo filtración de datos en ese periodo.

Hipótesis no demostradas

Estas son las explicaciones que consideramos más probables. Las respaldan pruebas indirectas, pero carecen de registros directos y no deben citarse como hechos. Al cerrar este informe, ninguna se había demostrado ni descartado.

Hipótesis 1: las credenciales iniciales proceden del incidente de agosto

• Hipótesis: el atacante usó 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 que usó el 14 de octubre. Ninguna prueba demuestra directamente esta vía; lo que sigue son solo indicios indirectos que encajan 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, así 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 usó 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 a favor:
  • 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.
• Por qué no se puede demostrar: pedimos a GitHub Support 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 hechas con la autorización de un empleado el 30 de agosto y el 2 de septiembre. GitHub Support no llegó a responder. Tampoco se puede descartar que las descargas con la autorización del empleado sean otra vía de obtención.

Hipótesis 2: los sondeos anteriores al 14 de octubre fueron 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.
• Indicios 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 la 01:36 usó por primera vez las claves de AWS filtradas.
• Por qué no se puede demostrar: el atacante usó 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.

Hipótesis 3: el acceso con la clave de despliegue del 15 de octubre fue obra 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.
• Indicios a favor: este acceso se produjo mientras el atacante leía secretos de producción (de 14:52 a 16:51), y el servicio al que pertenece la clave llevaba cuatro meses desactivado, así que no debería tener accesos normales.
• Por qué no se puede demostrar: no hay registros que vinculen directamente este acceso con el atacante.

Anexo

Cronología

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. La confianza sigue la escala de 0 a 100 de STIX: Confirmado equivale a 85, Evaluado a 60 y No se puede confirmar a 30. La versión legible por máquina está en el archivo STIX 2.1, donde los indicadores de IP son válidos hasta el 13 de enero de 2027.

Correspondencia con MITRE ATT&CK

Ordenada según las tácticas de MITRE ATT&CK.

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.

Soporte y costes

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 alguien usa las credenciales filtradas, es posible que tengas que asumir cargos adicionales, y lo sentimos mucho. Con su situación financiera actual, Zeabur no puede asumir los costes de servicios de terceros derivados de este incidente. La mayoría de los proveedores de nube y de API tienen vías de reclamación o de condonación, y puedes adjuntar este informe como explicación. Si el proveedor te pide otros justificantes, indícanoslo en un ticket y haremos lo posible por facilitarlos. Este incidente no afecta a los reembolsos del saldo de la cuenta; los detalles están en el seguimiento del incidente de seguridad de octubre.

Zeabur ha anunciado que cesará su actividad el 31 de diciembre de 2026, una decisión de carácter operativo. Hasta entonces seguiremos atendiendo las solicitudes de soporte relacionadas con este incidente.

Supimos de este incidente por el aviso de un usuario, unas 36 horas después de que el atacante empezara a usar las credenciales. Proteger las credenciales que guardas en Zeabur era responsabilidad nuestra, y no lo conseguimos. Pedimos disculpas a todos los usuarios afectados.

El equipo de Zeabur