La brecha de Railway: cómo rotar los secretos de tu app sin caídas

El 21 de octubre, Railway reveló que un tercero no autorizado había accedido a sistemas que almacenan variables de entorno de clientes y que, en algunos casos, el atacante podría haber obtenido su contenido descifrado. Railway pausó todos los despliegues, avisó a los proveedores afectados para que revocaran claves y pidió a todos sus usuarios que rotaran sus variables de entorno, incluidas las credenciales de registros privados.

Su informe preliminar aporta más detalles:

TechCrunch informa de que Railway cree que esto formaba parte de una campaña más amplia contra plataformas, con el objetivo de comprometer a proveedores de inferencia de IA. Esa misma semana, la herramienta de programación con IA OpenCode reveló que unos hackers se habían llevado API keys y otros secretos de más del 1% de sus clientes.

Las claves de IA robadas valen dinero de verdad. Los atacantes revenden el acceso o agotan tu cuota con sus propias cargas de trabajo, un patrón que los investigadores llaman LLMjacking. Una plataforma de hosting es un lugar muy eficiente para recolectarlas, porque miles de apps guardan en un mismo sitio sus claves de OpenAI, Anthropic, Stripe y su base de datos.

Hay un detalle incómodo en el informe de Railway. Las variables estaban cifradas, pero la plataforma tiene que poder descifrarlas para inyectarlas en tus builds y en tus servicios en ejecución. En cuanto el atacante tuvo el acceso interno adecuado, el cifrado en reposo no lo detuvo. Esto no es exclusivo de Railway. Cualquier host que ejecute tu código puede leer tus secretos.

Así que la pregunta no es "¿mi host es seguro?", sino "si mañana se filtraran los secretos de mi host, ¿qué tan grave sería y qué tan rápido podría recuperarme?"

Dedícale 20 minutos, aunque ya hayas pulsado "rotar" en algunas cosas.

1. Haz inventario de todos tus secretos. Lista los nombres de las variables de cada proyecto y entorno, incluidos staging y los entornos de preview. Si tienes un .env.example, es un buen punto de partida:

Para cada uno, anota qué desbloquea: una base de datos, un proveedor de pagos, un proveedor de IA, el email, un bucket de almacenamiento, un token de GitHub.

2. Revisa el uso y la facturación de tu proveedor de IA. Busca picos de uso, modelos que no reconoces o peticiones a horas raras desde el 20 de octubre. Es el lugar donde con más probabilidad aparecerá primero el abuso.

3. Revisa los logs de auditoría que tengas. Railway recomienda expresamente revisar los logs de auditoría de GitHub y el acceso de las apps instaladas, además de los logs de registros como Docker Hub. Mira también los logs de API de tu proveedor de pagos y los logs de conexión de tu base de datos.

4. Comprueba si tu base de datos es accesible desde internet. El informe de Railway recomienda eliminar el acceso de red público a las bases de datos. Si una cadena de conexión filtrada apunta a una base de datos a la que cualquiera puede conectarse, la filtración se puede aprovechar al instante:

5. Revisa lo que tu frontend ya está regalando. Brechas como esta recuerdan que hay que separar los secretos de verdad de los valores que son públicos por diseño. Una clave que viaja en tu bundle de JavaScript nunca fue secreta.

El error típico bajo presión es revocar primero la clave antigua y luego correr a desplegar la nueva mientras la app devuelve errores. Hazlo en este orden:

Recorre tu lista empezando por lo que más daño haría: claves de pagos, credenciales de base de datos, claves de cloud y almacenamiento, claves de proveedores de IA, tokens de GitHub y de registros, y después todo lo demás. Las indicaciones de Railway se centran en las variables configuradas antes del 21 de octubre, y sus recomendaciones posteriores añaden reconectar GitHub y recrear las credenciales de la CLI y de CI.

Algunos secretos requieren un cuidado especial:

No puedes evitar que hackeen a tu host. Sí puedes hacer que un secreto filtrado valga menos.

Limita el alcance de las claves. Usa claves restringidas cuando los proveedores las ofrezcan. Una clave restringida de Stripe que solo puede crear sesiones de checkout le sirve de mucho menos a un atacante que una secret key completa.

Pon un tope al gasto. Configura presupuestos mensuales y alertas de uso en cada proveedor de IA. Así, una sorpresa de cinco cifras se queda en un email.

Separa los entornos. No reutilices claves de producción en staging ni en despliegues de preview. Cada entorno debe tener sus propias credenciales para que una filtración en uno no entregue el otro.

Mantén privadas las bases de datos. Usa la red privada de tu plataforma y, si estás en Supabase, asegúrate de que Row Level Security esté activado para que una anon key filtrada no exponga tus tablas.

Nunca guardes secretos en archivos accesibles. Un archivo .env desplegado en tu web root se filtra sin necesidad de ninguna brecha.

Escribe ya tu runbook de rotación. La lista del paso 1, el orden de arriba y dónde se gestiona cada clave. La próxima vez, rotar te llevará una hora en lugar de un fin de semana.

Repásala para cada app que despliegues:

Railway hizo lo correcto al informar rápido y presionar para que se rotaran las claves. Pero esto les sigue pasando a las plataformas de hosting y de desarrollo, porque ahí es donde están las claves. Quienes salen de esto con calma son quienes saben qué secretos tienen y pueden cambiarlos en una tarde.

Ya que estás limpiando, vale la pena revisar también lo que tu app expone desde fuera. AppSafe escanea tu web en producción en busca de problemas comunes como API keys en bundles de JavaScript, archivos .env y .git expuestos y encabezados de seguridad ausentes, con soluciones explicadas en lenguaje claro. Nuestra checklist de lanzamiento para apps hechas con IA cubre el resto de lo básico.

Cuando lo hayas rotado todo, lanza un escaneo gratuito de AppSafe para asegurarte de que no se filtra nada más.