Brèche Fireworks AI : check-list des risques fournisseurs d'inférence après l'incident LLMjacking

La brèche de Fireworks AI est l'un des exemples récents les plus clairs d'un risque qui transite par un fournisseur d'inférence hébergée pour finir chez ses clients. En octobre 2026, Fireworks AI a divulgué un incident de sécurité. Une mise à jour ultérieure a ensuite décrit une seconde intrusion et un impact plus large.

Vous trouverez ci-dessous ce que Fireworks a réellement publié, suivi d'un plan de réponse que nous appelons le playbook Secrets, Données, Dépenses. Vient ensuite une check-list de due diligence pour vos futures évaluations de fournisseurs.

Ce que Fireworks a divulgué : deux intrusions, dans l'ordre

Fireworks a publié un bulletin de sécurité initial et une mise à jour de suivi. Lus côte à côte, ils décrivent deux intrusions distinctes.

Le premier incident, identifié le 6 octobre, impliquait l'utilisation non autorisée d'identifiants internes de Fireworks. Selon le bulletin initial, un tiers non autorisé a accédé aux variables d'environnement utilisées dans les jobs d'évaluation d'un nombre limité de comptes clients.

Le second est passé par un fournisseur. Un fournisseur cloud tiers qui hébergeait les machines de R&D de Fireworks a subi un incident de sécurité le 23 octobre. Le lendemain, 24 octobre, l'attaquant a utilisé cet accès pour atteindre les machines de développement de Fireworks et exécuter une charge de travail non autorisée, ce qui a entraîné un impact supplémentaire sur les données clients.

La mise à jour a également modifié la vision de ce qui a été dérobé. Lors de la publication du premier bulletin, seuls les secrets stockés chez Fireworks étaient connus comme ayant été consultés. L'enquête approfondie a révélé des impacts sur les informations de compte et de facturation et, pour un ensemble limité de comptes, sur des secrets, des jeux de données et des modèles incomplets.

Concernant l'attribution, l'entreprise cite des éléments reliant l'activité à un groupe cybercriminel motivé par l'appât du gain qui revend des tokens issus d'accès non autorisés à des LLM à des passerelles de routage illicites, une pratique qu'elle appelle « LLMJacking ».

Il reste une lacune dans le dossier. Selon The Register, la mise à jour ne précisait pas combien de clients chacune des attaques avait touchés. Tant que Fireworks n'en dit pas plus, confirmez votre propre exposition directement auprès du fournisseur.

Ce qui a été exposé, ce qui ne l'a pas été et ce que Fireworks a changé

Lors du premier incident, Fireworks estime que des variables d'environnement, y compris des clés API et des tokens stockés en tant que secrets, ont été capturées dans certains comptes affectés. Un secret présent dans l'environnement d'un job a rarement d'intérêt en soi ; sa valeur tient à ce qu'il permet d'ouvrir ailleurs.

Les informations de facturation exposées comprenaient les adresses de facturation et de livraison, l'historique des factures et des paiements, le solde du compte et la consommation de crédits. Les numéros de carte de paiement sont un cas à part : l'entreprise affirme ne pas les stocker et indique qu'ils n'ont pas été affectés.

Concernant les poids des modèles, Lin Qiao, CEO de l'entreprise, a déclaré à The Register que les attaquants ne semblaient pas chercher à obtenir les poids et que la plupart des téléchargements étaient partiels et avaient été interrompus. Considérez cela comme l'évaluation propre du fournisseur, et non comme une conclusion indépendante.

L'impact se propage également en aval. Notion, client de Fireworks, a informé les utilisateurs concernés que leurs espaces de travail faisaient partie des moins de 1 % des espaces de travail Notion susceptibles d'avoir été touchés par l'incident Fireworks.

Le produit a évolué en conséquence. Les téléversements et téléchargements de jeux de données en libre-service utilisés par Batch Inference et par l'entraînement basé sur des jeux de données ont été désactivés pendant l'enquête. La documentation sur le fine-tuning indique désormais que les évaluateurs et les jobs d'évaluation ont été supprimés. Il s'agit de la fonctionnalité même dont les variables d'environnement avaient été exposées lors du premier incident.

