Fireworks AI étend l’impact d’une faille sur comptes et modèles

Fireworks AI a élargi, le 9 novembre 2026, la portée d’un incident de sécurité survenu en octobre : des attaquants ont accédé à des informations de compte et de facturation, et, pour un nombre limité de clients, à des secrets, des jeux de données et des poids de modèle incomplets. L’entreprise, fournisseur d’infrastructure pour l’IA, avait d’abord parlé d’une utilisation non autorisée de credentials internes. La mise à jour change la lecture du dossier, car elle relie une compromission d’environnement de développement à des actifs d’IA et à des flux de travail perturbés.

Du vol de credentials à la compromission de machines de développement

Le premier signal remonte au 6 octobre 2026, quand Fireworks a détecté une utilisation non autorisée de credentials internes et engagé un confinement. À ce stade, la société indiquait n’avoir trouvé aucun accès illégitime aux modèles clients, aux données d’entraînement, aux données personnelles ou au trafic d’inférence dans son périmètre de sécurité. Puis, le 23 octobre 2026, un fournisseur cloud tiers hébergeant des machines de recherche et développement a connu un incident de sécurité. Le 24 octobre, l’attaquant s’est servi de cette voie d’entrée pour atteindre des machines de développement Fireworks et exécuter une charge de travail non autorisée.

Fireworks dit avoir détecté cette activité le jour même, appliqué des mesures de remédiation et fermé les vulnérabilités critiques connues. La société précise qu’au 25 octobre 2026, elle n’avait pas observé d’autres accès non autorisés réussis sur la plateforme utilisée par les clients. Les notifications client ont commencé le 7 octobre, puis l’entreprise a tourné les clés API des employés le 9 octobre, révoqué d’autres clés utilisateurs et remplacé des jetons de comptes de service le 10 octobre.

Ce que les attaquants ont vu, et ce qu’ils n’ont pas touché

Les données exposées couvrent plusieurs couches. L’application interne compromise donnait accès à des métadonnées de ressources, dont des identifiants, noms affichés, descriptions et dates de création. La partie facturation incluait adresses de facturation et de livraison, historique des factures et des paiements, soldes de compte et crédit consommé. Fireworks rappelle ne pas stocker les numéros de carte bancaire, qui n’ont donc pas été affectés.

Pour une poignée de clients, l’impact va plus loin : secrets, jeux de données et poids de modèle incomplets ont été concernés. L’entreprise envoie des détails propres à chaque compte touché et recommande des réponses adaptées, tout en précisant que l’enquête peut encore faire apparaître de nouveaux éléments. Oui, même les incidents de sécurité aiment parfois les rebondissements, ce qui n’est jamais le genre de suspense qu’un DSI réclame un vendredi soir.

Des restrictions temporaires sur les jeux de données

En attendant la fin de l’enquête, certaines opérations côté client restent limitées. Les envois et téléchargements de jeux de données en self-service utilisés par Batch Inference et l’entraînement sur données sont désactivés. En revanche, Training SDK reste disponible avec une rétention nulle des données, ce qui signifie qu’aucune donnée d’entraînement n’est stockée au repos. Fireworks Lab-based training fonctionne, lui, dans un environnement isolé avec des protections supplémentaires sur le réseau et le stockage.

L’entreprise indique qu’aucun impact n’a été détecté sur Inference, Training SDK ou Nexus, tous configurés par défaut en zero data retention. Cette conclusion reste toutefois limitée à l’état de l’enquête. La documentation de sécurité de Fireworks précise aussi que les prompts et générations d’inférence pour les modèles ouverts ne sont ni journalisés ni conservés sans opt-in explicite, tandis que Nexus ne stocke pas les prompts, réponses, code, appels d’outils ou traces, même s’il conserve des métadonnées de service nécessaires au fonctionnement puis les dé-identifie après 30 jours.

LLMJacking : quand l’accès IA se revend sur un marché noir

Fireworks relie l’activité à un groupe cybercriminel motivé financièrement, dont l’objectif serait de revendre un accès non autorisé à des LLM via des passerelles de routage illicites. Ce type d’activité porte un nom : LLMJacking, soit la revente d’accès à des modèles via des intermédiaires clandestins. L’entreprise cite des recherches publiées le 2 novembre 2026 par Google Threat Intelligence Group et Mandiant sur les LLM Mixers, ces passerelles qui proxyfient, agrègent et revendent un accès illégitime à des abonnés du marché souterrain.

Ces recherches décrivent aussi des schémas de monétisation en plusieurs temps : une équipe compromet l’environnement, une autre exploite ensuite l’accès pour générer du trafic payant. Dans les enquêtes citées, les frais frauduleux liés à la consommation de ressources ont dépassé 100 000 dollars en une seule journée dans certains cas, et atteint 1 million de dollars cumulés avant révocation de l’accès dans certaines organisations. Ces montants concernent les enquêtes de Mandiant, pas les pertes de Fireworks. Les chercheurs notent enfin que des jetons d’identité cloud exposés ou volés ont été la porte d’entrée la plus fréquente.

Pourquoi l’incident compte pour les clients cloud et IA

Le dossier montre qu’une sécurité centrée sur les clés d’accès ne suffit pas toujours. Fireworks dit avoir révoqué et remplacé des credentials et comptes de service, réduit les privilèges élevés inutiles, bloqué des chemins réseau non autorisés, isolé des systèmes touchés et renforcé la journalisation et la supervision. Ces mesures recoupent plusieurs recommandations formulées par Google Threat Intelligence Group et Mandiant : gestion centralisée des secrets, principe du moindre privilège, audits de configuration réguliers, contrôles de dépenses et détection de requêtes anormales de faible volume.

Pour les clients, le vrai sujet n’est donc pas seulement de remplacer des clés API. Il faut aussi vérifier les journaux associés, repérer des clés, utilisateurs, évaluateurs, jobs d’entraînement ou jeux de données inconnus, et, quand des secrets tiers sont concernés, les faire révoquer chez l’émetteur d’origine. Fireworks prévient d’ailleurs qu’effacer un secret stocké ne suffit pas à invalider le credential tiers sous-jacent. Cette nuance paraît administrative ; en pratique, elle évite de laisser une porte entrouverte pendant qu’on croit l’avoir fermée.