Robo de API keys de IA en Railway: 740 mil dólares en cargos

El 10 de noviembre de 2026 Railway publicó el reporte de un ataque que debería leer cualquiera que tenga una llave de OpenAI, Anthropic, OpenRouter o Gemini. La plataforma confirmó que un atacante robó llaves de API de IA que sus clientes guardaban como variables de entorno, con un uso no autorizado estimado en unos 740,000 USD.

No es solo una historia sobre hosting. Es una historia sobre dónde viven tus credenciales: si automatizas con n8n o montas agentes, probablemente tienes varias en un .env o en el gestor de credenciales de n8n.

Qué pasó en Railway

Cómo entró el atacante

El 20 de octubre de 2026 el atacante explotó una vulnerabilidad desconocida en la infraestructura de builds de Railway. Escapó de forma parcial del aislamiento y obtuvo una credencial interna de los servidores de build. Con ella leyó el historial de 353 builds y una copia del monorepo —el código fuente—, y pudo buscar más fallas y moverse lateralmente.

Luego encontró una configuración de identidad mal hecha en el pipeline de despliegue y llegó a una máquina con una credencial capaz de descifrar variables de clientes.

Fue expulsado por completo a las 09:24 UTC del 21 de octubre. Railway detuvo los builds dos veces, rotó credenciales internas e invalidó todas las sesiones y tokens. Desde el 21 de octubre pidió a GitHub, GitLab, Anthropic, OpenAI, OpenRouter, SpaceXSI, Google y Stripe revocar las llaves en riesgo. Reconstruyó su CI con 2FA; cada build corre en una máquina virtual efímera con credencial mínima, cifrado y descifrado auditados; credenciales de corta vida y alcance mínimo.

Qué buscaba: llaves de IA

El 21 de octubre consultó la base de variables cifradas y priorizó las llaves de IA: filtraba nombres con expresiones regulares y prefería clientes con muchas variables. Otra consulta buscó credenciales de nube, bases de datos y pagos; la forense concluyó que no se accedió a bases de datos de clientes.

Descifró variables de máximo el 1.85% de los workspaces (~100,000), un límite superior, no el número confirmado de afectados. También descifró tokens de cuentas vinculadas —llaves BYOK de agentes y tokens OAuth de GitHub— de 1,852 usuarios. Railway los reseteó todos, avisó a cada usuario y no detectó inicios de sesión con ellos.

El incidente en cifras

Quién paga los 740 mil dólares

Railway trabaja con los proveedores para reembolsar y cubrirá lo que ellos no reembolsen.

Para quien automatiza, el reembolso depende de la política de cada proveedor y de que el caso se documente.

No fue un caso aislado

Railway dice que OpenCode, Warp, Fireworks AI y otros reportaron robos similares entre el 6 y el 23 de octubre: lo ve como una serie de ataques contra plataformas que guardan llaves de IA.

El objetivo, según Railway, era revenderlas a “estaciones de transferencia”, servicios que revenden o retransmiten acceso a proveedores de IA para destilar modelos. El atacante usaba modelos “abliterated”, sin salvaguardas; la defensa se volvió, según Railway, una competencia de velocidad de agentes.

El incidente forma parte de una serie de ataques contra plataformas que guardan llaves de IA, y la defensa se convirtió en una competencia de velocidad de agentes.

Railway, reporte de incidente del 10 nov 2026

Qué significa para quien automatiza con n8n y agentes

Tu llave de IA es dinero en segundos

Una llave de OpenAI, Anthropic, OpenRouter o Gemini con acceso amplio y sin límite de gasto no es solo una credencial: es una tarjeta sin PIN. El atacante no necesita entrar a tu n8n; le basta encontrar la llave en un repositorio, un .env o una variable mal protegida. Y no roba datos: gasta.

También tu VPS, tu Docker y tus credenciales de n8n

La lección no es “cámbiate de proveedor”, sino tratar las llaves como secretos de producción en Railway, Render, un VPS con Docker, el gestor de credenciales de n8n o el .env que nadie debería ver. El Taller: Introducción a n8n y configuración inicial ayuda a dejar las credenciales bien desde el principio; la Guía definitiva de migración a n8n v2.0 sirve para revisar flujos viejos.

OpenRouter con límites por llave

OpenRouter puede ser una capa de control: una llave con presupuesto acotado por proyecto o cliente. El Taller: Implementación de OpenRouter en n8n muestra cómo conectarlo a tus agentes. Y si transcribes audio, Transcribir audio con n8n + OpenRouter también depende de una llave de API que conviene proteger.

El gasto también puede venir de un bucle

No hace falta un atacante: un flujo de agentes en bucle puede quemar presupuesto en minutos. Los flujos de error y las alertas son control de gasto; en el Taller: Agentes, Subagentes y Flujos de Error en n8n se trabaja eso.

Checklist: protege tus API keys de IA esta semana

• Rota hoy las llaves que estuvieron en Railway antes del 21 de octubre y recarga las variables sensibles, como recomendó la compañía.
• Usa una llave por proyecto o cliente. Si una se filtra, el daño queda acotado.
• Activa límites de gasto y alertas de presupuesto en OpenAI, Anthropic, Google y OpenRouter.
• Nada de llaves en nodos Code, campos de workflow o JSON compartido: usa el gestor de credenciales de n8n.
• Aplica permisos mínimos. Una llave que solo lee no debe administrar la cuenta.
• Rota las demás llaves cada cierto periodo y revisa facturación y consumo cada semana.
• Configura flujos de error y alertas para que un fallo o un bucle te avise, no la factura.

Cursos para pasar de la alerta a la práctica

Conclusión

Railway no es el problema; es el aviso. El atacante no buscaba las apps de los clientes, sino las llaves que las hacen funcionar: una llave de IA robada se convierte en dinero inmediato. Cualquier lugar donde guardes la tuya —un VPS con n8n, Docker o un .env— es un objetivo posible.

Rotar, acotar, separar y vigilar caben en una tarde. Revisa tu consumo en los próximos días y repítelo cada semana. El orden cuesta menos que una factura de 740,000 dólares que no era tuya.

Fuentes

• Reporte oficial de Railway — 10 nov 2026.
• The Hacker News — 11 nov 2026.
• CSO Online — 11 nov 2026.