Pourquoi le LLMjacking transforme une clé divulguée en facture salée

Le LLMjacking désigne le vol et la revente d'accès à l'inférence de modèles.

Le Google Threat Intelligence Group indique qu'au fil de plusieurs enquêtes sur ce qu'il appelle le « LLMJacking », le principal vecteur d'accès initial a été des tokens d'identité cloud exposés ou volés. Il s'agit notamment d'identifiants IAM, de clés de comptes de service, de personal access tokens GitHub et de tokens de session actifs. Remarquez à quel point cette liste dépasse largement les seules clés API de modèles. Pour les défenseurs, c'est le point essentiel.

Google décrit les « LLM Mixers » comme des passerelles de routage illicites qui relaient, agrègent et revendent des accès non autorisés à des LLM à des abonnés clandestins. Un service, Jet Night, propose une formule de tokens illimités pour environ $60 par mois avec un accès présumé à des modèles de pointe, alors qu'un service grand public de ce niveau coûterait généralement entre $100 et $250 par mois.

Quelqu'un paie la différence, et c'est la victime. Dans les incidents décrits par Google, les frais frauduleux ont dépassé $100,000 en une seule journée, et les frais cumulés de certaines organisations ont atteint $1 million avant la révocation des accès. Dans un cas, un acteur malveillant a effectué plus de 500,000 appels d'API LLM en moins de huit heures, en utilisant des clés API tierces volées pour alimenter Jet Night, et le service a répercuté près de $1 million de coûts de tokens sur l'organisation victime.

Des recherches antérieures vont dans le même sens. L'analyse initiale de 2024 de Sysdig estimait qu'une attaque non détectée pouvait coûter à une victime plus de $46,000 par jour en consommation de LLM. Des travaux ultérieurs de Sysdig indiquaient que ce montant avait presque triplé pour dépasser $100,000 par jour avec des modèles haut de gamme comme Claude 3 Opus.

Le playbook Secrets, Données, Dépenses pour les clients d'inférence hébergée

Ces sept étapes s'appliquent à cet incident comme au prochain du même type, quel que soit le fournisseur.

Secrets : ce que vous avez confié

Étape 1 : inventoriez chaque secret stocké. Listez chaque secret stocké chez le fournisseur, en portant une attention particulière aux variables d'environnement associées aux jobs d'évaluation, de batch ou d'entraînement. Puisque des clés API et des tokens stockés en tant que secrets ont été capturés dans certains comptes affectés, considérez tout secret concerné comme compromis jusqu'à preuve du contraire.

Étape 2 : effectuez la rotation à la source. Révoquez et réémettez chaque identifiant tiers auprès du fournisseur qui l'a émis. Le fournisseur est explicite : supprimer un secret stocké ne suffit pas à invalider l'identifiant sous-jacent, et les identifiants tiers nécessitent une action auprès de leurs émetteurs. À plus long terme, tenez complètement les clés brutes à l'écart des environnements d'exécution des jobs. Les équipes peuvent envisager un proxy d'identifiants à cette fin ; consultez notre guide des proxys d'identifiants pour agents IA.

Étape 3 : délimitez le rayon d'impact. Pour chaque clé renouvelée, notez ce à quoi elle pouvait accéder (comptes cloud, dépôts, bases de données, autres API de modèles) et examinez les journaux de ces systèmes pour repérer toute activité postérieure à la fenêtre d'exposition. Accordez aux tokens d'identité cloud et aux tokens GitHub la même priorité qu'aux clés de modèles ; dans les enquêtes de Google, ils constituaient la voie d'entrée la plus fréquente.

Données : ce que vous avez téléversé

Étape 4 : examinez les jeux de données et les modèles. Déterminez quels jeux de données, jobs de fine-tuning et modèles incomplets se trouvaient sur la plateforme. Décidez ensuite si certaines de ces données déclenchent une obligation de notification envers des clients, au titre de contrats ou de la réglementation. Impliquez un conseil juridique dès le début.

