Para: desarrolladores y operadores que ejecutan aplicaciones o bases de datos en Railway, la plataforma de alojamiento de aplicaciones (PaaS), en especial quienes guardan en variables de entorno claves de API de IA, de pagos, de GitHub, de la nube o credenciales de bases de datos.
Este artículo se basa en las publicaciones oficiales del blog de Railway (su comunicado, el informe preliminar y las guías para usuarios) y en su página de estado. No trata técnicas de ataque, que la empresa tampoco ha divulgado.
En desarrollo: este artículo se actualizará a medida que la organización publique más información
A las 11:00 UTC del 24 de octubre de 2026 (20:00 JST)Aún no se sabe
- Qué variables de entorno fueron descifradas (la empresa dice que no puede identificarlas)
- Si se accedió al código fuente (se confirmará en el informe final)
- Detalles del ataque
- Si las claves expuestas se han utilizado
El informe preliminar de la empresa está fechado el 22 de octubre; según la página de estado, estuvo disponible a las 16:38 UTC del 23 de octubre. La empresa dice que la investigación continúa y que publicará un seguimiento cuando concluya. No se indica fecha para el informe final.
La página de estado marcó el incidente como resuelto a las 22:06 UTC del 23 de octubre; las compilaciones y los despliegues funcionan con normalidad. Los nuevos registros siguen en pausa.
Qué deben hacer hoy los usuarios de Railway
Los pasos 1 y 2 se aplican a todos los usuarios. La empresa dice que el impacto puede ser limitado, pero recomienda estas acciones a todos como precaución.
Rote los secretos: vuelva a emitirlos en su origen y revoque los valores antiguos
La empresa pide revocar y volver a aplicar todas las variables de entorno sensibles almacenadas en Railway antes del 21 de octubre. Esto incluye claves de API y credenciales de registros privados.
Trabaje en este orden:
- Haga una lista de sus variables de entorno. Abra la pestaña Variables de cada servicio y marque los valores secretos (claves de API, tokens, contraseñas, claves de firma, cadenas de conexión)
- Emita valores nuevos en el panel de cada origen: la API de IA, el proveedor de pagos, GitHub, la nube, bases de datos externas, etc.
- Actualice las variables de Railway y vuelva a desplegar los servicios. Los contenedores leen las variables solo al iniciarse, así que siguen funcionando con los valores antiguos hasta que vuelva a desplegar (guía de la empresa)
- Cuando los valores nuevos funcionen, revoque o elimine los valores antiguos en el origen
Cambiar el valor solo dentro de Railway deja utilizable el valor expuesto hasta que lo revoque en el origen (nota de este sitio).
Si rotó antes de las 03:32 UTC del 22 de octubre
En su comunicado del 21 de octubre, la empresa pidió a los usuarios rotar de inmediato todas las variables de entorno. Más tarde dijo que a las 03:32 UTC del 22 de octubre confirmó que el atacante ya no tenía acceso a sus sistemas. El informe preliminar explica que quería expulsar al atacante antes de pedir a los usuarios que rotaran, para que las credenciales nuevas no volvieran a verse comprometidas enseguida. Por eso, conviene rotar una vez más los secretos rotados antes de las 03:32 UTC del 22 de octubre (nota de este sitio). La página de estado dice que esta actualización por sí sola no exige repetir las rotaciones ya completadas desde que se contuvo el incidente.
Bases de datos: regenere las contraseñas y elimine el acceso público
La empresa aconseja a todos los usuarios eliminar el acceso de red público a las bases de datos. Su guía dice que una base de datos con acceso público (el proxy TCP) habilitado puede alcanzarse con sus credenciales desde cualquier lugar de internet hasta que rote.
- En PostgreSQL, MySQL, Redis y MongoDB, use Regenerate en la vista de la base de datos. Cambia la contraseña dentro de la base de datos y las variables en un solo paso, y cierra las sesiones abiertas (guía de la empresa)
- No edite a mano variables de contraseña como POSTGRES_PASSWORD ni cambie la contraseña directamente en la base de datos. La variable y la base de datos quedan desincronizadas (guía de la empresa)
- Vuelva a desplegar todos los servicios que hagan referencia a las variables (por ejemplo
${{ Postgres.DATABASE_URL }}). Sustituya las cadenas de conexión pegadas por referencias - En Settings, Networking, desactive Public Access si nada fuera del proyecto lo necesita. Todo lo que esté fuera (desarrollo local, CI, herramientas de BI) necesita que pegue a mano el nuevo
DATABASE_PUBLIC_URL
GitHub y registros: revise los registros de auditoría y las aplicaciones conectadas
La empresa recomienda revisar los registros de auditoría de GitHub y el acceso de aplicaciones, así como los registros de auditoría de registros de contenedores como Docker Hub. Su guía enumera estas comprobaciones:
- Cuenta personal: el registro de seguridad de GitHub (90 días), las aplicaciones OAuth y GitHub Apps autorizadas, las claves SSH y GPG, y los tokens de acceso personal. Revoque lo que no reconozca y regenere los tokens
- Organización: el registro de auditoría de la organización (180 días). Exporte el registro antes de revocar nada. En cada repositorio, revise las deploy keys, los secretos, los webhooks y los colaboradores
- GitHub Container Registry (ghcr.io): Railway eliminó los tokens de GitHub que guardaba, pero esos tokens siguen funcionando en GitHub hasta que se revoquen. Elimine el token antiguo en GitHub, cree uno nuevo con el alcance read:packages y configúrelo en cada servicio
La guía también advierte de que un atacante con acceso de escritura puede añadir un webhook o un secreto que sobreviva a un restablecimiento de contraseña.
API de IA y pagos: busque usos y cargos que usted no hizo
Según el informe preliminar de la empresa, el atacante al parecer buscaba claves de API de proveedores de IA. La empresa ha publicado guías para comprobar el uso en OpenAI, Anthropic, OpenRouter, Grok, Stripe, AWS y GCP. La guía de OpenAI, por ejemplo, indica:
- Eliminar la clave posiblemente expuesta y crear una nueva en el mismo proyecto
- Abrir el uso, agrupar por clave de API y comparar el volumen de tokens, el número de solicitudes y la mezcla de modelos en la ventana de exposición con su tráfico normal
- Revisar la facturación del período y los créditos concedidos consumidos
- Revisar los miembros y la pertenencia al proyecto en busca de personas que no invitó
- Conservar los detalles de uso y contactar con el soporte del proveedor si encuentra un uso indebido
Revise como mínimo desde el inicio de la ventana de ataque (13:58 UTC del 20 de octubre) hasta que rotó la clave (nota de este sitio).
Dentro de Railway: vuelva a iniciar sesión, recree los tokens y vuelva a desplegar
Durante su respuesta, la empresa revocó todas las sesiones de inicio de sesión, los tokens de acceso de Railway, las conexiones de GitHub y las credenciales de los buckets de almacenamiento. Los commits enviados mientras los despliegues estaban en pausa no se desplegaron.
- Inicie sesión con la misma cuenta de Gmail, de GitHub o el mismo correo con que se registró. Iniciar sesión con otra identidad crea una cuenta nueva y vacía (guía de la empresa)
- Vuelva a conectar GitHub en la configuración de la cuenta, vuelva a conectar el repositorio en Settings del servicio y despliegue el último commit
- CLI: ejecute
railway logouty luegorailway login. CI: vuelva a crear el token de proyecto (RAILWAY_TOKEN) o el token de cuenta/workspace (RAILWAY_API_TOKEN) y reemplácelo en sus secretos de CI - Vuelva a desplegar los servicios que usan buckets para que tomen las nuevas credenciales. Revise también los buckets en busca de archivos que no subió o eliminaciones que no hizo (los buckets no tienen copias de seguridad automáticas, dice la empresa)
- En el registro de auditoría del workspace, busque lecturas de variables, cambios de credenciales de registros y despliegues en la ventana de exposición que no hayan hecho su equipo ni Railway (se muestra como "Railway Staff")
Secreto almacenado en Railway antes del 21 de octubre
Trátelo como expuesto, le hayan contactado o no
↓→
1. Emita un valor nuevo en el origen
Actualice la variable y vuelva a desplegar, luego revoque el valor antiguo
Base de datos con acceso público
Accesible desde internet con una contraseña filtrada
↓→
2. Regenere la contraseña y elimine el acceso público
Vuelva a desplegar todos los servicios que la referencian
API de IA, pagos, GitHub
Claves que el atacante al parecer buscaba
↓→
3. Revise el uso, los cargos y los registros de auditoría
Desde las 13:58 UTC del 20 oct hasta que rotó
Tenga cuidado con los mensajes que dicen ser del soporte de Railway
La empresa dice que enviará correos directamente a los clientes afectados. Su guía de recuperación de cuentas indica a los usuarios que no envíen al soporte contraseñas, códigos de inicio de sesión, códigos de recuperación, tokens de API ni valores secretos. Si un mensaje relacionado con este incidente pide valores secretos o códigos de inicio de sesión, suponga que no es genuino (nota de este sitio).
Los avisos de revocación de GitHub, OpenAI y otros proveedores responden a la solicitud de Railway, y la empresa dice que no implican que sus credenciales se vieran afectadas. No haga clic en los enlaces de esos mensajes; abra directamente el panel de cada proveedor.
Qué ocurrió (según Railway)
Lo siguiente se basa en las publicaciones del blog de Railway "Security Disclosure: Wednesday October 21st" (21 de octubre de 2026) y "Preliminary Report: Oct 21st Security Incident" (fechada el 22 de octubre; disponible a las 16:38 UTC del 23 de octubre, según la página de estado), y en su página de estado. Las horas son UTC.
20 oct, 13:58
La monitorización detecta actividad anormal en forma de latencia elevada; el ingeniero de guardia comienza a investigar.20 oct, 14:03–16:51
La actividad se identifica como un intento de escalada de privilegios por parte de un tercero externo hostil. Se encuentra una posible escalada de privilegios en la infraestructura de compilación y se detienen los pipelines de compilación.20 oct, 18:05–19:53
Se aplican mitigaciones y el exploit ya no puede reproducirse. A las 19:53, nuevas pruebas muestran que el atacante podía escalar el acceso a mayor escala en varias partes del sistema en paralelo.21 oct, 04:24–05:23
El análisis forense detecta que el atacante había extraído secretos en forma cifrada, sin poder descifrarlos en ese momento.21 oct, 05:27–07:25
El atacante obtiene credenciales del entorno de CI y descifra artefactos que contienen acceso adicional a API.21 oct, 07:25–09:18
Las pruebas en la base de datos muestran una consulta no autorizada de variables de entorno cifradas; un subconjunto fue descifrado mediante una combinación de credenciales comprometidas.21 oct, 09:25
Railway notifica a los proveedores las superficies a las que accedió el atacante y les pide revocar claves (las preguntas frecuentes del informe indican las 09:35).21 oct, 20:19–22:10
Railway anuncia la invalidación de las sesiones de usuario y publica su comunicado de seguridad y las indicaciones para los clientes.22 oct, 03:32
Railway confirma que el atacante ya no tiene acceso a ningún sistema interno y comienza a reinicializar los sistemas internos con credenciales nuevas.22 oct, 17:00–22:49
Se informa de la restauración completa de la API y de los despliegues normales para todos los planes.23 oct, 16:38
Se pone a disposición el informe preliminar fechado el 22 de octubre (página de estado).23 oct, 18:57
Se completan las notificaciones a los workspaces evaluados como de mayor riesgo (página de estado).23 oct, 22:06
La página de estado marca el incidente como resuelto. Los nuevos registros siguen en pausa.
- Qué ocurrió
- Un tercero no autorizado accedió a sistemas internos, obtuvo variables de entorno cifradas de los clientes y descifró un subconjunto de ellas
- Escala
- Como máximo el 1,85 % de todos los workspaces (unos 100 000 workspaces) tuvo algunas variables de entorno potencialmente comprometidas. Los registros de consultas por sí solos no permiten identificar qué variables concretas se vieron afectadas, porque las claves tenían cifrado de sobre (la clave que cifra los datos está a su vez cifrada con otra clave), dice la empresa
- Objetivo del atacante (evaluación de la empresa)
- Obtener claves de API de proveedores de IA para la "destilación" de modelos (entrenar otro modelo con las salidas de un modelo; explicación de este sitio). La empresa cree que forma parte de una serie de ataques dirigidos a empresas de plataformas con el objetivo de comprometer a proveedores de inferencia de IA
- Entornos de mayor riesgo
- Workspaces con un número muy grande de variables de entorno y entornos con muchas claves de proveedores de IA
- Declarado como no accedido
- No se inició sesión en cuentas de usuario de Railway
- Aún sin confirmar
- No se ha descartado el acceso al código fuente y se confirmará en el informe final
- Notificaciones a proveedores
- Railway notificó a GitHub, GitLab, Anthropic, OpenAI, OpenRouter, Google, Stripe y otros las claves potencialmente descifradas y les pidió revocarlas. A algunos proveedores les entregó todas las claves registradas en la plataforma, con independencia del impacto conocido. Más de 100 000 usuarios se vieron afectados por las solicitudes de restablecimiento a proveedores
- Impacto en el servicio
- Los servicios en ejecución siguieron en línea. Las nuevas compilaciones y despliegues, el panel, la API, la CLI y el soporte no estuvieron disponibles en algunos momentos
- Acciones de la empresa
- Apagó herramientas internas potencialmente comprometidas; rotó todas las claves y las rotó de nuevo tras validar que el intruso había sido expulsado; contrató a una empresa externa de análisis forense; trasladó los builders a entornos de un solo inquilino; rotó las credenciales de todos los buckets de almacenamiento; reconstruyó las herramientas internas a partir de código fuente validado; añadió una forma de revocar en masa los permisos de las aplicaciones de Railway
Qué se sabe y qué no
Situación a 24 de octubre de 2026. Esta tabla se actualizará a medida que la empresa publique más información.
| Elemento | Qué se divulgó | Estado |
|---|---|---|
| Variables de entorno cifradas obtenidas | Obtenidas mediante una consulta no autorizada | Confirmado (empresa) |
| Descifrado | Un subconjunto descifrado mediante una combinación de credenciales comprometidas | Confirmado (empresa) |
| Workspaces afectados | Como máximo el 1,85 % de todos los workspaces (unos 100 000) | Posible (empresa) |
| Qué variables fueron descifradas | No se puede identificar solo con los registros de consultas | En investigación |
| Credenciales de registros privados | Incluidas en la lista para rotación | Posible (empresa) |
| Cuentas de usuario | El atacante no accedió a cuentas de usuario de Railway | Negado (empresa) |
| Código fuente | Acceso no descartado; se confirmará en el informe final | En investigación |
| Servicios en ejecución | Siguieron en línea | Confirmado (empresa) |
| Ventana de ataque | De las 13:58 UTC del 20 oct a las 03:32 UTC del 22 oct | Confirmado (empresa) |
| Detalles del ataque | No divulgados, para proteger a los clientes | En investigación |
| Uso indebido de las claves expuestas | No indicado | No indicado |
| Hora en que se notificó a los proveedores | 09:25 UTC en la cronología del informe, 09:35 UTC en sus preguntas frecuentes | Inconsistente en el informe |
Cómo leer las cifras: qué cuentan los 100 000
Los "unos 100 000" del informe preliminar son el número de workspaces (el 1,85 % del total) que tuvieron algunas variables de entorno potencialmente comprometidas. El informe dice que más de 100 000 usuarios se vieron afectados por las solicitudes de revocación a proveedores, y que los clientes a los que contactó como de alto riesgo superan ese 1,85 %. Que le contacten, o que le revoquen una clave, no confirma una exposición. A la inversa, la empresa dice que los workspaces fuera de los grupos de mayor riesgo no están confirmados como seguros.
Por qué se buscan las claves de API de IA
Lo que sigue es general y no significa que estas cosas ocurrieran en este incidente. El objetivo que la empresa describe para este atacante es obtener claves de API de IA para la destilación de modelos.
Una clave de API de IA es dinero y capacidad de cómputo que puede gastar cualquiera que la tenga. Cuando se usa mucho una clave robada, la factura llega a su propietario. Cuando se recopilan grandes volúmenes de salidas a nombre del propietario, el proveedor puede suspender la cuenta por una infracción de política, como su prohibición de la destilación. Cómo funciona y cómo apelar se explica en por qué se bloquea una cuenta después de que le roban su clave de API.
Una plataforma de alojamiento guarda en un solo lugar las claves de muchos clientes. Es probable que por eso la empresa describa como de mayor riesgo los workspaces con muchas variables de entorno o muchas claves de IA. En el mismo mes, el desarrollador de LiteLLM también dijo que el atacante de su incidente buscaba sobre todo claves de proveedores de LLM (un incidente distinto; no se ha divulgado ninguna relación entre ambos). Para una visión más amplia de los ataques que usan IA o que apuntan a claves de IA, consulte cómo defenderse de los ciberataques impulsados por IA.
Qué deben revisar los usuarios de Railway: lecciones de los hechos divulgados
Esta sección no evalúa la respuesta de la empresa. Se centra en lo que los usuarios pueden hacer para estar preparados ante el próximo incidente, a partir de lo divulgado.
Suponga que el cifrado del lado de la plataforma no protege ante un compromiso de la plataforma
Las variables de entorno de Railway estaban cifradas, pero según el informe preliminar el atacante descifró un subconjunto mediante una combinación de credenciales comprometidas. Una plataforma de alojamiento tiene que convertir las variables de nuevo en valores en claro para ejecutar su aplicación, así que, una vez que se toman privilegios dentro de la plataforma, el cifrado por sí solo no puede protegerlas por completo (nota de este sitio).
Junto con el cifrado de la plataforma, guarde los secretos de modo que una filtración cause un daño limitado. Como primer paso, configure límites de gasto y alertas con sus proveedores de API de IA y de pagos. Separar las claves de producción, preparación y desarrollo también reduce lo que tiene que rotar. El almacenamiento de secretos se trata en qué es realmente peligroso de .env y las claves de API.
Mantenga las bases de datos fuera de internet público
Según la guía de la empresa, una base de datos con acceso público habilitado puede alcanzarse desde cualquier lugar de internet con una cadena de conexión filtrada. Una base de datos usada solo por la red privada del proyecto no es accesible directamente desde fuera aunque se filtre su cadena de conexión.
El acceso desde fuera suele necesitarse solo para desarrollo local, CI o herramientas de BI. Aun así, considere abrirlo solo mientras sea necesario, o usar un usuario aparte de solo lectura (nota de este sitio).
Comparta los secretos mediante referencias para que la rotación se haga en un solo lugar
La guía de la empresa recomienda compartir cadenas de conexión y claves mediante variables de referencia como ${{ Postgres.DATABASE_URL }} en lugar de pegarlas en cada servicio. Con referencias, cambiar el valor de origen y volver a desplegar llega a todos los servicios, y no se olvida ninguna copia pegada.
En el mismo espíritu, mantenga una lista actualizada de qué secreto usa cada servicio y dónde se vuelve a emitir (nota de este sitio). Cuando hay que rotarlo todo, como ahora, esa lista determina cuánto dura el trabajo. En un caso similar, el incidente de seguridad de Vercel, lo importante era si los secretos estaban almacenados en una categoría cuyos valores no se pueden mostrar después.
Limite las conexiones de GitHub a los repositorios y alcances que necesite
En este incidente la empresa revocó los tokens de GitHub que tenía y recomienda revisar los registros de auditoría de GitHub y el acceso de aplicaciones. Limite el acceso a GitHub que concede a una plataforma de alojamiento a los repositorios que despliega, y dé a los tokens de registros de contenedores solo acceso de lectura (read:packages), para que una filtración llegue a menos (nota de este sitio). El problema de las credenciales filtradas que siguen siendo válidas se trata en credenciales filtradas que siguen siendo válidas.
Fuentes (registro público)
Los hechos de este artículo se basan en las siguientes fuentes públicas. No se reproducen detalles del ataque.
- Railway, "Security Disclosure: Wednesday October 21st" (21 de octubre de 2026; la página de estado publicó "We have published a security notice" a las 22:10 UTC del 21 de octubre) — blog.railway.com
- Railway, "Preliminary Report: Oct 21st Security Incident" (fechado el 22 de octubre de 2026; disponible a las 16:38 UTC del 23 de octubre, según la página de estado) — blog.railway.com
- Railway, "Railway Platform Outage" (página de estado, consultada hasta la actualización "Resolved" de las 22:06 UTC del 23 de octubre) — status.railway.com
- Guías para usuarios de Railway (22–23 de octubre de 2026): "Rotate PostgreSQL Database Credentials" blog.railway.com / "Check for Anomalous GitHub Access" blog.railway.com / "Check for Unexpected OpenAI Usage" blog.railway.com / "Redeploy Buckets and Reconnect GitHub After the Credential Reset" blog.railway.com / "Recover Failing Deploys" blog.railway.com / "Resolving Login Issues" blog.railway.com
- Las guías para otros servicios (MySQL, Redis, MongoDB, Anthropic, OpenRouter, Grok, Stripe, AWS, GCP) figuran en el blog de ingeniería de la empresa — blog.railway.com
Historial de actualizaciones
2026-10-24: Primera versión, basada en el comunicado de Railway (21 de octubre), el informe preliminar (22 de octubre) y la página de estado (hasta la actualización de las 22:06 UTC del 23 de octubre). Corregida el mismo día tras comprobar las fuentes: la hora de publicación del informe preliminar ahora sigue a la página de estado (16:38 UTC, 23 de octubre), y el estado del acceso a cuentas de usuario ahora es "Negado (empresa)". El alcance del descifrado y si se accedió al código fuente se añadirán cuando se publique el informe final.
Lea a continuación
- Incidentes similares: qué deben hacer los desarrolladores tras el incidente de seguridad de Vercel / el compromiso de LiteLLM 1.107.0
- 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
- Almacenamiento de secretos: qué es realmente peligroso de .env y las claves de API / claves de API filtradas desde código escrito por IA
- Otros incidentes de 2026: lista de filtraciones de datos y ciberataques