Incidente de seguridad de Zeabur de agosto de 2026

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

El 27 de agosto de 2026, un atacante obtuvo acceso no autorizado a los sistemas de Zeabur. El ataque comenzó con una vulnerabilidad en un servicio de un usuario expuesto a Internet y escaló a través de cuatro límites de sistema, alcanzando la red interna del clúster compartido, las cuentas de la plataforma, la cuenta de AWS y el entorno de producción. Confirmamos que se leyó parte de la base de datos de producción, incluida información de cuentas y variables de entorno de proyectos que contenían claves de API de terceros, contraseñas de bases de datos y otras credenciales de servicios.

Pedimos disculpas a todos los usuarios afectados por este incidente. El incidente dejó al descubierto carencias en la forma en que almacenábamos las credenciales internas y delimitábamos sus permisos, en cómo aislábamos las redes de los clústeres compartidos y en cómo supervisábamos y alertábamos sobre accesos inusuales. Desde entonces se han llevado a cabo la remediación y las mejoras de la plataforma.

Alcance confirmado del impacto

Cotejamos los registros de solicitudes de la plataforma, los registros de consultas de la base de datos de producción y los registros de claves de acceso, uso y facturación de AI Hub para identificar qué cuentas, proyectos y servicios fueron consultados o leídos. Esto define el alcance del impacto que hemos confirmado hasta la fecha.

Variables de entorno de los proyectos

Nuestra investigación confirmó el acceso no autorizado a los nombres y los valores de las variables de entorno de los proyectos. Esas variables contenían claves de API de servicios de IA y de otros terceros, credenciales de acceso a la nube, datos de conexión y contraseñas de bases de datos, claves de firma de aplicaciones y otros ajustes de proyecto. Comparamos los proyectos y servicios afectados con los registros de consultas de la base de datos de producción para delimitar el alcance de este impacto.

Hemos completado el tratamiento de las credenciales internas de la plataforma. También enviamos el primer aviso el 28 de agosto a las 08:53 y el segundo aviso a las 17:03 de ese mismo día, en los que pedíamos a los usuarios afectados que sustituyeran todas las credenciales de terceros implicadas.

Cuentas y AI Hub

Los registros de solicitudes de la plataforma muestran que el atacante explotó las Zeabur Legacy API Keys que había obtenido para consultar cuentas e información de AI Hub, y para crear claves de acceso de AI Hub. Tras nuevas comprobaciones en los registros de uso y facturación de AI Hub, no se identificó ningún uso de AI Hub con esas claves ni se generó ningún cargo de AI Hub. Hemos revisado y revocado todas las claves creadas por el atacante.

Qué ocurrió

La ruta del incidente que hemos confirmado atraviesa cuatro límites de sistema. El atacante explotó primero una vulnerabilidad de ejecución remota de código (RCE) en un servicio expuesto a Internet para acceder a la red interna del clúster compartido y, a continuación, obtuvo de la caché una Zeabur Legacy API Key con privilegios elevados, con la que leyó las variables de entorno de un servicio de gestión interno. Una clave root de AWS que se encontraba entre esas variables permitió al atacante acceder a nuestra infraestructura en la nube con el máximo nivel de privilegios. Utilizando la conexión de red privada y las credenciales de base de datos ya existentes en el clúster compartido, el atacante llegó después a la base de datos de producción.

Esta ruta implicaba dos mecanismos de producto heredados que ya estaban en proceso de retirada antes del incidente: los clústeres compartidos y las Zeabur Legacy API Keys. Anunciamos el plan de retirada de los clústeres compartidos en febrero de 2026, desactivamos la creación de nuevos proyectos en marzo y desactivamos la creación de nuevos servicios dentro de los proyectos existentes en abril. El servicio implicado en este incidente se había desplegado antes del anuncio de retirada y seguía en funcionamiento en ese momento.

Etapa uno: entrada en la red interna del clúster compartido a través de un servicio público

Nuestra investigación confirmó que el atacante comenzó por un servicio NextChat v2.16.1 que un usuario había desplegado en un clúster compartido. Los registros de ejecución del servicio contenían indicios claros de explotación, que apuntaban a CVE-2026-7644, relativa a las comprobaciones de autorización de su funcionalidad MCP. Una vez obtenida la ejecución de código en ese servicio, la actividad relacionada también podía conectarse, a través de la red interna del clúster compartido, a los endpoints internos que el servicio alcanzaba.

