Retour au blog

Sécurité

Neuf piratages en un mois : votre accès à l'IA se revend au marché noir

1 novembre 20267 min de lecturePar Alpha Oumar Sow

Neuf plateformes piratées en octobre 2026. Les intrus cherchaient les clés d'IA de leurs clients pour revendre l'accès. Ce qu'il faut vérifier chez vous.

Le lundi, votre équipe confie une partie de son travail à un service extérieur. Le vendredi, la facture de ce service a doublé. Aucune fonction de votre produit n'a changé, aucune alerte n'est apparue, et personne n'a d'explication.

Ce n'est pas une histoire inventée. En octobre 2026, neuf plateformes de développement ont révélé, chacune à sa date, qu'un intrus avait fouillé leurs serveurs. Toutes cherchaient la même chose : les codes secrets que leurs clients y avaient rangés pour utiliser des services d'IA.

Ces codes portent un nom courant, la clé d'accès. Une clé volée permet de faire tourner un modèle d'IA, le programme qui rédige du texte ou du code, sur le compte de quelqu'un d'autre. La note arrive chez la victime, pas chez le voleur.

Le 30 octobre 2026, deux chercheurs de la société de sécurité Wiz, Benjamin Read et Rami McCarthy, ont publié une synthèse de ces neuf incidents. Leur rapport est la source principale de cet article. Il relie des faits dispersés et documente deux cas d'entreprise observés de bout en bout.

Ce qui s'est passé entre le 6 et le 30 octobre

Neuf plateformes, neuf dates. Fireworks AI le 6 octobre, Andromeda le 9, Zeabur le 14, Lightning AI le 15, OpenCode les 16 et 17, Railway le 20, Warp le 23, CommandCode le 28, Northflank le 30.

Une plateforme de développement est un service qui exécute et héberge le code de vos applications. Vos équipes y déposent leurs programmes, et souvent les codes d'accès qui vont avec.

Les causes annoncées diffèrent. Fireworks, Zeabur et Lightning parlent d'un accès aux identifiants. Railway pense à une élévation de privilèges dans son infrastructure de compilation. Warp évoque un prestataire externe. OpenCode désigne un système ancien.

Wiz insiste sur un point : aucune faille commune ne relie ces neuf incidents. Ce n'est pas la même porte qui a été forcée neuf fois. C'est la même pièce qui a été visitée neuf fois.

Le point commun est ailleurs. Dans tous les rapports publics, l'intrus cherche explicitement des variables d'environnement, ces fichiers de réglages où l'on range les codes secrets d'une application. Il vise en priorité celles qui donnent accès à des services d'IA.

Une victime collatérale mérite d'être citée. Zeabur a annoncé sa fermeture à cause de l'incident.

Ce qu'est une clé d'accès, et pourquoi on la vole

Une clé d'accès est une longue suite de caractères qui prouve votre identité à un service distant. Elle fonctionne comme un badge de salarié : celui qui le porte passe les portes, sans qu'on vérifie son visage.

Sauf qu'ici, le badge ouvre aussi la caisse. Une clé d'IA autorise des appels facturés à votre compte, souvent sans plafond propre. Quiconque la détient dépense votre argent.

D'où le nom donné à ce commerce par les analystes : le détournement de capacité d'IA, ou LLMjacking dans la littérature anglaise. Le principe est simple. On ne casse pas votre produit. On utilise la puissance que vous payez.

Wiz décrit deux moteurs de demande. Le premier est la revente. Des sites vendent l'accès à des modèles réputés chers, à prix cassé, payables en cryptomonnaie. Ils revendent la capacité volée.

Le second moteur est la copie. Il s'agit d'entraîner son propre modèle en observant les réponses d'un autre, ce que le secteur appelle la distillation. On photographie le savoir-faire au lieu de l'acheter.

Railway attribue explicitement l'attaque à cette intention : obtenir des clés pour mener des attaques de distillation. OpenCode et CommandCode vont dans le même sens. Deux marchés se rejoignent donc, celui de la revente et celui de la copie.

L'image utile est celle du badge volé. On peut revendre des entrées au marché noir, ou s'en servir pour photographier les coulisses. Dans les deux cas, le propriétaire paie.

Deux clés, 2,5 millions d'appels en quelques jours

C'est la partie la plus concrète du rapport. Wiz a suivi deux clés d'entreprise volées lors de l'un de ces incidents, sans nommer la plateforme concernée.

Le début est identique dans les deux cas. Moins de trente minutes après l'accès aux identifiants chez le fournisseur, un appel unique part d'une connexion domestique. Il demande un modèle nommé Claude Fable 5.1, échoue, puis bascule sur Opus 5.5, qui répond. Ce test sert à vérifier que la clé fonctionne encore.

Suivent plusieurs jours de trafic discret : entre 14 et 120 appels par jour, depuis un même petit programme, à une minute d'intervalle entre les deux clés. C'est un contrôle de validité, pas un usage.

Puis tout s'accélère.

Sur la première clé, environ 800 000 appels en trente heures, dont près de 90 % réussis. Les règles attachées à cette clé autorisaient les appels vers toutes les régions du fournisseur. La charge s'est donc répartie, et 6 % seulement des appels ont été refusés parce que le plafond d'appels d'une région était atteint.

