Para: desarrolladores y operadores que despliegan aplicaciones o bases de datos en Zeabur, la plataforma de despliegue de aplicaciones (PaaS), en especial quienes guardan en variables de entorno claves de API de servicios de IA, de pago, de la nube o credenciales de bases de datos. Este artículo se basa en el informe preliminar oficial de Zeabur y en su anuncio de cierre, y no trata técnicas de ataque.
En desarrollo: este artículo se actualizará a medida que la organización publique más información
- A quién afecta
desarrolladores y operadores que despliegan aplicaciones o bases de datos en Zeabur, la plataforma de despliegue de aplicaciones (PaaS), en especial quienes guardan en variables de entorno claves de API de servicios de IA, de pago, de la nube o credenciales de bases de datos.
- Confirmado hasta ahoraVer la tabla ↓
- Variables de entorno en la base de datos de la plataforma
- Datos de cuentas
- Claves de API de zSend
2 más
- Access Tokens de la plataforma
- Los que la empresa llama GCP Dedicated Servers
- Aún sin confirmar
- Cómo obtuvo el atacante las credenciales iniciales
- Cuántos datos se extrajeron realmente de las bases de datos del clúster compartido
- Si se descargaron copias de seguridad y otros objetos almacenados
1 más
- Si se usaron los tokens filtrados de los que la empresa llama Hetzner and DigitalOcean Dedicated Servers
- Qué hacer ahoraVer los pasos ↓
- Revoque cada secreto de sus variables de entorno en el servicio que lo emitió
- Usuarios del clúster compartido: cambien también las contraseñas dentro de la base de datos
- Vuelva a crear los Access Tokens de Zeabur y las claves de API de zSend
4 más
- Si conectó GitHub, revise su registro de auditoría del 15 de octubre
- Revise el uso y las facturas desde el 14 de octubre
- Si perdió dinero, presente una reclamación antes del 30 de noviembre de 2026
- Usuarios de Dedicated Servers: traten el servidor como comprometido si está dentro del alcance
- Dónde verificarlo (fuente)Todas las fuentes ↓
- Zeabur, «Zeabur October 2026 security incident (preliminary report)» (19 de octubre de 2026)
- Última comprobación
- A fecha del 31 de octubre de 2026
Próximos avisos y qué comprobamos
El informe del 19 de octubre dice: «La investigación continúa y actualizaremos este artículo a medida que avance». El 31 de octubre la página seguía mostrando el 19 de octubre como fecha. El único aviso posterior en el blog de la empresa es una publicación del 22 de octubre sobre reembolsos y reclamaciones por el incidente, que no actualiza la investigación.
Qué deben hacer hoy los usuarios de Zeabur
Revoque cada secreto de sus variables de entorno en el servicio que lo emitió
Esto incluye claves de API (servicios de IA, pagos, correo electrónico), claves de la nube, contraseñas de bases de datos y claves de firma y de cifrado. El orden que indica la empresa es: revocar primero el valor antiguo en el proveedor del servicio, y después crear uno nuevo, ponerlo en Zeabur y volver a desplegar.
Borrar o editar la variable solo en Zeabur no detiene una copia que alguien ya tenga. Esto se aplica aunque sustituyera el valor tras el incidente de agosto, porque la empresa dice que la rotación de agosto no cubrió las credenciales usadas esta vez.
Usuarios del clúster compartido: cambien también las contraseñas dentro de la base de datos
La empresa dice que cambiar las variables de entorno en Zeabur no cambia las contraseñas dentro de la base de datos. Cambiar las contraseñas tampoco deshace la filtración de datos que ya se hayan filtrado. Si su base de datos almacena hashes de contraseñas, sesiones de inicio de sesión o tokens de sus propios usuarios, revóquelos y vuelva a generarlos también.
La empresa también pide a los usuarios que:
- n8n: sustituyan la clave de cifrado de n8n y vuelvan a crear todas las credenciales de terceros almacenadas en n8n
- new-api/one-api: revoquen las claves de los servicios de IA de origen y vuelvan a generar los tokens de acceso
- PostgreSQL: busquen roles, funciones, disparadores, tareas programadas o extensiones que no reconozcan; en caso de duda, creen una base de datos nueva e importen solo los datos
- Regiones de Taipéi (tpe1) y Hong Kong (hkg1): traten como filtrados los datos de las copias de seguridad de las bases de datos
Vuelva a crear los Access Tokens de Zeabur y las claves de API de zSend
La empresa dice que se cerró la sesión de todos los usuarios y se revocaron todos los Access Tokens de la plataforma. Vuelva a iniciar sesión, cree tokens nuevos en la página de Access Token y compruebe si hay solicitudes que no reconozca. Los usuarios de zSend tienen que volver a crear sus claves de API de zSend (las 566 se han revocado).
Si conectó GitHub, revise su registro de auditoría del 15 de octubre
La empresa dice que se leyó la clave privada de la Zeabur GitHub App, que se sustituyó a las 18:54 UTC del 15 de octubre, y que hasta ahora no ha encontrado indicios de su uso. Pide a los usuarios que revisen en su registro de auditoría de GitHub las acciones de la Zeabur GitHub App entre las 15:05 y las 18:54 UTC del 15 de octubre: clonaciones o pushes inesperados, nuevas deploy keys y webhooks modificados.
Revise el uso y las facturas desde el 14 de octubre
Revise el uso y las facturas de cada servicio cuyas claves almacenó, desde el 14 de octubre de 2026. La empresa dice que esa es la fecha del primer uso conocido de las credenciales, no una prueba de que no se filtrara nada antes. Los usuarios de los Dedicated Servers etiquetados como «GCP Dedicated Servers» deben remontarse al 1 de septiembre. Para saber por qué las claves de IA robadas se convierten rápido en facturas, consulte claves de API robadas y bloqueos de cuentas.
Si perdió dinero, presente una reclamación antes del 30 de noviembre de 2026
El aviso de la empresa del 22 de octubre dice que las reclamaciones por pérdidas derivadas del incidente de octubre deben presentarse como un ticket aparte al soporte de Zeabur (Zeabur Support) a más tardar el 30 de noviembre de 2026, y que solo se aceptarán las presentadas hasta esa fecha. Pide las cuentas y servicios afectados, los tipos de claves o credenciales filtradas y las facturas o registros de uso de terceros que cubran el periodo del incidente. Las reclamaciones se tramitan por separado de los reembolsos del saldo de la cuenta.
Usuarios de Dedicated Servers: traten el servidor como comprometido si está dentro del alcance
Para los Dedicated Servers etiquetados como «GCP Dedicated Servers», la empresa dice que se trate el servidor como comprometido. Haga una copia de seguridad de sus datos y reconstruya el servidor; es la forma más fiable de eliminar cualquier cosa que haya quedado. Si no puede reconstruirlo enseguida, los pasos mínimos que indica la empresa son eliminar las claves SSH que no reconozca, revisar cuentas, tareas programadas y servicios, cambiar la contraseña de root y desactivar el inicio de sesión con contraseña en SSH, y sustituir todas las credenciales del servidor. El informe de la empresa enumera las señales que hay que buscar; compruébelas en la página oficial.
Para los servidores que la empresa llama «Hetzner and DigitalOcean Dedicated Servers», pide comprobar en la consola del proveedor si la contraseña de root se restableció o el sistema se reinstaló después del 14 de octubre.
Qué pasó (según el informe de Zeabur)
Lo siguiente se basa en el informe preliminar de Zeabur del 19 de octubre de 2026 (publicado también en japonés y en otros cuatro idiomas). Todas las horas están en UTC.
Agosto de 2026
Otro incidente de seguridad, distinto, en Zeabur. La empresa dice que la rotación posterior no cubrió las credenciales usadas en octubre.14 de octubre, 01:36
Primer uso conocido por parte del atacante de una clave interna de la nube de Zeabur, seguido del acceso al clúster compartido.15 de octubre, 13:56
Zeabur inicia su investigación tras el aviso de un usuario.15 de octubre, 16:10–16:47
El atacante lee la base de datos de la plataforma (confirmado por la empresa).15 de octubre, 20:25
Zeabur rota su clave de firma de inicio de sesión; se cierra la sesión de todos los usuarios.15 de octubre, 21:05
Última actividad del atacante observada hasta ahora.17 de octubre
Zeabur anuncia que cerrará el 31 de diciembre de 2026.19 de octubre
Zeabur publica su informe preliminar sobre el incidente.22 de octubre
Zeabur fija el 30 de noviembre de 2026 como plazo para las reclamaciones por el incidente y dice que los datos de los servicios se borrarán el 31 de diciembre.
Almacenadas en Zeabur: leídas
Variables de entorno guardadas en la base de datos de la plataforma Zeabur, incluidos los proyectos que nunca las trasladaron
Trasladadas a su propio Dedicated Server después de agosto
Fuera de la lectura de la base de datos de la plataforma. Si el propio servidor estaba dentro del alcance, sus secretos también hay que sustituirlos
La empresa pide a todos los usuarios que sustituyan los secretos en cualquier caso. Esta división solo indica cuán segura es la exposición.
- Qué pasó
- Un atacante usó credenciales internas filtradas de Zeabur para entrar en el clúster compartido, en algunos Dedicated Servers y en sistemas internos, y leyó la base de datos de la plataforma
- Datos leídos
- Variables de entorno (3.218.965 registros), datos de cuentas (321.810 cuentas), claves de API de zSend (566), además de Access Tokens de la plataforma almacenados como hashes irreversibles (11.536, todos revocados)
- Otros sistemas
- Se ejecutaron comandos dentro de 865 contenedores de bases de datos del clúster compartido; se confirmaron inicios de sesión como root en 101 de los servidores que la empresa llama GCP Dedicated Servers
- Causa (empresa)
- Credenciales de administración de larga duración almacenadas en texto claro y utilizables desde internet. La empresa dice que la causa de fondo es responsabilidad de Zeabur
- Respuesta
- Credenciales usadas revocadas, acceso SSH público a las interfaces de administración y a los servidores bloqueado, sesión cerrada para todos los usuarios, todos los Access Tokens revocados
- Compensación
- Los cargos adicionales en claves de API de terceros o cuentas en la nube causados por el incidente pueden reclamarse mediante un ticket de soporte, hasta el 30 de noviembre de 2026 (aviso del 22 de octubre)
Qué se sabe y qué no
Situación a fecha del 31 de octubre de 2026. Los términos propios de la empresa son «confirmado» (un registro lo recoge directamente), «evaluado» (el momento y el contenido coinciden, pero no hay registro directo), «no se puede confirmar» (no hay registros que revisar; se trata como filtrado) e «hipótesis» (una explicación posible respaldada solo por indicios indirectos). La columna de estado sigue esos términos. Cuando haya una actualización, se actualizará.
| Elemento | Qué dice el informe | Estado |
|---|---|---|
| Variables de entorno en la base de datos de la plataforma | 3.218.965 registros (nombres y valores) leídos | Confirmado (empresa) |
| Datos de cuentas | 321.810 cuentas: correo electrónico, nombre de usuario, número de teléfono y más, además de datos de proyectos | Confirmado (empresa) |
| Claves de API de zSend | 566 claves almacenadas en texto claro, todas revocadas | Confirmado (empresa) |
| Access Tokens de la plataforma | 11.536 tokens almacenados solo como hashes irreversibles, todos revocados | Confirmado (empresa) |
| Variables de entorno y secretos del clúster compartido | 9 regiones; una parte confirmada, el resto tratado como filtrado | Confirmado en parte; el resto no se puede confirmar (empresa) |
| Contenido de las bases de datos del clúster compartido | Comandos ejecutados en 865 servicios de bases de datos; no se puede confirmar cuánto se extrajo | Evaluado (empresa) |
| Los que la empresa llama GCP Dedicated Servers | Inicios de sesión como root confirmados en 101 servidores (92 usuarios) | Confirmado (empresa) |
| Copias de seguridad de bases de datos (Taipéi tpe1, Hong Kong hkg1) | No se puede confirmar si se descargaron. Por otra parte, la empresa dice que las pruebas en un host comprometido confirman que a las 15:42 UTC del 15 de octubre el atacante obtuvo una copia de seguridad de la base de datos de un cliente | No se puede confirmar (empresa) |
| Los que la empresa llama Hetzner and DigitalOcean Dedicated Servers | Tokens de administración filtrados; no se puede confirmar si se usaron | No se puede confirmar (empresa) |
| Datos de autenticación de dos factores y de passkeys | Solo se consultaron estadísticas; no hay registro de que se leyera su contenido | Sin registro de lectura del contenido (empresa) |
| Cómo se obtuvieron las credenciales iniciales | No se puede confirmar; un vínculo con agosto es una hipótesis no confirmada | No se puede confirmar (empresa) |
| Uso indebido de claves filtradas | La clave de un servicio de IA de un usuario se usó para unas 1.107 solicitudes el 16 de octubre; la empresa dice que es una hipótesis que procediera de esta filtración | Hipótesis (empresa) |
Cómo leer esto: «no se puede confirmar» también significa rotar
La empresa dice que, cuando no se puede descartar un acceso no autorizado, da por hecho que los datos pueden haber quedado expuestos. Para sus propios secretos, la diferencia práctica entre «confirmado», «evaluado» y «no se puede confirmar» es pequeña: todos significan revocar y sustituir.
A qué pueden llevar las variables de entorno filtradas
En general, los secretos obtenidos de variables de entorno pueden usarse indebidamente de las siguientes formas. Esto no significa que todo ello haya ocurrido aquí.
- Claves de API de servicios de IA: otra persona envía solicitudes con su cuenta y usted recibe la factura. La empresa observó que el atacante buscaba sobre todo claves que pudiera usar directamente, en especial claves de servicios de IA
- Contraseñas de bases de datos y cadenas de conexión: leer o modificar los datos de su aplicación, incluidos los registros de sus propios usuarios
- Claves de firma y de cifrado: falsificar tokens de sesión o descifrar datos que su aplicación protege
- Claves de la nube y de pago: crear recursos o hacer llamadas que cuestan dinero
Un ejemplo anterior: tras el incidente de las variables de entorno de Railway, la empresa de alojamiento envió a los servicios emisores listas de claves posiblemente expuestas para que pudieran revocarse. Este caso puede no seguir el mismo curso, así que revoque usted mismo sus claves.
Para operadores: lecciones de lo que divulgó la empresa
Estos puntos proceden de la causa y las carencias que la propia empresa enumeró. No son un juicio adicional sobre Zeabur.
- Ponga caducidad a los tokens de administración y mantenga las interfaces de administración fuera de internet. La empresa dice que los tokens de administración de su clúster no caducaban, no se habían rotado desde enero de 2024 y que la interfaz de administración era accesible desde internet.
- Tras un incidente, rote todas las credenciales que pudieron leerse, no solo las confirmadas como filtradas. La empresa dice que la rotación de agosto no cubrió las credenciales usadas en octubre.
- No guarde secretos en texto claro en las copias de seguridad y mantenga aparte las claves de las copias. La empresa dice que las copias de seguridad del clúster contenían todos los secretos y que una clave rotada durante la respuesta quedó recogida en una copia posterior.
- Configure alertas ante lecturas masivas de secretos. La empresa dice que más de 16 horas de actividad el 14 de octubre no generaron ninguna alerta y que el incidente se descubrió tras el aviso de un usuario.
Para sus propias aplicaciones, el secreto más seguro es el que la plataforma nunca almacena: credenciales de corta duración, o un almacén de secretos aparte que su aplicación lee en tiempo de ejecución (consulte qué es realmente peligroso de .env y las claves de API).
Fuentes (registro público)
Los hechos de este artículo se basan en la información pública siguiente. No se especula sobre vías de intrusión que la empresa no haya confirmado, y no se reproducen aquí indicadores de compromiso.
- Zeabur, «Zeabur October 2026 security incident (preliminary report)» (19 de octubre de 2026) — zeabur.com
- Zeabur, «Zeabur service migration, refunds, and security incident claims» (22 de octubre de 2026) — zeabur.com
- Zeabur, «Zeabur is shutting down: what happens next» (17 de octubre de 2026) — zeabur.com
Historial de actualizaciones
2026-10-31: Primera versión, basada en el informe preliminar de Zeabur del 19 de octubre, su anuncio de cierre del 17 de octubre y su aviso del 22 de octubre sobre las reclamaciones por el incidente. A fecha del 31 de octubre, no aparece ningún informe de investigación posterior en el blog de la empresa. Actualizaremos este artículo cuando haya novedades.
Lectura recomendada
- Incidente del mismo tipo: Variables de entorno de Railway posiblemente expuestas (octubre de 2026) / Brecha de OpenCode Console (octubre de 2026)
- Por qué se buscan las claves de IA: cómo defenderse de los ciberataques impulsados por IA / claves de API robadas y bloqueos de cuentas
- Claves filtradas que siguen siendo válidas: credenciales filtradas que siguen siendo válidas
- Otros incidentes de 2026: Filtraciones de datos y ciberataques de 2026