Railway y Heroku fueron vulnerados por su infraestructura compartida. Este es el patrón real, no un argumento de venta.

Dos plataformas que corren las aplicaciones de muchas otras personas publicaron incidentes de seguridad reales y confirmados en los últimos años: Railway en octubre de 2026, y Heroku en abril de 2022. Ambos están documentados por las propias empresas, no son rumores. Y ambos se remontan a la misma forma de riesgo subyacente: una vulnerabilidad en infraestructura que la plataforma opera en nombre de muchos clientes a la vez, que se convirtió en acceso a datos de clientes que no tenían nada que ver con la falla original.

Este artículo no dice “todas las plataformas han sido vulneradas” — eso sería falso, y no vamos a afirmarlo. Son dos incidentes reales y bien documentados, lo que realmente tienen en común, y lo que un modelo donde traes tu propio servidor cambia sobre ese patrón específico. Ya escribimos un desglose completo del incidente de Railway por separado: la brecha de Railway en variables de entorno. Este artículo mira el patrón en los dos incidentes.

Qué pasó realmente, en ambos casos

Railway, octubre de 2026. El reporte preliminar de Railway describe a un atacante que escaló privilegios dentro de la infraestructura de build de Railway, llegó a su entorno de CI, y desde ahí accedió a los sistemas que almacenan las variables de entorno de los clientes — desencriptando una parte de ellas. Según las propias cifras de Railway, hasta un 1.85% de todos los workspaces, unos 100,000, tuvieron variables de entorno potencialmente expuestas. El detalle completo y las palabras de Railway están en nuestro artículo dedicado a la brecha.

Heroku, abril de 2022. Un atacante obtuvo las credenciales de una cuenta de máquina de Heroku, dejadas en un repositorio privado archivado de GitHub que contenía el código fuente de Heroku. Ese acceso llegó a una base de datos de Heroku que almacenaba los tokens OAuth de la integración con GitHub de los clientes, y desde ahí a una base de datos interna de clientes, de donde se exfiltraron contraseñas de clientes hasheadas y con salt. Heroku hizo su divulgación el 15 de abril de 2022, revocó los tokens de la integración con GitHub, forzó un reseteo de contraseña para los usuarios afectados, y la integración con GitHub en sí quedó fuera de línea hasta el 25 de mayo de 2022. El equipo de seguridad de GitHub confirmó por separado que los tokens OAuth robados se usaron para acceder a repositorios privados en decenas de organizaciones, incluyendo npm.

El patrón detrás de ambos

En ningún caso un cliente hizo algo mal, y no fue un ataque de fuerza bruta contra una cuenta individual. En ambos casos, el punto de entrada fue una pieza de infraestructura que la plataforma opera de forma centralizada — el pipeline de build/CI de Railway, el control de código fuente interno y las credenciales de cuenta de máquina de Heroku — y el punto de salida fueron datos de un gran número de clientes sin relación entre sí, alcanzados a través de ese único sistema compartido.

Ese es el mecanismo real que vale la pena nombrar: en una plataforma multi-tenant, el sistema de build, el control plane y el cómputo que corre el código de los clientes suelen estar todos dentro del mismo perímetro interno de un solo operador. Una fuga de credenciales o un bug de escalada de privilegios en cualquiera de esos sistemas es potencialmente un camino hacia los datos de todos, porque “todos” comparten la infraestructura donde vive ese bug.

Qué cambia realmente un modelo con tu propio servidor — y qué no cambia

Lo escribimos con cuidado en el artículo de Railway y aplica aquí también: el control plane de Railyard también almacena las variables de entorno de los clientes de forma centralizada, encriptadas en reposo, de la misma manera general que cualquier plataforma que guarda secretos de clientes — Railway y Heroku incluidos. Una compromisión de la base de datos del control plane de Railyard y su clave de encriptación es el mismo tipo general de riesgo que carga cualquier almacén central de secretos, sin importar dónde corra el cómputo. Tener tu propio servidor no hace que esa base de datos desaparezca.

