Ciberseguridad
Railway y Zeabur: si guardas claves en un PaaS, rótalas hoy
¿Usas Railway o Zeabur? Ambas plataformas reportaron accesos no autorizados en octubre de 2026. Qué revisar hoy en tus variables, tokens y cuentas de API.
Si tu web, tu API o tus automatizaciones corren en Railway o Zeabur, rota hoy las variables de entorno y los tokens que guardaste allí. Las dos plataformas reportaron en octubre de 2026 accesos no autorizados a sus sistemas internos y piden a sus clientes cambiar secretos. Rotar solo dentro de la plataforma no basta: también hay que revocar la clave original en cada proveedor.
Qué informaron Railway y Zeabur
Los datos oficiales son parciales, así que conviene leer las fuentes primarias. Este es el resumen de lo que ambas empresas han publicado hasta hoy:
| Plataforma | Qué reportó | Qué pide a sus clientes |
|---|---|---|
| Railway | Un atacante accedió a sistemas internos y descifró variables de entorno de un subconjunto de espacios de trabajo. Según la empresa, como máximo el 1,85 % de los espacios podría estar afectado. Invalidó todos los tokens de API el 22 de octubre y reinició credenciales S3 y tokens de GitHub almacenados. | Rotar los secretos guardados en la plataforma. Railway no reembolsará el gasto fraudulento hecho con claves comprometidas. |
| Zeabur | Publicó un informe preliminar el 19 de octubre. Según su página de estado, hubo acceso a servidores de Google Cloud y lectura de la base de datos de la plataforma. Menciona variables de entorno, datos de cuenta, tokens de API y claves de zSend entre lo expuesto. | Cambiar la contraseña root de sus servidores, revisar claves SSH desconocidas y regenerar tokens y variables. |
Ninguna de las dos ha confirmado todo. Railway no ha revelado el vector de entrada y no descarta acceso al código fuente. Zeabur no ha confirmado si las credenciales usadas provienen de una brecha anterior. Por eso la recomendación es rotar todo, sin esperar a conocer el detalle.
Por qué te afecta aunque tu proyecto parezca pequeño
Un PaaS guarda los mismos secretos que un servidor propio: la URL de la base de datos, las claves de OpenAI o de otros modelos, las llaves de la pasarela de pagos, el SMTP y los accesos a almacenamiento. Quien obtiene una de esas claves no necesita entrar a tu panel; le basta con usarla. Ahí está el riesgo económico: consumo fraudulento de APIs que se cobra a tu tarjeta y datos de clientes que salen por una base de datos accesible.
Qué hacer hoy, en este orden
- Haz un inventario. Lista cada proyecto en Railway o Zeabur y qué variables guarda: base de datos, claves de IA, pagos, correo, tokens de GitHub.
- Revisa el consumo de cada proveedor de API. Entra a OpenAI, Stripe, tu proveedor de WhatsApp y tu almacenamiento S3 y busca cargos o llamadas de las últimas semanas que no reconozcas.
- Rota en el proveedor de origen, no solo en la plataforma. Crea la clave nueva en OpenAI, Stripe o el servicio correspondiente, actualiza la variable y revoca la anterior. Si la clave vieja sigue activa en el proveedor, quien la copió conserva el acceso aunque hayas cambiado la variable en Railway.
- Revoca tokens de GitHub y claves SSH desconocidas. Si Zeabur pide revisar su lista de claves, hazlo en tus servidores también.
- Revisa quién tiene acceso al panel. Quita a quien ya no participa en el proyecto y activa la verificación en dos pasos.
- Anota la fecha de rotación. Así sabrás qué secretos ya cambiaste y cuáles quedan pendientes.
Separa secretos por entorno y por servicio
La lección de fondo no depende de Railway ni de Zeabur. Una clave que sirve para todo es la que más daño hace cuando se filtra. Tres prácticas reducen el impacto:
- Una clave por servicio y por entorno. La de desarrollo no debe servir en producción.
- Límites de gasto en cada API. Así un abuso se corta en lugar de llegar a la factura del mes.
- Alertas de consumo. Un salto inusual de llamadas debe avisarte el mismo día.
Si quieres ver el mismo patrón en otro caso reciente, el ataque a LiteLLM expuso claves de IA de empresas por razones parecidas: lee cómo revisar las claves de IA de tu empresa.
Cuándo conviene pedir ayuda
Si encuentras consumo que no reconoces, o si no sabes en qué proyectos hay secretos guardados, es el momento de una revisión profesional. Revisamos accesos, rotación de claves y configuración de la infraestructura en nuestra práctica de ciberseguridad, y el diseño de entornos separados en infraestructura en la nube. Antes de contratar a cualquiera, pregunta cómo se rotan las claves y quién recibe las alertas de consumo.
Fuentes: informe preliminar de Railway y página de estado de Zeabur. Las cifras pueden cambiar cuando las empresas publiquen su informe final.
Preguntas frecuentes
¿Qué debo hacer si uso Railway o Zeabur?
Haz un inventario de las variables guardadas en cada proyecto, revisa el consumo de tus proveedores de API y rota cada clave en su proveedor de origen. Después revoca la anterior.
¿Basta con cambiar las variables en la plataforma?
No. Si la clave original sigue activa en OpenAI, Stripe o el proveedor que corresponda, cualquiera que la haya copiado puede seguir usándola. Hay que crear la clave nueva y revocar la vieja.
¿Me van a reembolsar el gasto fraudulento?
Railway indicó que no reembolsará el gasto hecho con claves comprometidas. Revisa tus condiciones con tu proveedor de API y tu banco, y activa límites de gasto para que un abuso no se acumule.
¿Cómo sé si mi negocio fue afectado?
No hay una prueba única. Revisa consumo inusual en tus APIs, accesos desconocidos a tu panel y cambios en variables que no hiciste. Si encuentras algo, documéntalo y rota los secretos afectados de inmediato.