XPoint News · 11 de noviembre de 2026

Un ataque contra la fábrica de software

Railway publicó el informe técnico de un ataque que encadenó vulnerabilidades, atravesó su infraestructura de construcción y permitió descifrar variables de entorno de una parte de sus clientes. La investigación concluye que el objetivo principal eran claves de proveedores de inteligencia artificial. Su uso no autorizado habría generado aproximadamente US$740.000 en cargos.

Railway es una plataforma cloud utilizada para construir, desplegar y operar aplicaciones. En estos entornos, las variables de ambiente suelen contener claves de APIs, credenciales de bases de datos, tokens de GitHub, accesos cloud y secretos necesarios para que una aplicación funcione.

El 20 de octubre, el atacante comenzó a probar la infraestructura de builds. Railway afirma que explotó una vulnerabilidad desconocida para escapar parcialmente del aislamiento del sistema de archivos de una máquina virtual multi-tenant. Desde allí obtuvo una credencial utilizada por los servidores de construcción para comunicarse con servicios internos.

Una alerta por llamadas anómalas a un registro de artefactos permitió detectar la actividad. Railway revocó la primera credencial y corrigió la ruta inicial, pero el atacante ya había accedido a información suficiente para continuar buscando nuevas entradas.

Del historial de builds al código interno

La credencial comprometida debía autorizar tareas limitadas, como publicar imágenes después de una compilación. Sin embargo, un clúster interno de Temporal la aceptaba como cliente confiable. El atacante utilizó esa relación para consultar historiales de builds que contenían variables, metadatos y tokens de acceso restringidos.

También recuperó una copia del monorepo interno de Railway desde un snapshot de construcción. Esa visibilidad reveló cómo estaban conectados los sistemas y facilitó la búsqueda de rutas antiguas o poco utilizadas. Railway observó al actor consultando endpoints sin referencias activas desde hacía semanas, meses o años.

El informe sostiene que el adversario utilizó múltiples agentes en paralelo y modelos modificados para reducir sus restricciones. Esa evaluación describe la velocidad y amplitud de la exploración observada, pero Railway no identifica públicamente los modelos ni atribuye la operación a un grupo específico.

La segunda entrada condujo a los secretos

El atacante encontró una configuración OIDC incorrecta dentro del sistema CI/CD y obtuvo una credencial cloud temporal. Con ella recuperó otras credenciales internas y accedió por SSH a una máquina de orquestación conectada con la red privada donde residía la base de datos de variables cifradas.

Las variables utilizaban cifrado por envolvente: cada ambiente tenía una clave de datos protegida a su vez por una clave raíz en un servicio de gestión de claves. La máquina de orquestación necesitaba una credencial de mayor duración para descifrar variables al aprovisionar workloads. Esa credencial, combinada con el acceso a la red interna, permitió extraer y descifrar una parte de los secretos almacenados.

Los registros muestran que el atacante buscó específicamente nombres de variables asociados con proveedores de IA. Otra consulta también coincidió con credenciales cloud, bases de datos y servicios de pago. Railway afirma que su análisis no encontró evidencia de acceso directo a bases de datos de clientes.

Hasta 100.000 workspaces y 1.852 usuarios con tokens vinculados

Railway pudo validar que, como máximo, alrededor de 100.000 workspaces tuvieron ambientes desde los cuales alguna variable pudo ser descifrada. Como los registros identifican ambientes y no cada secreto individual, la empresa presenta la cifra como un límite superior.

El atacante también leyó historiales almacenados de 353 builds. Los datos descifrados incluyeron tokens de cuentas vinculadas —claves de agentes aportadas por el usuario y tokens OAuth de GitHub— correspondientes a 1.852 usuarios. Railway restableció esos tokens y dice no haber identificado ingresos a cuentas de Railway mediante credenciales obtenidas en el incidente.

La compañía pidió a GitHub, GitLab, Anthropic, OpenAI, OpenRouter, SpaceXSI, Google y Stripe que revocaran claves potencialmente comprometidas. Algunas empresas ampliaron el alcance de las revocaciones como precaución.

LLMJacking: robar capacidad de IA sin pagarla

