Fireworks AI : des secrets de jobs d’évaluation accessibles après un vol d’identifiants

Activité détectée le 6 octobre 2026 ; bulletin publié le 9, mis à jour le 10. Fireworks AI affirme qu’un tiers a utilisé sans autorisation des identifiants internes et atteint des variables d’environnement de jobs d’évaluation dans un nombre limité de comptes clients. Ces variables pouvaient contenir des clés d’API et des tokens fournis par les clients. L’entreprise n’a pas détecté, au stade de son bulletin, d’accès non autorisé aux modèles, datasets, données d’entraînement, informations personnelles ou trafic d’inférence dans son périmètre. La nuance est capitale : l’accès à des secrets peut ouvrir des systèmes tiers, même si les données hébergées chez Fireworks ne sont pas déclarées lues.

Pourquoi un job d’évaluation lit des secrets

Un job d’évaluation compare des modèles ou des configurations et peut devoir appeler des API externes. Pour cela, la plateforme lui remet des clés comme variables d’environnement au moment de l’exécution. Le service qui orchestre ces jobs doit donc disposer d’une capacité de lecture ou d’injection des secrets. Si des identifiants internes donnent un accès trop large à cette capacité, le chiffrement du stockage ne suffit pas : la plateforme peut avoir besoin de restituer la valeur en clair au job autorisé, et le mauvais acteur peut tenter d’atteindre le même chemin.

Fireworks n’explique pas publiquement comment les identifiants internes ont été obtenus ni quelle API précise a permis la lecture. Il serait donc faux de publier une CVE, un exploit de sandbox ou une traversée inter-clients comme cause établie. Le fait confirmé par l’entreprise est l’usage non autorisé de credentials internes et l’accès aux variables de certains comptes ; elle dit revoir la manière dont les secrets sont rendus disponibles aux jobs d’évaluation. Cette formulation indique une surface à renforcer, pas un diff de correctif public.

Le risque se propage hors de la plateforme

Une clé exposée n’est pas automatiquement utilisée. Si elle l’est, son impact dépend du fournisseur qui l’a émise : inférence facturée, accès à des données, gestion de ressources ou actions sur un dépôt. Fireworks demande donc aux clients touchés de révoquer les identifiants auprès des fournisseurs tiers, puis de vérifier leurs journaux d’activité. Effacer une variable de l’interface Fireworks ne révoque pas la clé chez son émetteur. Le bulletin distingue aussi les clés Fireworks qu’il a lui-même révoquées des clés tierces dont l’action revient aux clients.

La chronologie donnée par Fireworks est utile : détection et début de confinement le 6 octobre, notifications des clients les 7 et 9, rotation de clés employé le 9, puis révocation de clés et tokens supplémentaires le 10. Ces dates montrent une enquête évolutive. L’absence d’indice d’accès aux datasets ou au trafic d’inférence « à ce stade » n’est pas la preuve mathématique qu’aucun système externe accessible via une clé tierce n’a été touché.

Comment auditer cette frontière

Un audit autorisé suivrait la vie d’une variable de sa création jusqu’au job, en listant chaque service capable de la lire, les rôles qui peuvent lancer une évaluation, les journaux de cette lecture et l’isolation entre clients. Il testerait les identifiants internes avec le principe du moindre privilège : un compte chargé de gérer une tâche doit-il pouvoir lire les secrets d’un autre compte ? Des tests de rotation démontrent aussi si une clé révoquée devient réellement inutilisable chez le fournisseur émetteur. Aucun PoC public de l’entrée initiale n’est publié dans le bulletin ; cette méthode est un cadre d’audit, pas une reproduction de l’attaque.

L’incident rappelle qu’un secret stocké dans une plateforme IA conserve tous les droits que son émetteur lui a donnés. La réponse doit donc associer les logs de Fireworks à ceux des fournisseurs externes et limiter durablement l’accès des outils internes aux variables clients.

Source principale : bulletin de sécurité Fireworks AI.