Lo que cambia es qué toca la copia desencriptada y activa de un secreto una vez que sale de ese almacén. En Railyard, las variables se desencriptan una sola vez, en el momento del despliegue, y se entregan a un servidor en la cuenta de nube propia de ese cliente específico — no a una flota de cómputo compartida que opera la plataforma misma. No hay un único pipeline de build o entorno de CI cuya compromisión le dé a un atacante un punto de apoyo en las aplicaciones en ejecución de otros clientes, porque no hay una flota compartida de aplicaciones en ejecución por la cual pivotar. El entorno activo de cada cliente es una máquina distinta en una cuenta distinta.

Esa es una afirmación angosta y específica: cierra un camino — un bug en la infraestructura compartida de la plataforma convirtiéndose en una ruta hacia los secretos activos de muchos clientes sin relación a la vez — no todos los caminos. No es una afirmación de que Railyard, o cualquiera, sea inmune a una brecha. Una empresa que te dice que no puede ser vulnerada es una empresa de la que deberías ser más escéptico, no menos.

Qué hacer realmente, en cualquier plataforma

• Rota los secretos en un calendario, no solo después de una divulgación. Una clave de API estática y de larga duración sentada en el panel de cualquier plataforma es un riesgo permanente, independiente de cualquier incidente puntual.
• Limita el alcance de las credenciales. Cuanto más pequeño el alcance de una sola clave robada, menos te cuesta una brecha de cualquier tipo.
• Pregunta qué hay que comprometer para llegar a un secreto desencriptado y en uso activo — no solo si los datos están “encriptados en reposo”. La encriptación en reposo es lo mínimo en todas partes; la pregunta real es cuántos sistemas compartidos hay entre un bug en otra parte de la plataforma y tus secretos realmente en ejecución.
• Lee los reportes de incidentes que las empresas realmente publican. Las divulgaciones de Railway y Heroku aquí son genuinamente informativas cuando separas lo que confirmaron de lo que se amplificó de forma secundaria — ve nuestro desglose de la brecha de Railway como ejemplo de esa separación.

Ve las comparaciones completas: Railyard contra Railway y Migrar desde Heroku.

Preguntas frecuentes

¿Han sido vulneradas todas las plataformas PaaS? No, y no lo estamos afirmando. Este artículo cubre dos incidentes específicos, confirmados y bien documentados — Railway (2026) y Heroku (2022) — no todas las plataformas del mercado.

¿Correr tu propio servidor hace imposible una brecha? No. El control plane de una plataforma siempre tiene que guardar tus secretos en algún lado antes de desplegarlos, y ese almacén sigue siendo un blanco en cualquier arquitectura, Railyard incluido. Lo que cambia es si un bug en la infraestructura compartida de build/cómputo de la plataforma puede convertirse en un camino hacia los secretos activos de otros clientes — en un modelo con tu propio servidor, no hay una flota de cómputo compartida por la cual ese bug pueda pivotar.

¿Cuál es el punto en común real entre los incidentes de Railway y Heroku? En ambos casos, el punto de acceso inicial fue infraestructura que la plataforma opera en nombre de muchos clientes a la vez (el pipeline de build/CI de Railway; el control de código fuente interno y las credenciales de cuenta de máquina de Heroku), y el impacto llegó a clientes que no tenían nada que ver con la vulnerabilidad original.

Fuentes

• Security Disclosure: Wednesday October 21st — blog oficial de Railway
• Preliminary Report: Oct 21st Security Incident — blog oficial de Railway
• April 2022 Incident Review — blog oficial de Heroku
• Incident 2413 — página de estado oficial de Heroku
• Security alert: Attack campaign involving stolen OAuth user tokens — blog oficial de GitHub
• Heroku Forces User Password Resets Following GitHub OAuth Token Theft — cobertura secundaria