← Blog
Asif
AsifNovember 10, 2026

How AuthNull's MFA and Privileged Access Could Have Contained the Railway October 2026 Security Incident

The attacker's path through Railway's systems, with AuthNull controls between each hop

On October 20–21, 2026, Railway suffered a sophisticated security incident. An attacker (accelerated by AI agents and tooling similar to ARTEX, per Railway’s own report and Wiz’s “Black October” research) exploited a vulnerability in multi-tenant build isolation, stole a build credential, moved laterally through Temporal and an OIDC misconfiguration, SSH’d into an orchestration machine, and ultimately decrypted customer environment variables (primarily AI provider API keys) for at most 1.85% of workspaces (~100,000). Unauthorized spend reached an estimated $740,000.

The attack was a classic privilege-escalation and lateral-movement chain enabled by over-privileged credentials, static secrets on disk, standing access, and insufficient real-time controls on privileged paths. While no single product is a silver bullet, AuthNull’s unified MFA + Privileged Access Management platform is purpose-built for exactly these gaps: agentless MFA on Active Directory, Linux, RADIUS, and databases; just-in-time (JIT) access; SSH session recording; service-account protection; and vaultless secrets.

Here’s how AuthNull’s controls map to the Railway kill chain and could have raised friction, limited blast radius, or stopped key steps.

Before and After: The Same Attack Path

On the left, the path the attacker took through standing access and static secrets. On the right, the same systems with AuthNull in the path.

BeforeStanding access, static secrets
AttackerAI agents, fan-out tooling
Escapes build isolation
Build credentialMeant for registry pushes only
Accepted as a trusted client
Temporal clusterBuild histories, monorepo
SSH with a static key from disk
Orchestration machineHolds the decryption path
Long-lived credential decrypts
KMS + env-var databaseCustomer secrets
Customer environment variables decrypted
AfterWith AuthNull in the path
AttackerAI agents, fan-out tooling
Escapes build isolation
Build credentialMeant for registry pushes only
AuthNull · Policy engineOut-of-scope call denied
Temporal clusterBuild histories, monorepo
AuthNull · SSH gatewayStatic keys refused; MFA push + JIT
Orchestration machineHolds the decryption path
AuthNull · Database MFAStep-up MFA; no standing key
KMS + env-var databaseCustomer secrets
Stopped at the next hop, and every attempt is logged

The Kill Chain at a Glance

Attacker stepAuthNull controlEffect
01Over-privileged build credential accepted by TemporalService-account discovery, least-privilege policy, M2M auth, rotationCredential can't query Temporal; short useful life
02SSH to orchestration machine with a static key on diskSSH gateway, MFA push, JIT access, session recordingKey alone is refused; every session is challenged and recorded
03Database query and KMS decryption of env variablesDatabase MFA, policy and masking, audit to SIEMStep-up on sensitive queries; unusual patterns flagged
04AI-agent fan-out and lateral movementNo standing privileges, conditional access, full audit trailStolen credentials can't be reused freely across systems

1. Over-Privileged Build Credential and Temporal Access

Railway’s build credential was intended only for registry pushes but was accepted as a trusted client by their Temporal cluster. This let the attacker read other builds’ histories and pull the monorepo, giving the AI agents a map of the system for rapid fan-out exploits.

AuthNull response

  • Service account discovery and protection: AuthNull automatically discovers service and machine accounts (domain-linked or local) and ranks them by risk. Policies enforce least privilege so a build credential cannot freely query Temporal or other internal systems.
  • Passwordless M2M authentication: Replace shared static secrets with passwordless machine-to-machine credentials. No long-lived token sits usable by an attacker.
  • Conditional access and policy engine: Policies decide allow / MFA / deny based on user, source and target. Anomalous use of a build credential (unexpected source, high volume of Temporal API calls, access outside normal build windows) can be blocked or stepped up in real time. Audit mode lets teams discover existing patterns before enforcement.
  • Credential rotation: Automatic rotation (default every 30 days, configurable) means a stolen static credential has a short useful life.

These controls shrink the window and scope after the initial isolation escape.

2. SSH to the Orchestration Machine Using a Static Key on Disk

After obtaining short-lived cloud credentials via a misconfigured OIDC binding, the attacker retrieved a longer-lived credential and an SSH private key, then connected to the orchestration machine that held the decryption key for customer environment variables.