La caché se diseñó originalmente para guardar la correspondencia entre dominios y servicios, y también almacenaba Zeabur Legacy API Keys. Una vez que el atacante leyó la caché, su acceso dejó de limitarse a NextChat.

Comparamos las cuentas y las listas de recursos asociadas al atacante con los registros de solicitudes de la plataforma y confirmamos que estas Zeabur Legacy API Keys procedían de esa misma caché. A continuación, el atacante probó las claves por lotes para identificar las que seguían siendo válidas y tenían permisos más elevados; una de ellas pertenecía a un administrador de equipo.

Las Legacy API Keys eran un método de autenticación temprano que Zeabur ofrecía para la CLI y los scripts de automatización. El diseño original no admitía ámbitos (scopes), por lo que los permisos no estaban limitados ni por operación y recurso ni por caducidad. Esta fue una de las razones por las que se amplió el impacto de este incidente.

Todas las Zeabur Legacy API Keys se han desactivado. Los Access Tokens actuales admiten ámbitos, con permisos que ahora pueden limitarse según su finalidad, con fechas de caducidad y con registros de auditoría conservados. Desde el incidente también hemos reforzado las comprobaciones de autorización de nuestras API.

Etapa dos: del acceso administrativo de Zeabur a la cuenta de AWS

El atacante abusó de la Zeabur Legacy API Key de este administrador para enumerar los proyectos internos y leer las variables de entorno de un servicio de gestión interno. Esas variables contenían varias claves de acceso de AWS, incluida una clave del usuario root de AWS conservada durante mucho tiempo. Los registros de auditoría de la nube muestran que, una vez leídos esos ajustes, el mismo origen probó y abusó de inmediato de las claves implicadas.

Las claves guardadas en el proyecto interno en ese momento tenían permisos en la nube superiores a los que requerían las operaciones cotidianas, y por eso evaluamos que el alcance de este incidente se extendía a la cuenta de AWS.

Etapa tres: de AWS y el clúster compartido a producción

Tras obtener acceso root de AWS, el atacante empezó a enumerar recursos en la nube y después entró en el clúster compartido de Tokio. Los registros de auditoría de la nube y del clúster muestran tareas puntuales inusuales y cambios de privilegios en el clúster, entre ellos la concesión de permisos de administrador del clúster a una cuenta de servicio. En ese momento, el atacante tenía el máximo nivel de control sobre el clúster compartido al que había accedido.

Los sistemas principales de Zeabur se ejecutan en otro proveedor de nube. La base de datos de producción no tiene ningún punto de entrada de red pública y solo se puede alcanzar a través de una red privada. Sin embargo, una tarea de mantenimiento programada existente en el clúster compartido disponía de esa conectividad.

Esta tarea programada se diseñó para limpiar los servicios del clúster compartido designado, y por eso necesitaba conectividad con los sistemas principales. La credencial de base de datos de la tarea podía leer más de lo que la tarea requería realmente, y podía volver a conectarse a los sistemas principales a través de la red privada. Cuando el atacante tomó el control del clúster compartido de Tokio, obtuvo acceso tanto a la conexión de red como a la base de datos.

Los registros de la base de datos confirman que el atacante asumió esta identidad de servicio para leer variables de entorno de proyectos en producción. Tras comparar los registros de consultas, no encontramos indicios de que se hubiera leído ningún otro dato, y hemos revocado esta credencial y eliminado la ruta del clúster compartido de vuelta a los sistemas principales.

Nuestra responsabilidad y por qué se propagó el ataque

La vulnerabilidad de NextChat fue el punto de entrada inicial de este incidente. Como plataforma que permite a los usuarios desplegar y ejecutar aplicaciones, somos —y debemos ser— responsables de limitar las redes, los datos y los permisos que un atacante puede alcanzar cuando una carga de trabajo se ve comprometida. Las credenciales de la plataforma guardadas en la caché de enrutamiento, las Legacy API Keys sin ámbito ni caducidad, los permisos excesivos en la nube que tenía un servicio interno y una tarea de mantenimiento que disponía a la vez de conectividad entre entornos y de una credencial de base de datos con permisos excesivos ampliaron conjuntamente el impacto de este incidente. Los clústeres compartidos y las Legacy API Keys estaban en proceso de retirada, y mantener en ellos un aislamiento y unos controles de acceso adecuados hasta que dejaran de funcionar formaba parte de ese proceso.

