{"id":10402,"date":"2026-11-12T02:53:41","date_gmt":"2026-11-12T02:53:41","guid":{"rendered":"https:\/\/cybersecurityinfocus.com\/?p=10402"},"modified":"2026-11-12T02:53:41","modified_gmt":"2026-11-12T02:53:41","slug":"hackers-stole-ai-credentials-to-get-740000-in-free-compute-railway-picked-up-the-bill","status":"publish","type":"post","link":"https:\/\/cybersecurityinfocus.com\/?p=10402","title":{"rendered":"Hackers stole AI credentials to get $740,000 in free compute; Railway picked up the bill"},"content":{"rendered":"
\n
\n
\n
\n
<\/div>\n

As AI model training and distillation increase, AI tokens are becoming a piping hot currency for threat actors.<\/p>\n

Cloud hosting provider Railway found out the hard way; it has confirmed a near 26-hour battle against attackers targeting AI provider credentials to sell to AI \u2018transfer stations\u2019 for use in model distillation. The crooks generated about $740,000 in fraudulent AI usage charges using the stolen credentials and potentially had access to up to 100,000 workspace credentials.<\/p>\n

Railway said the attacker\u2019s database searches looked for AI provider keys by name before anything else; some queries also targeted cloud, database, and payment service credentials.<\/p>\n

The company disclosed the incident on October 22<\/a>, and posted a follow-up report<\/a> this week. Because of the ongoing investigation, it is not able to share the specific details and scale of the exploits, but advised users to revoke and reapply sensitive environmental variables stored on Railway prior to October 21.<\/p>\n

\u201cAI credentials are becoming the new credit card numbers,\u201d said David Shipley<\/a> of Beauceron Security. \u201cSo-called LLMjacking is expected to displace Cryptojacking as a cheap, scalable way to make money.\u201d<\/p>\n

A 26-hour battle<\/h2>\n

The attack began on October 20, when hackers exploited a previously unknown vulnerability in Railway\u2019s build infrastructure. They were able to evade filesystem isolation protections and obtain an internal credential that they used to access stored build histories. From there, they retrieved a copy of Railway\u2019s internal source code and analyzed it to identify additional avenues of compromise.<\/p>\n

They then exploited another vulnerability involving an improperly configured trust relationship \u00a0that allowed them to gain even more access to Railway\u2019s infrastructure and obtain credentials used to decrypt customer environment variables.<\/p>\n

In a nearly 26-hour battle, Railway\u2019s engineering team worked 24-7 in shifts and the escalating situation became a \u201ccontest of agent speed,\u201d the company explained. The threat actor chained various exploits, moved laterally across multiple systems, and \u201cprobed many potential routes, in parallel.\u201d Defenders in turn hardened routes in parallel.<\/p>\n

\u201cThis was not a single breach followed by a single fix,\u201d Railway wrote.<\/p>\n

The threat actors were \u201cfully evicted\u201d on October 21, but over the course of their time in the system, they obtained and decrypted a \u201csubset\u201d of customer variables, roughly 100,000, or \u201cat most\u201d 1.85% of workspaces. They also racked up $740,000 in fraudulent AI usage charges, with customers reporting their keys answered coding questions and performed training-data tasks they never ran. The company is working to reimburse customers, including for charges providers decline to refund.<\/p>\n

The breach also exposed linked-account tokens belonging to more than 1,850 users, which included GitHub and OAuth tokens that Railway says it reset. The company worked quickly with GitHub, GitLab, Anthropic, OpenAI, OpenRouter, SpaceXSI, Stripe, and others to revoke potentially compromised keys.<\/p>\n

In the wake of the attack, customers have been advised to remove public network access to databases; rotate any sensitive variables and keys; check GitHub account audit logs and review all app access; and check audit logs within registries such as Dockerhub.<\/p>\n

On its own systems, Railway said it shut down any potentially compromised internal tooling; rolled all keys and \u201cthen rerolled them\u201d after validating that intruders had been shut out; moved to a new generation of infrastructure; rebuilt tooling used to run its infrastructure; and added functionality to mass revoke Railway app permissions in the event of suspicious activity in the future.<\/p>\n

Why attackers want AI keys<\/h2>\n

AI credentials are cheap to harvest at scale, Shipley noted; attackers can hit a provider like Railway rather than trying to target one company at a time. That access can then be resold to generate revenue through so-called AI routers, which provide access to models that users otherwise could not afford, or even reach.<\/p>\n

This makes that access a hot commodity for tasks like d<\/a>istillation<\/a>, which transfers knowledge from a larger model to a smaller one to cut costs and improve efficiency.<\/p>\n

Training one model on another model\u2019s answers at scale takes millions of questions, said Frank Dickson<\/a> of Dickson Research, and a single account asking millions of questions stands out. Stolen keys spread those questions across thousands of real customers.<\/p>\n

\u201cThink of copying a textbook one page at a time, using library cards that belong to other people,\u201d Dickson explained. Frontier AI is expensive to buy, and the owner of the keys gets the bill while the thief gets cost-free compute.<\/p>\n

\u201cIt is the 2026 version of cryptomining; [the] same playbook with a different output,\u201d he said.<\/p>\n

Managing identities when so many are machine-held<\/h2>\n

Even though the facts are ugly, Railway deserves credit for a \u201cremarkably candid report,\u201d Dickson emphasized: It owns its own configuration mistake, it admits it cannot be sure it found every account the attacker created, and it commits to telling customers of issues more quickly in the future.<\/p>\n

Railway is now moving to short-lived credentials and logging every decryption. That is the right fix, Dickson said, and every platform holding customer secrets should copy it.<\/p>\n

\u201cRailway customers should treat every secret stored on the platform as stolen until they have rotated it,\u201d he noted. But that rotation has to beat the thief\u2019s clock; an investigation by Wiz found that stolen keys were tested within 30 minutes of theft, then flooded with traffic four to seven days later.<\/p>\n

Start with AI provider keys, then rotate cloud, database, and payment credentials, he advised. Check AI provider bills and usage logs for traffic internal teams did not generate, then report any unauthorized charges to Railway. Alert on any call from an unrecognized address.<\/p>\n

Further, he said, limit the damage any one key can do. Set hard spending caps and usage alerts on every AI key, and scope each key as narrowly as the provider allows. This really works: In one case Wiz examined, a key restricted to a narrow set of model profiles left most of the thief\u2019s traffic throttled.<\/p>\n

Non-Railway users, meanwhile, should ask their platform providers two questions: How are my secrets stored, and who can decrypt them? A good standard practice: Issue fewer keys. \u201cNo one ever said during a key rotation that they wished they had issued more keys,\u201d Dickson pointed out.<\/p>\n

Ultimately, he said, a stolen AI key spends real money, and machines now hold most of the keys. \u201cProtect machine identities like cash, because to a thief, that is exactly what they are,\u201d Dickson urged.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>","protected":false},"excerpt":{"rendered":"

As AI model training and distillation increase, AI tokens are becoming a piping hot currency for threat actors. Cloud hosting provider Railway found out the hard way; it has confirmed a near 26-hour battle against attackers targeting AI provider credentials to sell to AI \u2018transfer stations\u2019 for use in model distillation. The crooks generated about […]<\/p>\n","protected":false},"author":0,"featured_media":10403,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-10402","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-education"],"_links":{"self":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/10402"}],"collection":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=10402"}],"version-history":[{"count":0,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/10402\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/media\/10403"}],"wp:attachment":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=10402"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=10402"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=10402"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}