AuthNull response

  • SSH gateway (jump server): All admin SSH traffic is forced through the AuthNull gateway. Direct password or key logins that bypass it are refused. The gateway checks policy, raises an MFA push (AuthNull Authenticator, Duo, Okta, TOTP, or WebAuthn), and uses a per-session key.
  • Just-in-time access: SSH accounts and sudo rights are granted only for the approved window and then removed. No standing SSH keys or persistent privileged accounts exist for attackers to steal or reuse.
  • Local 2FA / passwordless for Linux: Even if an SSH key is present, PAM-enforced second-factor (or full passwordless) is required. Break-glass accounts can be tightly controlled.
  • Session recording: Every admin SSH session is recorded (text and/or video). Anomalous commands or rapid lateral movement by AI agents become immediately visible to operators and SIEM.
  • Vaultless secrets / rotation: The decryption credential and SSH key would not sit as static files on disk. Operators never hold the underlying secrets; the gateway or wallet supplies short-lived access.

An AI agent moving at high speed would have been interrupted by MFA challenges and left a full audit trail.

3. Database Query and Decryption of Customer Environment Variables

The attacker queried the database of envelope-encrypted variables, prioritizing AI provider keys, then used the longer-lived credential against the KMS to decrypt a subset.

AuthNull response

  • Database MFA and fine-grained access: AuthNull’s DB agent (for MySQL, PostgreSQL, MariaDB) adds MFA and policy-based controls. Access can be limited by user, time, source, or even require step-up. Data-masking policies can hide sensitive columns from unauthorized sessions (including those driven by AI agents).
  • Audit logging: Every decision (who, what, when, outcome) streams to SIEM, enabling faster detection of unusual query patterns (regex searches for AI key names, large result sets).
  • No standing long-lived decryption credentials: Combined with service-account protection and rotation, the decryption key is not a persistent file an attacker can simply read after SSH.

Railway’s envelope encryption already limited the blast radius; AuthNull-style controls would have made reaching and using the decryption path far harder.

4. Broader AI-Agent and Lateral-Movement Resilience

Railway described the incident as “a contest of agent speed.” The attacker used abliterated models and agent fan-outs once they had the monorepo.

AuthNull response

  • No standing privileges: JIT + policy enforcement means agents cannot freely reuse stolen credentials across systems.
  • Real-time risk and conditional access: Suspicious patterns (rapid parallel probes, access from unexpected locations or to unused endpoints) trigger MFA or denial.
  • Comprehensive audit and SIEM integration: Every authentication decision is logged from day one, giving defenders the telemetry needed to match the attacker’s speed.
  • AI copilots (optional): AuthNull’s copilots help generate and evaluate MFA, conditional-access, and Linux policies from auth logs, reducing the time to close gaps.

What AuthNull Does Not Replace

AuthNull does not fix an underlying isolation vulnerability in build infrastructure or an OIDC binding misconfiguration. Those are platform and configuration issues. What it does is make the subsequent use of any stolen or over-privileged credential expensive, noisy, and time-limited, especially for interactive or high-privilege paths on Linux, databases, and service accounts.

Railway already used envelope encryption and strong monitoring. Adding agentless MFA, JIT privileged access, session recording, and service-account hygiene on the internal systems that hold decryption keys and orchestration privileges would have added multiple additional barriers precisely where the attacker moved fastest.

Takeaways for Platform and Infrastructure Teams

  1. Treat every build, CI/CD, and orchestration credential as a privileged service account: discover it, rotate it, and eliminate standing secrets.
  2. Force all SSH and privileged Linux access through a gateway that enforces MFA + JIT and records sessions.
  3. Apply conditional access and least-privilege policies to internal systems (Temporal, databases, KMS paths), not just external logins.
  4. Assume AI agents will accelerate lateral movement; design controls that interrupt, log, and expire access automatically.
  5. Prefer vaultless or decentralized approaches so a single compromised machine does not yield a treasure trove of long-lived keys.

The Railway incident is a clear reminder that AI-accelerated attackers thrive on over-privileged, long-lived, and poorly monitored credentials. Platforms that combine MFA with modern privileged access management, especially agentless coverage for the infrastructure IdPs do not see, raise the cost of those attacks dramatically.

Want to see these controls on your own infrastructure? Book a demo of AuthNull.


AuthNull provides MFA and privileged access for Active Directory, Linux, RADIUS, databases, and more, without agents on every endpoint.

← Back to Blog