Étape 5 : adaptez les workflows concernés. Organisez-vous autour de la suspension des fonctionnalités de jeux de données pour Batch Inference et l'entraînement basé sur des jeux de données. Décidez si vous téléverserez à nouveau les données lorsque les fonctionnalités reviendront ou si vous les conserverez désormais dans votre propre environnement.

Dépenses : ce que vous surveillez

Étape 6 : informez la finance de l'exposition des données de facturation. Des adresses, historiques de factures et soldes divulgués fournissent à un fraudeur des détails utiles pour un e-mail de phishing crédible ou une fausse facture. Demandez aux équipes finance et comptabilité fournisseurs de confirmer toute demande de paiement inattendue ou tout changement de coordonnées bancaires par un canal qu'elles jugent déjà fiable.

Étape 7 : plafonnez et surveillez chaque clé restante. Définissez des alertes de dépenses et des plafonds stricts par clé, à la fois chez le fournisseur et dans votre propre facturation cloud. Acheminez-les vers un canal d'astreinte, et non vers une boîte partagée que personne ne lit la nuit. La section sur la surveillance ci-dessous précise les signaux à suivre.

Quel que soit le groupe, consignez chaque décision avec un horodatage et un responsable.

Qui pilote chaque étape

Utilisez ceci comme point de départ par défaut. Dans une petite équipe, une même personne peut couvrir plusieurs rôles. L'essentiel est que chaque étape ait un responsable nommément désigné.

Où s'applique la conservation zéro des données, et où elle ne s'applique pas

Selon la documentation sur le traitement des données de Fireworks, l'entreprise applique par défaut la conservation zéro des données (zero data retention, ZDR), ce qui signifie qu'elle ne journalise ni ne stocke les données de prompts ou de génération pour aucun modèle ouvert sans activation explicite par l'utilisateur. Sa page sur la politique ZDR ajoute une réserve : quelques fonctionnalités stockent bien du contenu client, comme les réponses stockées, les jobs batch et l'entraînement.

Regardez ce que la brèche a réellement touché : du contenu stocké, sous forme de jeux de données et de modèles incomplets, ainsi que des secrets, que la ZDR n'a jamais eu vocation à couvrir. Une ZDR par défaut est précieuse pour l'inférence en temps réel. Ce n'est pas une promesse portant sur tout ce que vous envoyez. Nous recommandons de vérifier les paramètres de conservation de chaque fournisseur que vous utilisez plutôt que de supposer qu'ils sont identiques ; notre guide sur le stockage des requêtes de l'API Gemini est une lecture complémentaire.

En pratique, étiquetez chaque charge de travail comme inférence seule ou contenu stocké. Pour les téléversements batch ou de fine-tuning, supprimez les champs dont le modèle n'a pas besoin, masquez les données personnelles quand c'est possible et conservez la copie maîtresse dans votre propre environnement.

Check-list de due diligence fournisseur : questions à poser à tout fournisseur d'inférence

Apportez-les lors des revues d'achats, des renouvellements et des questionnaires de sécurité. Chacune découle de la chronologie Fireworks ou du schéma plus large du LLMjacking.

• [ ] Gestion des secrets : Où sont stockés les secrets clients, qui peut les lire, et les environnements d'exécution des jobs les reçoivent-ils sous forme de variables d'environnement en clair ?
• [ ] Chaîne d'approvisionnement : Quels clouds tiers hébergent les machines de R&D ou de développement, et comment sont-ils isolés des données clients ?
• [ ] Cartographie de la conservation : Quelles fonctionnalités stockent du contenu client ? Comme le montre la section précédente, cela varie selon la fonctionnalité ; obtenez donc la réponse par écrit.
• [ ] Communication en cas d'incident : Le fournisseur indiquera-t-il combien de clients ont été touchés, et comment les mises à jour vous parviendront-elles ?
• [ ] Cycle de vie des fonctionnalités : Lorsqu'une fonctionnalité est retirée, comme les évaluateurs et les jobs d'évaluation ici, comment ses secrets et ses données sont-ils purgés ?
• [ ] Contrôles de facturation : Pouvez-vous définir des plafonds de dépenses, des quotas par clé et des alertes d'anomalie qui atteignent un canal d'astreinte ?
• [ ] Portée des identifiants : Les clés peuvent-elles être limitées à des modèles, projets ou environnements précis, et renouvelées sans interruption de service ?
• [ ] Accès aux journaux : Pouvez-vous voir qui a lu vos secrets et quand ?