Respuesta y remediación

Para el alcance confirmado descrito arriba, primero cerramos las rutas de acceso que habíamos identificado y después tratamos las credenciales y los entornos afectados uno por uno.

Completado

• Credenciales internas de la plataforma: desactivamos o rotamos todas las claves administrativas internas, contraseñas de bases de datos y contraseñas de caché, y desactivamos por completo la autenticación mediante Zeabur Legacy API Key. Ninguna de las claves heredadas puede utilizarse para acceder a Zeabur.
• Claves de acceso de AI Hub: se ha revocado toda clave de acceso de AI Hub que se haya confirmado que fue creada por el atacante. AI Hub sigue desactivado y anunciaremos por separado nuestros planes al respecto.
• Autorización de la API y registros de acceso: reforzamos las comprobaciones de autorización de nuestras API existentes y añadimos registros de acceso a los Access Tokens actuales. En la página de gestión de Access Tokens puedes consultar cuándo hizo una solicitud cada token, el origen de esa solicitud y la operación realizada, de modo que puedas identificar usos que no reconozcas e investigar accesos inusuales.
• Rutas de acceso a producción y credenciales de base de datos: desconectamos la conexión existente del clúster compartido con la base de datos de producción, revocamos la cuenta de servicio de base de datos correspondiente y eliminamos los permisos de clúster inusuales que identificamos.
• Servicios internos heredados y clústeres compartidos: desactivamos los servicios internos heredados implicados en este incidente, separamos la información de enrutamiento de las credenciales de usuario, eliminamos las credenciales de la caché heredada y completamos la sustitución de los hosts del clúster compartido.
• Auditoría, supervisión y alertas: cubrimos las carencias de nuestros registros de operaciones de clúster, red, base de datos y caché, añadimos alertas para cambios de privilegios, uso inusual de la cuenta en la nube y consultas sospechosas a la base de datos, y activamos la supervisión de seguridad en tiempo de ejecución en la nube.
• Conservación de registros y comprobaciones internas de seguridad: ampliamos el periodo de conservación de la supervisión, los registros y las trazas de solicitudes, ampliamos el almacenamiento y completamos las autocomprobaciones de seguridad de los dispositivos de empleados y los entornos de desarrollo implicados.

En curso

• Cotejo de registros entre sistemas: seguimos comparando los registros de la nube, del clúster, de la base de datos y de las aplicaciones para determinar si alguna otra actividad guarda relación con este incidente.
• Soporte, compensación e información a las autoridades: seguimos tramitando las solicitudes de soporte y compensación de los usuarios afectados, y comunicando los resultados de nuestra investigación a las autoridades competentes.
• Sustitución de las credenciales de terceros de los usuarios afectados: enviamos el primer aviso el 28 de agosto a las 08:53 y el segundo aviso a las 17:03 de ese mismo día. Si aún no has completado estos pasos, todavía tendrás que revocar las credenciales indicadas en el aviso, crear otras nuevas, actualizar los ajustes de tus servicios, volver a desplegar los servicios implicados y revisar los registros de acceso y los cargos.
• Sustitución preventiva de credenciales: para reducir riesgos adicionales, recomendamos sustituir todas las credenciales que se hayan guardado alguna vez en una variable de entorno de Zeabur y sigan siendo válidas, incluidas las que no figuren en los avisos.

Mejoras de producto y de seguridad

Después del incidente redujimos lo que almacenamos de forma centralizada y limitamos los permisos de cada servicio a lo que su trabajo requiere, tras una revisión de cómo Zeabur guarda la información confidencial y accede a ella. El anuncio de la actualización de seguridad describe estas funciones y cómo implementarlas.

Implementado

Variables de entorno guardadas en tu propio servidor

El nuevo método de almacenamiento mantiene las variables de entorno directamente en tu Dedicated Server, en lugar de guardarlas de forma centralizada en la base de datos de Zeabur.

Los servicios nuevos utilizan este método de forma predeterminada. Los servicios existentes pueden migrarse desde la página de variables de entorno y, una vez completada la migración, las variables correspondientes se eliminan de la base de datos central de Zeabur. Esto se aplica actualmente solo a los Dedicated Servers. Los servicios que se ejecutan en clústeres compartidos no cambian de forma automática.

