Brecha de Zeabur y variables de entorno: cierre en diciembre

La brecha de Zeabur dejó al aire las variables de entorno de miles de proyectos y la empresa decidió cerrar. Un atacante entró con credenciales internas guardadas en texto plano, leyó la base de datos de producción y alcanzó 321.810 cuentas y 3.218.965 registros de variables. Zeabur, plataforma de despliegue para desarrolladores, dejará de prestar servicio el 31 de diciembre de 2026.

El dato que duele está en el tipo de registro copiado. Una variable de entorno es el cajón donde una aplicación guarda sus secretos: la clave de una base de datos, la llave de acceso a un servicio de inteligencia artificial, el token de pagos o la contraseña de un correo transaccional. Copiar ese cajón completo equivale a copiar las llaves de servicios que ni siquiera viven dentro de Zeabur.

Brecha de Zeabur y variables de entorno: la entrada fue con llaves viejas

Zeabur informó que el ataque ocurrió entre el 14 y el 15 de octubre de 2026. El atacante usó credenciales internas filtradas, entre ellas credenciales de administrador y llaves de acceso a la nube, y se movió por el clúster compartido, por algunos servidores dedicados y por sistemas internos hasta leer la base de datos de producción. BleepingComputer publicó el informe con la cadena de ataque y la tabla de alcance preparadas por la propia empresa.

El alcance cubre clústeres compartidos en nueve regiones. Zeabur confirmó inicios de sesión como administrador principal en 101 servidores de Google Cloud Platform (GCP, la nube de Google) usados por 92 clientes, llaves SSH (Secure Shell, el acceso remoto a servidores) añadidas en 50 servidores y 16 copias de discos de clientes conectadas a máquinas virtuales del atacante. Con un disco copiado y montado en otro equipo, el contenido se lee sin pedir permiso a nadie.

Agosto dejó la raíz del problema. Ese mes, un primer ataque aprovechó una falla en la aplicación NextChat de un cliente y avanzó por sistemas internos con separación débil, hasta robar credenciales de Amazon Web Services y tocar la misma base de datos. Zeabur reveló el detalle que explica la segunda entrada: los tokens de administrador no tenían fecha de vencimiento, no se habían cambiado desde su creación en enero de 2024 y quedaron fuera de la rotación aplicada tras el incidente de agosto. Los portales de administración, además, seguían accesibles desde internet abierto y las credenciales no estaban cifradas en reposo.

Zeabur sostiene que el atacante obtuvo con probabilidad alta las credenciales de octubre durante la intrusión de agosto, aunque ese vínculo sigue sin confirmación definitiva. Una parte del daño sí tuvo un límite: las variables trasladadas en exclusiva a servidores propios de cada cliente durante la respuesta de agosto quedaron fuera de esta lectura de la base de datos, con la salvedad de que un servidor comprometido puede exponerlas por otra vía.

Rotar todo otra vez, aunque ya se haya rotado en agosto

La instrucción para los clientes es tajante: cambiar de inmediato cada credencial y cada secreto guardado en las variables de entorno de la plataforma, revocar todas las sesiones activas y reconstruir los servidores de GCP afectados. La orden alcanza también a quien ya hizo su rotación tras el incidente de agosto. Una llave creada en septiembre y guardada otra vez dentro de Zeabur pudo quedar dentro del paquete leído en octubre, y tratarla como segura sería repetir el error que originó la segunda brecha.

El patrón se repite en el sector. Los ataques contra herramientas de desarrollo y servicios de inteligencia artificial persiguen el mismo botín: claves de acceso que abren cuentas de nube, modelos de pago y bases de datos de terceros. Una clave de un servicio de modelos puede quemarse en horas generando cargos en la cuenta de la víctima, y una contraseña de base de datos copiada sobrevive al cambio de servidor si nadie la reemplaza.

El cierre de Zeabur: fechas y migración antes del 31 de diciembre

Zeabur anunció el cierre el fin de semana posterior al hallazgo. El 1 de diciembre se desactivan las renovaciones y se pausan los servicios en ejecución dentro de los clústeres compartidos. Los servidores dedicados vencen de forma escalonada y el 31 de diciembre se apagan los últimos clústeres compartidos. La empresa dejó abierta la posibilidad de dar tiempo extra para migrar datos, sin fechas concretas publicadas hasta este momento.

Detrás de la decisión hay una historia corta e intensa: tres años y medio de crecimiento continuo, con 2026 como año récord en actividad. La propia Zeabur explicó que escalar el proyecto para atender la demanda volvió la operación cada vez más compleja y difícil de mantener, y que las fallas de seguridad recientes forman parte de esa cuenta. Tras el incidente de agosto, el equipo de Zeabur discutió durante semanas qué hacer; la segunda brecha inclinó la balanza hacia el cierre ordenado.

Quien tenga hoy un proyecto vivo en Zeabur tiene dos trabajos con fecha límite, no uno. El primero es de seguridad: inventariar cada secreto guardado en la plataforma, reemplazarlo en el servicio de origen y comprobar que la llave vieja dejó de funcionar. El segundo es de mudanza: sacar código, datos y dominios antes del 1 de diciembre, probar la copia restaurada en el destino y guardar constancia de qué se movió y qué acceso quedó abierto en la plataforma que cierra.

Fuente: BleepingComputer

Foto: BleepingComputer