Railway zegt dat gestolen AI-sleutels bij een in oktober ontdekte inbraak hebben geleid tot een schatting van $740.000 aan ongeoorloofde gebruikskosten richting AI-providers. Het platform-as-a-servicebedrijf bevestigt dat aanvallers toegang kregen tot geheimen die klanten als omgevingvariabelen hadden opgeslagen.
De impact lijkt vooral te draaien om het misbruik van API- en accounttokens, niet om het uitlezen van volledige klantdatabases of het downloaden van repositories. Toch is het voor teams die op Railway draaien een dringende reminder om gevoelige sleutels zorgvuldig te beheren en snel te roteren waar nodig.
Wat Railway meldt over de gestolen AI-sleutels
Railway bewaart volgens eigen beschrijving klantgeheimen zoals API-keys en database-inloggegevens in omgevingvariabelen. Bij de aanval konden aanvallers die variabelen voor een deel ontsleutelen: maximaal 1,85% van de werkruimtes. Railway noemt dit een bovengrens, omdat de logboeken wel blootgelegde omgevingen tonen, maar niet welke individuele variabelen precies zijn vrijgegeven.
In dezelfde periode richtten de zoekopdrachten in de database zich specifiek op AI-provider keys. Daarnaast zijn ook gekoppelde accounttokens aangetroffen voor een reeks gebruikers (in het rapport genoemd: tokens voor 1.852 gebruikers), waaronder BYOK-agent keys en GitHub OAuth-tokens. Alle betroffen tokens zijn opnieuw ingesteld en gebruikers zijn ingelicht.
Geschatte kosten: waar gaat die $740.000 over?
Railway geeft aan dat er in totaal ongeveer $740.000 aan ongeoorloofde usage charges is ontstaan. Het bedrijf belooft die kosten te dragen wanneer de desbetreffende AI-provider geen refund aanbiedt.
Belangrijk detail: Railway licht niet toe hoe dat bedrag precies is berekend, noch over welke periode de schatting loopt. Evenmin beschrijft het incidentrapport strikte deadlines of een harde cap voor claims. Daardoor is het voor klanten vooral zaak om alert te blijven op facturatie en actief te handelen volgens de instructies van zowel Railway als de betreffende AI-provider.
Refunds verschillen per AI-provider
Railway schetst per provider hoe refundafhandeling werkt bij misbruik van gestolen sleutels:
- AWS Bedrock en Google Gemini: bestaande refundpolicies dekken fraudemeldingen; provider-teams zijn gestart met refunds.
- OpenAI: claims worden per geval beoordeeld. Klanten dienen een claim in bij OpenAI en sturen daarna het case-ID door aan Railway support.
- SpaceXSI: ook case-by-case; klanten dienen dezelfde route te volgen via het supportteam.
- Anthropic: gesprekken lopen nog; Railway dekt de kosten uit Anthropic-sleutels voor de periode tot er duidelijkheid is.
- OpenRouter: hanteert volgens de terms een no-refund beleid; Railway zegt alle OpenRouter-gerelateerde kosten als gevolg van de breach te vergoeden.
Daarnaast vraagt Railway klanten om eventuele niet-gemaakte charges te melden via een charge report-formulier. Het formulier vermeldt dat het bedrijf niet verantwoordelijk is voor usage met die keys, maar geeft wel aan dat Railway onderzoekt en samenwerkt met providers.
Wat is er wél en niet gebeurd tijdens de aanval?
Volgens het incidentrapport konden aanvallers meer doen dan alleen sleutels zoeken. Railway beschrijft vier categorieën bevindingen:
- Ontsleutelde variabelen in een beperkt deel van de werkruimtes, met focus op AI-provider keys.
- Statische bouwhistorie: de aanvaller las build-histories van 353 builds, inclusief variabelen en geheimen die aan die builds waren doorgegeven.
- Klantdata niet aangetoond: de forensische analyse toont geen bewijs dat klantdatabases zijn benaderd.
- Geen code-downloads: er is geen indicatie dat code-repositories zijn gedownload.
Ook relevant: Railway stelt dat data die wel is gekopieerd maar niet kon worden ontsleuteld, niet meer opnieuw ontsleuteld kan worden omdat de gebruikte credential is uitgeschakeld.
Hoe de inbraak volgens Railway verliep
Railway koppelt de aanval aan het build-systeem. Op 20 oktober (07:28 UTC) misbruikten aanvallers een tot dan toe onbekende zwakte waarmee ze gedeeltelijk de bestandsisolatie rond een build konden omzeilen en bestanden op de host-virtual machine konden inzien.
Met die toegang kregen ze een credential die buildservers gebruiken om images te pushen en om interne systemen te bereiken. Ongeveer zeseneenhalf uur later (13:58 UTC) volgde een alert door ongebruikelijke calls naar een registry-service.
Vervolgens misbruikten aanvallers een interne component in de buildketen: Railway beschrijft dat een intern Temporal-systeem dat doorgaans vertrouwde clients behandelt, de credential accepteerde. Via die route konden zij build-historie van andere builds inzien. Daarnaast konden ze cached snapshots van code ophalen, wat resulteerde in een kopie van de interne monorepo—informatie die volgens Railway hielp bij het vinden en versnellen van verdere exploits.
Daarna volgde een stap in een cloudomgeving: een verkeerd geconfigureerde OIDC-binding werd gebruikt om cloud credentials te verkrijgen. Daarmee pakten aanvallers twee extra geheimen, waaronder een SSH-key die een orchestration-machine ontsloot. Die machine had een credential waarmee klantvariabelen konden worden gedecrypt.
Tussen 04:07 en 05:21 UTC op 21 oktober zochten aanvallers in versleutelde variabelen naar namen die overeenkomen met AI-provider keys. Railway geeft aan dat een deel ervan is ontsleuteld op specifieke tijdstippen. Later die dag werd de aanvaller volledig uit systemen verwijderd (09:24 UTC).
Op basis van nieuwe inzichten en het sluiten van zwaktes heeft Railway de manier waarop builds draaien aangepast: builds draaien nu in kortlevende virtual machines, met credentials die maar één specifieke image kunnen pushen naar de registry.
Wat je als Railway-klant nu kunt doen
Railway adviseert klanten om vóór 21 oktober alle gevoelige variabelen die op het platform zijn opgeslagen te roteren of te revoken. Het bedrijf benadrukt dat een charge report niet automatisch leidt tot het ongeldig maken van een sleutel.
Concreet noemt Railway de volgende acties:
- Keys revoken/rotaten bij de provider die ze heeft uitgegeven.
- Database-toegang versmallen: haal publieke netwerktoegang tot databases weg.
- GitHub controleren: bekijk GitHub audit logs en verifieer welke apps toegang hebben tot het account.
- Registry-audits: controleer audit logs in registries zoals Docker Hub.
Railway geeft ook aan dat sommige providers uit voorzorg alle keys kregen die het bedrijf had voor hun diensten—waardoor resetverzoeken mogelijk gericht zijn geweest op meer dan 100.000 gebruikers. Een revocation notice van een provider betekent dus niet automatisch dat jouw sleutel daadwerkelijk is blootgesteld.
Vergelijkbare risico’s: waarom dit breder dan één provider is
Deze casus laat een patroon zien dat in beveiligingsonderzoek vaker terugkomt: aanvallers zoeken niet alleen naar code of databases, maar naar geheimen die in de pipeline klaarstaan. Wie API-keys opslaat in omgevingvariabelen, loopt het risico dat een ketenfout in het build- of deployproces die sleutels bereikbaar maakt.
Wil je extra context over incidenten en patch- of herstelupdates rond cloud- en platformbeveiliging, dan zijn deze artikelen mogelijk relevant:
- Microsoft patcht 1.259 lekken, inclusief Outlook-exploit met NTLMv2
- Software transparency: SBOM, AI BOMs en VEX uitgelegd
- SSHole: OpenSSH-kwetsbaarheid en directe acties
Conclusie: actie op sleutels én op je sleutelbeheer
Railway’s bericht komt erop neer dat gestolen AI-sleutels uit klantomgevingen zijn misbruikt, met een schatting van $740.000 aan ongeoorloofde kosten. Het goede nieuws is dat er volgens Railway geen aanwijzingen zijn voor het uitlezen van klantdatabases of het downloaden van repositories. Het minder goede nieuws is dat aanvallers wel degelijk omgevingvariabelen konden ontsleutelen en build-historie konden inzien.
Voor teams die Railway gebruiken is de belangrijkste praktische stap: roteren en revoken waar nodig, audit je toegang (GitHub en registries) en volg het refundproces per AI-provider. Zo voorkom je dat gestolen sleutels opnieuw tot uitgaven of datalek-achtige gevolgen leiden.
Bron: https://thehackernews.com/2026/11/railway-says-stolen-customer-ai-keys.html
