Hackeo de Railway: qué hacer con tus claves API y tus bots

El proveedor estadounidense de alojamiento Railway comunicó el 21 de octubre de 2026 que un tercero no autorizado pudo acceder a las variables de entorno guardadas de sus clientes y descifrar una parte de ellas. En esas variables hay claves API, accesos a bases de datos y, en muchos servicios cripto, también claves de exchange y claves privadas de cartera. Railway aconseja a todos sus clientes sustituir todas sus claves. La investigadora de seguridad Taylor Monahan cuenta ya salidas de unos 371.000 dólares de carteras cuyas claves estaban en Railway; Railway no ha confirmado esa relación. Cryptoticker también es cliente de Railway y recibió el aviso durante la noche.

Cómo se desarrolló el incidente, qué dicen las condiciones de Railway sobre la responsabilidad y por qué el caso es asunto de la política lo ha detallado nuestro fundador Dennis Weidner, con captura del correo a los clientes: Incidente de seguridad en Railway: por qué la responsabilidad termina en 100 dólares.

Hackeo de Railway: lo esencial en breve

• 21 de octubre de 2026, 21:59 UTC: Railway menciona el incidente de seguridad en su página de estado y aconseja revocar todas las variables de entorno.
• Unos 371.000 dólares salieron a partir de las 19:36 UTC según Taylor Monahan, en más de 500 transacciones desde más de 200 direcciones y en al menos 19 blockchains.
• Más de 2 millones de desarrolladores usan Railway, según datos propios. Cuántos clientes están afectados, la empresa no lo dice.
• 22 de octubre, 04:17 UTC: Railway invalida todos los tokens de la API de Railway de sus clientes.
• 100 dólares es el límite de responsabilidad en las condiciones de uso de Railway, cuando las tarifas de los últimos doce meses son inferiores.

Hackeo de Railway: lo que se sabe hasta ahora

Railway es una plataforma en la que los desarrolladores operan aplicaciones, bases de datos y servicios en segundo plano sin administrar servidores propios. Los proyectos cripto también recurren a plataformas así, por ejemplo para bots de trading, bots de Telegram y pequeños back-ends. La mañana del 21 de octubre la página de estado informó primero de una caída de la plataforma y se detuvieron las compilaciones. Por la tarde llegó el aviso de seguridad del fundador, Jake Cooper: Railway había detectado actividad anómala en los sistemas que guardan las variables de entorno y sospecha de una serie de ataques contra empresas de plataforma con el objetivo de comprometer a proveedores de IA (aviso de seguridad de Railway).

Cómo entraron los atacantes y qué clientes están afectados, Railway no lo dice por ahora. La propia empresa ha restablecido las credenciales de todos sus buckets de almacenamiento y las conexiones con GitHub, y el 22 de octubre invalidó todos los tokens de la API de Railway (página de estado del incidente). Las compilaciones volvieron a funcionar desde las 03:32 UTC para los clientes Enterprise y desde las 06:29 UTC para los clientes Pro; las tarifas menores seguían esperando al mediodía.

Salidas de carteras tras el hackeo de Railway: qué informan los analistas on-chain

Las primeras consecuencias llegaron antes del aviso. La investigadora de seguridad Taylor Monahan escribió en X durante la noche que las claves privadas de Railway se habían vaciado al parecer con un script de barrido muy extendido. Cuenta unos 371.000 dólares, más de 500 transacciones, más de 200 direcciones afectadas y al menos 19 blockchains EVM, a partir del 21 de octubre a las 19:36 UTC (Taylor Monahan en X). El servicio Onchain Lens informa de una supuesta cartera del atacante que habría enviado al menos 369.300 dólares al exchange HitBTC y a otras direcciones, y califica de no confirmada la relación con Railway.

Las dos cifras proceden de recuentos distintos y no se pueden sumar. Railway no ha confirmado las salidas. Llama la atención la cronología: las salidas empezaron dos buenas horas antes del aviso público de Railway. Si sustituiste tus claves solo después del correo, para una cartera afectada quizá ya fuera tarde.

Por qué los bots cripto están especialmente expuestos en el hackeo de Railway