Railway cree que las claves de IA fueron el objetivo principal. Los atacantes pueden utilizar credenciales ajenas para consumir modelos, operar agentes, ejecutar pipelines de entrenamiento o revender el acceso mediante gateways clandestinos. Esta práctica se conoce como LLMJacking.

La empresa observó cargas que iban desde agentes de programación hasta pipelines de entrenamiento. También recibió evidencias de clientes sobre solicitudes para analizar el comportamiento de agentes y evaluar tareas de entrenamiento. Railway considera que las claves pudieron distribuirse mediante servicios intermediarios, aunque no ha establecido si el atacante original operaba esas plataformas.

El gasto no autorizado estimado llegó a unos US$740.000. Railway dice que trabaja con los proveedores para reembolsarlo y que cubrirá los montos cuando los proveedores no lo hagan.

Por qué este caso importa más allá de Railway

Las variables de entorno se han convertido en una bóveda informal para la economía cloud. Una sola plataforma puede concentrar acceso a repositorios, modelos, bases de datos, almacenamiento, pagos y producción. El cifrado en reposo protege los datos almacenados, pero no resuelve el problema cuando un componente autorizado para descifrarlos queda comprometido.

El caso también muestra el riesgo de credenciales con confianza implícita entre sistemas. La primera clave no tenía por qué abrir toda la plataforma; la arquitectura permitió utilizarla en un servicio que la trató como cliente confiable. La combinación de permisos, conectividad y conocimiento del código amplió progresivamente el alcance.

Rotar únicamente las claves de IA sería insuficiente. Si un ambiente contenía accesos a bases de datos, cloud, pagos, registros de contenedores o GitHub, cada secreto debe considerarse de manera independiente y revisarse por el impacto que podría producir.

Recomendaciones de XPoint

• Rotar todos los secretos expuestos a Railway antes del 21 de octubre: no limitarse a proveedores de IA; incluir bases de datos, cloud, GitHub, registros, pagos y claves de firma.
• Revisar el consumo y la facturación: buscar picos, modelos desconocidos, regiones nuevas, agentes de programación o workloads de entrenamiento no autorizados.
• Aplicar límites duros: configurar presupuestos, cuotas por clave, alertas de velocidad y bloqueo automático ante desviaciones.
• Separar credenciales por aplicación y ambiente: evitar claves compartidas entre desarrollo, pruebas y producción para reducir el radio de impacto.
• Preferir identidades temporales: sustituir secretos estáticos por workload identity, OIDC correctamente restringido y credenciales de corta duración.
• Reducir conectividad interna: una máquina de orquestación no debería combinar acceso a la base de secretos, a la red privada y a credenciales capaces de descifrarlos sin controles adicionales.
• Auditar CI/CD y builds: revisar aislamiento multi-tenant, snapshots, cachés, historiales, tokens de repositorio y sistemas de orquestación.
• Tratar la rotación como una investigación: una clave nueva detiene el uso futuro, pero no revela qué datos fueron consultados o qué persistencia pudo establecerse.

Fuentes verificadas

• Railway — informe técnico del incidente del 21 de octubre
• Railway Status — incidente, contención y recomendaciones
• Fireworks AI — actualización sobre la campaña de LLMJacking

XPoint News · November 11, 2026

Railway: attackers stole development secrets to fuel LLMJacking operations

Railway published the technical report of an attack that chained vulnerabilities, crossed its build infrastructure and enabled the decryption of environment variables belonging to a subset of customers. The investigation concluded that AI-provider keys were the primary target. Their unauthorized use generated an estimated $740,000 in charges.

An attack on the software factory

Railway is a cloud platform used to build, deploy and operate applications. In these environments, variables commonly hold API keys, database credentials, GitHub tokens, cloud access and the secrets an application needs to function.

On October 20, the attacker began probing the build infrastructure. Railway says an unknown vulnerability enabled a partial escape from filesystem isolation on a multi-tenant virtual machine. The actor obtained a credential used by build servers to communicate with internal services.

An alert triggered by anomalous calls to an artifact registry exposed the activity. Railway revoked the first credential and closed the initial path, but the attacker had already obtained enough internal information to continue searching for other entries.

From build histories to internal source code