De bonnes réponses ne feront pas disparaître le risque. Les équipes qui répartissent leur trafic entre plusieurs fournisseurs peuvent aussi souhaiter des contrôles de routage et de budget au niveau de la passerelle ; consultez notre playbook sur les passerelles IA.

Surveiller le LLMjacking : les signaux qui peuvent apparaître avant la facture

Le LLMjacking a tendance à être bruyant. Ses signaux apparaissent souvent dans les données d'utilisation bien avant l'arrivée de la facture, à condition que quelqu'un les surveille.

• Pics de volume. Sysdig a détecté plus de 85,000 requêtes vers l'API Bedrock lors d'une campagne, dont 61,000 sur une fenêtre de trois heures le 11 juillet 2024. Un tel pic devrait déclencher une alerte d'astreinte.
• Anomalies de débit. Le cas Jet Night, plus de 500,000 appels en moins de huit heures, dépasse probablement de loin tout ce que vos clés font habituellement. Déclenchez des alertes en cas d'écart important par rapport au débit habituel de chaque clé. Le traçage GenAI avec OpenTelemetry est un moyen de collecter les données d'utilisation nécessaires pour établir cette référence.
• Seuils de dépenses. Les plafonds horaires ou journaliers de l'étape 7 limitent les dégâts à l'échelle journalière rapportée par Google. Une revue mensuelle en est incapable.
• Schémas inhabituels. Surveillez les appels à des modèles que vous n'utilisez pas habituellement, les nouvelles régions, les adresses IP sources inconnues et l'activité à des heures inhabituelles.
• L'identité, pas seulement les clés. Considérez tout token d'identité cloud volé comme un point d'entrée possible pour le LLMjacking.

Cette tendance n'a pas commencé avec Fireworks. Sysdig a signalé une hausse de 10x des requêtes de LLMjacking en juillet 2024, et deux fois plus d'adresses IP uniques impliquées dans ces attaques au cours du premier semestre 2024.

Erreurs fréquentes des équipes après une brèche chez un fournisseur d'inférence

• Confondre suppression et révocation. Effacer un secret d'un tableau de bord relève du simple ménage. Ce n'est pas une rotation (voir l'étape 2).
• Surinterpréter un badge ZDR. Consultez le tableau de conservation avant de supposer qu'une charge de travail n'a jamais été stockée.
• Ne renouveler que la clé évidente. Les clés IAM, les clés de comptes de service et les tokens GitHub stockés à côté de la clé de modèle comptent tout autant. Dans les enquêtes de Google, les tokens d'identité cloud étaient le point d'entrée le plus fréquent.
• Considérer le premier bulletin comme définitif. Ici, le périmètre s'est étendu des secrets stockés aux informations de facturation, aux jeux de données et aux modèles incomplets. Réévaluez votre exposition à chaque mise à jour.
• Attendre la facture mensuelle. Aux rythmes de pertes journalières décrits plus haut, une facture arrive bien trop tard pour être utile.

Mises en garde : ce qui reste inconnu et comment lire les chiffres

• Fireworks n'a pas divulgué combien de clients ont été touchés.
• L'affirmation selon laquelle les attaquants ne visaient pas les poids des modèles provient de Lin Qiao, CEO de Fireworks, et n'a pas été vérifiée de manière indépendante.
• Les chiffres de coût du LLMjacking proviennent d'enquêtes du Google Threat Intelligence Group et de Sysdig portant sur d'autres victimes, et non sur cet incident. Ils montrent ce qui est possible, pas ce que les clients de Fireworks ont perdu.
• Les chiffres de Sysdig datent de 2024 et reflètent les tarifs des modèles et les volumes d'attaque de cette période.
• Le chiffre de moins de 1 % avancé par Notion ne concerne que les espaces de travail Notion.
• Les obligations de notification dépendent de votre juridiction et de vos contrats ; demandez donc un avis juridique lorsqu'elles s'appliquent.