Esto solo cambia la forma en que se almacenan las variables. No invalida las credenciales antiguas, por lo que las credenciales implicadas en este incidente todavía deben sustituirse.

Eliminación de las credenciales SSH guardadas por Zeabur

En los servidores adquiridos recientemente, Zeabur ya no conserva contraseñas ni claves privadas de SSH. En los servidores existentes que admiten la migración, también se pueden eliminar desde los ajustes del servidor las credenciales que guarda Zeabur, sin que ello afecte a las demás funciones de gestión del servidor. También puedes consultar los registros de inicio de sesión SSH en la consola de Zeabur para ver el origen de los inicios de sesión correctos y de los intentos de inicio de sesión, y los ajustes del firewall te permiten limitar qué orígenes pueden conectarse a tu servidor.

Mejoras continuas

Aislamiento y supervisión de los sistemas en proceso de retirada

Seguiremos manteniendo el aislamiento, la supervisión y los controles de acceso en los sistemas en proceso de retirada, hasta que las cargas de trabajo que alojan se hayan migrado o hayan dejado de ejecutarse.

Autenticación, autorización y auditoría

Los Zeabur Access Tokens ya admiten ámbitos, de modo que los permisos pueden limitarse según su finalidad. También seguimos reforzando las comprobaciones de ámbito y autorización en nuestras API existentes, y ajustando la caducidad de los tokens de inicio de sesión, los permisos de los componentes, la autorización de recursos y el registro de operaciones sensibles.

Mientras ajustábamos los controles de acceso, las funciones relacionadas con GitHub, la gestión de variables de entorno y el correo electrónico se vieron afectados durante un tiempo. Estamos mejorando la forma en que validamos los cambios de antemano, para reducir el efecto de los ajustes posteriores sobre nuestros servicios.

Detección del incidente y comunicación con los usuarios

Solo confirmamos este incidente después de recibir un informe de uso abusivo de una clave de API el 28 de agosto a las 02:34. Una revisión posterior de los registros de la base de datos identificó el registro de intrusión más antiguo a las 07:54 del 27 de agosto. Nuestra supervisión y nuestras alertas de aquel momento no detectaron este acceso no autorizado.

Durante la investigación inicial, la falta de pruebas completas nos llevó a evaluar mal el alcance del impacto. Enviamos el primer aviso el 28 de agosto a las 08:53 y después el segundo a las 17:03. Pedimos disculpas por las molestias causadas por que ese primer aviso no cubriera todo el alcance del impacto, y estamos mejorando la forma en que verificamos el alcance y avisamos a los usuarios, para poder ofrecer instrucciones de remediación precisas antes, una vez confirmado un incidente.

Cronología principal

La tabla siguiente recoge la cronología confirmada en UTC. El primer uso registrado de una credencial no indica que el atacante la obtuviera y empezara a usarla de forma indebida en ese mismo momento.

Las actualizaciones anteriores están disponibles en la página de estado del incidente.

Soporte y compensació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 y te ayudaremos a revisar los registros pertinentes y los siguientes pasos. Antes de escribirnos, por favor:

• Revoca primero las credenciales afectadas, para reducir el riesgo de que vuelvan a utilizarse.
• Facilita únicamente información identificativa enmascarada.
• No incluyas claves, contraseñas ni otras credenciales completas y todavía válidas en un ticket de soporte ni en ningún canal público.

Si se abusó de la clave de API de un servicio de IA de terceros a causa de este incidente y ello generó cargos adicionales, envía una solicitud de compensación mediante un ticket de soporte. A continuación:

• revisaremos contigo los registros de uso del proveedor, el periodo de actividad inusual y los cargos
• procederemos con los trámites de compensación

Cierre

Entendemos el esfuerzo y las molestias adicionales que siguieron al incidente, que obligaron a nuestros usuarios a sustituir credenciales, revisar servicios y conciliar cargos. Pedimos sinceras disculpas por el riesgo y el trabajo adicional que ha causado este incidente.

Seguiremos llevando a cabo el soporte, la compensación y las mejoras previstas. Los avances posteriores se anunciarán en la página de estado del incidente y en publicaciones relacionadas.

Zeabur Team