The compromised credential was intended to authorize limited tasks such as pushing images after a build. An internal Temporal cluster, however, accepted it as a trusted client. The attacker used that trust relationship to query build histories containing variables, metadata and restricted tokens.

The actor also retrieved a copy of Railway’s internal monorepo from a build snapshot. That visibility revealed how systems were connected and supported searches for old or rarely used paths. Railway observed probes against endpoints that had lacked active references for weeks, months or years.

The report says the adversary used multiple agents in parallel and modified models with reduced restrictions. This assessment describes the observed speed and breadth of exploration, but Railway does not publicly identify the models or attribute the operation to a named group.

The second entry led to the secrets

The attacker found an incorrect OIDC configuration in the CI/CD system and obtained a short-lived cloud credential. That credential exposed additional internal credentials and enabled SSH access to an orchestration machine connected to the private network containing the encrypted-variable database.

The variables used envelope encryption: each environment had a data-encryption key protected by a root key in a key-management service. The orchestration machine needed a longer-lived credential to decrypt variables while provisioning workloads. Combined with internal-network access, that credential allowed the actor to retrieve and decrypt a subset of stored secrets.

Logs show that the attacker specifically searched for variable names associated with AI providers. Another query also matched cloud, database and payment credentials. Railway says its forensics found no indication that customer databases were directly accessed.

Up to 100,000 workspaces and linked tokens for 1,852 users

Railway validated that at most about 100,000 workspaces contained environments from which a variable could have been decrypted. Because logs identify environments rather than each individual secret, the company treats this number as an upper bound.

The attacker also read stored histories for 353 builds. Decrypted data included linked-account tokens — user-provided agent keys and GitHub OAuth tokens — for 1,852 users. Railway reset those tokens and says it identified no Railway-account logins using credentials obtained in the incident.

The company asked GitHub, GitLab, Anthropic, OpenAI, OpenRouter, SpaceXSI, Google and Stripe to revoke potentially compromised keys. Some providers expanded revocations as a precaution.

LLMJacking: stealing AI capacity instead of paying for it

Railway believes AI credentials were the primary target. Attackers can use someone else’s keys to consume models, operate agents, run training pipelines or resell access through illicit gateways. This practice is known as LLMJacking.

The company observed workloads ranging from coding agents to AI training pipelines. Customers also shared evidence of requests analyzing agent behavior and evaluating training tasks. Railway believes the keys may have been distributed through intermediary services, although it has not established whether the original attacker operated them.

Estimated unauthorized spending reached approximately $740,000. Railway says it is working with providers on refunds and will backstop costs when providers decline to do so.

Why this case matters beyond Railway

Environment variables have become an informal vault for the cloud economy. A single platform may concentrate access to repositories, models, databases, storage, payments and production. Encryption at rest protects stored data, but it cannot solve the problem when a component authorized to decrypt it is compromised.

The case also illustrates the danger of implicit trust between systems. The first credential was not supposed to open the platform; the architecture allowed it to reach a service that treated it as a trusted client. Permissions, connectivity and source-code knowledge progressively expanded the blast radius.

Rotating only AI keys would be insufficient. If an environment held database, cloud, payment, registry or GitHub credentials, each secret requires its own risk assessment and response.

XPoint recommendations

• Rotate every secret stored in Railway before October 21: include databases, cloud, GitHub, registries, payment services and signing keys, not just AI providers.
• Review consumption and billing: investigate spikes, unfamiliar models, new regions, coding agents and unauthorized training workloads.
• Enforce hard limits: apply budgets, per-key quotas, velocity alerts and automatic blocking when behavior deviates.
• Separate credentials by application and environment: avoid sharing keys across development, test and production.
• Prefer temporary identities: replace static secrets with workload identity, tightly constrained OIDC and short-lived credentials.
• Reduce internal connectivity: an orchestration host should not combine access to the secrets database, private network and decryption credentials without additional controls.
• Audit CI/CD and builds: review multi-tenant isolation, snapshots, caches, histories, repository tokens and orchestration platforms.
• Treat rotation as part of an investigation: a new key stops future use but does not reveal what was accessed or whether persistence was established.

Verified sources

• Railway — technical report on the October 21 incident
• Railway Status — incident, containment and recommendations
• Fireworks AI — update on the wider LLMJacking campaign