Sur la seconde, environ 1,7 million d'appels en treize heures, dont plus d'un million réussis. Cette clé-là était restreinte à une seule zone géographique. Les appels hors zone ont été bloqués, ce qui a limité les dégâts sans les empêcher.

Wiz estime que ces deux cas représentent, au tarif public, plus de 100 000 dollars d'usage. Il s'agit d'une estimation, pas d'une facture vérifiée. Le profil de consommation ressemble à celui d'un service de revente d'accès à des assistants de programmation.

Réparer la plateforme ne révoque pas votre clé

C'est la leçon la plus utile, et la plus contre-intuitive. Deux opérations distinctes sont en jeu.

La première appartient au fournisseur : colmater la faille. La seconde vous appartient : faire cesser l'usage de la clé volée. Tant que la clé n'est pas révoquée chez le fournisseur de modèles, elle continue de fonctionner. Le pirate profite d'un service qui ne sait pas encore qu'il a été cambriolé.

Fireworks l'écrit dans sa notice : supprimer un secret stocké ne suffit pas à invalider l'identifiant sous-jacent. La révocation doit se faire chez celui qui a émis la clé.

Railway donne l'échelle. Au plus 1,85 % des espaces de travail, soit environ 100 000, ont pu voir une partie de leurs variables d'environnement compromises. Par précaution, la société a demandé à tous ses clients inscrits avant le 21 octobre de changer leurs clés.

Un détail du rapport mérite attention. L'une des clés volées a servi, en fin de mois, à une tentative de modification des paramètres de conservation des données du compte. La clé ne servait plus seulement à consommer. Elle servait à préparer la suite.

Ce qu'il faut vérifier cette semaine

Faites la liste de vos clés, et de qui les détient. Pour chaque service extérieur, demandez quelles clés de votre entreprise y sont stockées. La question surprend souvent. La réponse aussi.

Changez les clés après tout incident chez un prestataire, même sans courriel de notification. Les notifications arrivent après l'analyse, parfois des semaines plus tard. La rotation préventive coûte une heure de travail. Elle évite le reste.

Restreignez chaque clé à ce qu'elle doit faire. Le second cas le montre : une clé limitée à une zone a encaissé un tiers des appels du premier. Limitez le modèle, la région, le projet. Une clé qui peut tout faire est une clé qui vaut cher.

Posez un plafond de dépense, et surveillez la dépense, pas seulement les erreurs. Une attaque par clé volée ne produit aucune erreur applicative. Le seul signal visible est un volume d'appels et un montant qui sortent de l'ordinaire.

Surveillez les petits volumes. Le contrôle de validité se cache dans 14 à 120 appels par jour. Un pic brutal se voit. Un filet régulier, non. Comparez les adresses d'origine et les heures d'activité à vos habitudes.

Pour cela, activez la journalisation des appels. Chez Amazon, CloudTrail enregistre chaque appel adressé à Bedrock, le service de modèles de la maison. Le journal indique l'adresse d'origine, l'identité utilisée et l'heure exacte.

Ce qu'il faut retenir

  • Neuf plateformes de développement ont révélé un incident en octobre 2026 : les intrus cherchaient les clés d'accès aux services d'IA stockées par leurs clients.
  • Deux clés d'entreprise volées ont produit environ 2,5 millions d'appels en quelques jours, estimés à plus de 100 000 dollars au tarif public.
  • Le premier signe n'est pas une erreur, mais un trafic faible et régulier, entre 14 et 120 appels par jour, destiné à vérifier que la clé fonctionne.
  • Corriger la faille chez le fournisseur ne révoque pas votre clé : la révocation se fait chez celui qui a émis la clé, et c'est votre travail.
  • Une clé limitée à un modèle, une région et un budget réduit fortement la facture d'un vol. Une clé sans limite la laisse filer.
  • Demandez cette semaine quelles clés de votre entreprise dorment chez des prestataires, et changez celles que vous ne pouvez pas justifier.

Références

  1. [1] Benjamin Read et Rami McCarthy (Wiz Research), « “Black October” for AI Developer Platforms », rapport de recherche, 30 octobre 2026
  2. [2] Fireworks AI, « October 2026 security incident », bulletin de sécurité et chronologie, publié le 9 octobre 2026, mis à jour le 10 octobre 2026
  3. [3] Jacob Cooper et Angelo Saraceno (Railway), « Preliminary Report: Oct 21st Security Incident », rapport préliminaire, 22 octobre 2026
  4. [4] Railway, « Security disclosure — Wednesday, October 21st », première divulgation, 21 octobre 2026
  5. [5] Zeabur, « October 2026 security incident », rapport d'incident, 14 octobre 2026
  6. [6] Amazon Web Services, « Monitor Amazon Bedrock API calls using CloudTrail », documentation officielle, consultée le 1er novembre 2026

Alpha Oumar Sow

Gufaca — ingénierie logicielle et IA

Profil LinkedIn

Prêt à passer à l’action ?

Réservez une séance de diagnostic de 45 minutes et repartez avec une feuille de route claire.

Réserver un diagnostic