Un bot de trading necesita acceso a un exchange, y un bot de arbitraje o de sniping a menudo acceso directo a una cartera. En plataformas como Railway ambas cosas acaban normalmente como variable de entorno: la clave API del exchange con su secreto, o directamente la clave privada de una cartera caliente. Quien abre ese almacén no necesita ninguna otra brecha. Una sola clave privada basta para mover un saldo a una dirección ajena en segundos, en todas las blockchains en las que esa misma dirección tenga fondos.

En las claves de exchange el daño depende de los permisos. Una clave sin derecho de retirada y con restricción de IP vale poco para un atacante; una clave con derecho de retirada es una cuenta abierta. Los pocos permisos que una herramienta fiscal o un bot necesita de verdad los mostramos en nuestra guía sobre comprobar las claves API en los exchanges cripto. Que una sola clave pueda sobrevivir a la toma de una cuenta lo mostró hace poco el caso de MEXC.

A eso se suma el motivo que Railway menciona él mismo: las claves de IA. Los accesos robados a modelos de lenguaje se revenden, y los investigadores de seguridad de Sysdig cifraban ya en 2024 el coste para una víctima en más de 46.000 dólares al día (Sysdig sobre el LLMjacking). Si usas funciones de IA en tu proyecto cripto, sustituye esas claves igual que los accesos al exchange.

Rotación de claves tras el hackeo de Railway: primero las carteras, después el exchange

Toda clave que estuviera en Railway se considera conocida hasta que se demuestre lo contrario. La sustitución se hace en el emisor, no solo en Railway. El orden lo marca lo que mueve dinero:

1. Las carteras primero. Si una clave privada o una frase semilla estaba en una variable, pasa el saldo de inmediato a una dirección nueva con una clave nueva, mejor a una cartera hardware; qué dispositivos sirven lo muestra nuestra comparativa de carteras hardware. Cambiar el nombre de la variable no protege de nada.
2. Revoca las claves del exchange. Borra las claves API antiguas directamente en el exchange y crea nuevas, sin derecho de retirada y con una dirección IP fija. Revisa la lista de direcciones de retirada permitidas. Para los bots encajan mejor los exchanges con reglas claras para los permisos de API; nuestra comparativa de exchanges cripto regulados ofrece una visión general.
3. Lee los registros. Mira en cada exchange y cada servicio si desde el 21 de octubre hubo accesos desde direcciones IP ajenas, u órdenes y retiradas que no conozcas.
4. Sustituye las claves de IA y de pago. Railway menciona expresamente en sus guías OpenRouter, Grok, Anthropic, OpenAI y Stripe. Fija ahí límites de gasto.
5. Protege las bases de datos. Contraseñas nuevas, conexiones abiertas cerradas. Si contienen datos de clientes, corre el plazo de 72 horas para notificarlo a la autoridad de protección de datos.

Responsabilidad: Railway paga 100 dólares como máximo

Railway no ha anunciado ninguna indemnización. Las condiciones de uso, en su versión del 20 de abril de 2026, excluyen los daños indirectos, la interrupción de la actividad y la pérdida de datos, y limitan todo lo demás a 100 dólares o a las tarifas de los últimos doce meses, según lo que sea mayor (condiciones de uso de Railway). Según las versiones archivadas, la cláusula figura en el contrato palabra por palabra desde 2021. Se aplica el derecho de Delaware y los litigios van a un arbitraje en San Francisco. Para una cartera de bot vaciada, la pérdida es tuya. Por qué esto es un problema de fondo para las empresas alemanas, y a quién dirigirse en el plano político, lo expone el análisis de Dennis Weidner.

PHP2Shell: una segunda vulnerabilidad crítica la misma semana

El mismo 21 de octubre aparecieron actualizaciones para PHP2Shell, dos fallos en PHP con 9,2 puntos sobre 10 por los que un atacante puede ejecutar código en servidores web sin autenticarse. Están corregidos en PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35 (php.net). La oficina alemana BSI aconseja desconectar de la red, si hace falta, los sistemas sin parchear. Para los usuarios cripto lo esencial es esto: en servicios con tecnología PHP antigua, como tiendas pequeñas o páginas de pago con caja cripto, conviene no reutilizar las credenciales. Reunimos más casos en nuestra sección de hackeos y seguridad cripto.

Este artículo no constituye asesoramiento de inversión. Lo actualizaremos en cuanto Railway indique la vía del ataque o el número de afectados.