Railway paie 740 000 $ après vol massif de clés d’IA

Un groupe d’attaquants a exploité des failles chez Railway pour dérober des identifiants d’IA et générer 740 000 $ de calcul frauduleux. L’épisode, étalé sur près de 26 heures, illustre la montée du « LLMjacking » et s’accompagne de recommandations opérationnelles immédiates pour limiter les dégâts.

Limiter l’impact dès maintenant sur les comptes et les clés

Railway recommande de supprimer l’accès réseau public aux bases de données, de renouveler toutes les variables et clés sensibles, de contrôler les journaux d’audit GitHub et les accès aux applications, ainsi que d’examiner les registres tels que Dockerhub. Frank Dickson conseille aux clients de considérer chaque secret stocké comme compromis jusqu’à ce qu’il soit renouvelé. Selon Wiz, des clés volées sont testées dans les 30 minutes suivant le vol, puis soumises à un trafic massif entre quatre et sept jours plus tard, ce qui impose d’agir rapidement. Dickson recommande de commencer par les clés des fournisseurs d’IA, puis de renouveler les identifiants cloud, de bases de données et de paiement. Il suggère aussi de vérifier les factures et journaux d’utilisation des fournisseurs d’IA et de signaler toute charge non autorisée à Railway, ainsi que d’alerter sur tout appel provenant d’une adresse inconnue. Pour limiter l’exposition, il préconise des plafonds de dépenses, des alertes d’usage et des restrictions fines sur chaque clé ; Wiz rapporte qu’une clé fortement restreinte a permis de limiter la plupart du trafic malveillant dans un cas examiné. Au-delà de Railway, Dickson invite à demander aux plateformes comment les secrets sont stockés et qui peut les déchiffrer, et à émettre moins de clés. Il souligne qu’une clé d’IA volée entraîne des dépenses réelles et que la majorité des clés résident désormais dans des machines, d’où son appel à protéger les identités machine comme de l’argent liquide. Railway a également conseillé de révoquer et réappliquer les variables sensibles stockées avant le 21 octobre.

Fraude facturée à 740 000 $ et données client exposées

Les attaques ont généré environ 740 000 $ de frais d’usage d’IA frauduleux. Railway indique qu’environ 100 000 variables clients ont été obtenues et déchiffrées, ce qui représente au maximum 1,85 % des espaces de travail. Des clients ont signalé des réponses à des questions de codage et des tâches de données d’entraînement qu’ils n’avaient pas initiées. Plus de 1 850 utilisateurs ont vu des tokens de comptes liés exposés ; Railway affirme avoir réinitialisé les tokens GitHub et OAuth et collaboré rapidement avec GitHub, GitLab, Anthropic, OpenAI, OpenRouter, SpaceXSI, Stripe et d’autres pour révoquer des clés susceptibles d’être compromises. L’entreprise travaille au remboursement des clients, y compris lorsque certains fournisseurs refusent de rembourser. Railway précise aussi que les attaquants ont potentiellement eu accès à jusqu’à 100 000 identifiants d’espaces de travail.

Chronologie confirmée et communication encadrée

Railway a fait état de l’incident le 22 octobre et a diffusé un rapport de suivi durant la même semaine que l’annonce. Selon l’entreprise, une enquête est actuellement menée et il lui est impossible de communiquer l’ensemble des informations ou de préciser toute l’ampleur des exploits. Elle confirme une intrusion qui s’est étalée sur près de 26 heures, l’éviction complète des attaquants le 21 octobre, et précise que son équipe d’ingénierie a travaillé en continu par roulements.

Vecteurs d’intrusion et escalade côté infrastructure

L’attaque a débuté le 20 octobre par l’exploitation d’une vulnérabilité inconnue dans l’infrastructure de build. Les assaillants ont contourné les protections d’isolation du système de fichiers, obtenu un identifiant interne et accédé aux historiques de build. Ils ont récupéré le code source interne de Railway et l’ont analysé pour trouver d’autres voies de compromission. Une relation de confiance mal configurée a ensuite été exploitée, ouvrant un accès plus profond à l’infrastructure et aux identifiants permettant de déchiffrer des variables d’environnement client. Railway décrit un enchaînement d’exploits et de déplacements latéraux menés en parallèle, auquel les défenseurs ont répondu par un durcissement simultané, et insiste sur l’absence d’un schéma « une violation, une correction ».

Le mobile : revente de clés et distillation de modèles

Selon David Shipley, récolter des identifiants d’IA à grande échelle est peu coûteux et viser un fournisseur unique est plus rentable que d’attaquer des entreprises une à une. Ces accès se revendent via des routeurs d’IA qui proposent des modèles autrement inabordables ou inaccessibles. La distillation, qui transfère des connaissances d’un modèle volumineux vers un plus petit, motive cet intérêt. Frank Dickson souligne qu’un entraînement à grande échelle sur les réponses d’un autre modèle exige des millions de requêtes ; un seul compte serait détectable, alors que des clés volées répartissent ces requêtes sur des milliers de comptes légitimes. Il rappelle que l’IA de pointe coûte cher, que le propriétaire des clés paie la facture et que le voleur profite du calcul. Il compare ce phénomène à une version 2026 du cryptomining avec un mode opératoire similaire. Shipley estime que le LLMjacking est en passe de supplanter le cryptojacking.

Durcissement interne et nouvelles pratiques d’identités

Railway indique avoir fermé les outils internes potentiellement compromis, réinitialisé l’ensemble des clés puis procédé à une seconde réinitialisation après l’éviction confirmée des intrus. L’entreprise est passée à une nouvelle génération d’infrastructure, a reconstruit les outils d’exploitation et déployé un mécanisme pour révoquer en masse les autorisations d’applications en cas d’activité suspecte. Elle adopte des identifiants à durée de vie courte tout en journalisant chaque déchiffrement. Frank Dickson juge cette approche appropriée et recommandable à toute plateforme qui conserve des secrets clients. Il salue la franchise de Railway, qui reconnaît une erreur de configuration de confiance, admet ne pas pouvoir garantir l’identification de tous les comptes créés par l’attaquant et promet d’accélérer l’information aux clients.