Fireworks AI touchée via la compromission d’un fournisseur cloud tiers

23 octobre 2026. Un fournisseur cloud tiers qui hébergeait les machines de R&D de Fireworks AI subit un incident de sécurité. 24 octobre. L’attaquant s’en sert pour atteindre les machines de développement de Fireworks et y exécuter une charge non autorisée. 10 novembre. L’entreprise publie l’avis qui détaille l’étendue : métadonnées de ressources, données de facturation et poids de modèles incomplets de certains clients. Pourquoi c’est important : c’est la seconde brèche de Fireworks en un mois, et cette fois la porte d’entrée n’est pas chez Fireworks mais chez son fournisseur cloud.

Une plateforme d’inférence, une double exposition

Fireworks AI vend une plateforme d’inférence : les développeurs y déploient des modèles open source — Mistral, Llama de Meta, Gemma de Google — sans gérer le matériel. Cette position la rend doublement exposée. Elle détient d’une part les clés d’API et jetons de ses clients ; d’autre part, elle s’appuie elle-même sur des fournisseurs cloud pour ses propres machines de développement et de R&D.

Le premier incident, début octobre, avait déjà montré la première face : des attaquants avaient accédé à des variables d’environnement contenant des clés d’API et jetons pour un nombre limité de comptes. Fireworks l’avait relié à un acteur financièrement motivé qui revend des jetons d’accès à des modèles via des passerelles illicites — une pratique que le secteur appelle le LLMjacking.

Le second incident exploite la seconde face, plus discrète : la chaîne d’approvisionnement cloud.

La compromission du fournisseur, le talon d’Achille

Le 23 octobre, un fournisseur cloud tiers hébergeant les machines de R&D de Fireworks subit un incident. Le 24, l’acteur non autorisé l’utilise comme tremplin pour atteindre les machines de développement de Fireworks, puis y lancer une charge de travail non autorisée qui a étendu l’impact aux données clients.

Ce qui a fui tient en une liste froide : identifiants de ressources, noms, descriptions, dates de création, adresses de facturation et de livraison, historique de facturation et de paiement, solde et consommation de crédits, et des poids de modèles et jeux de données incomplets pour certains clients. Fireworks précise que les numéros de carte bancaire n’étaient pas accessibles, car l’entreprise ne les stocke pas.

L’entreprise a réagi le jour même : révocation et remplacement des identifiants et comptes de service, restriction des chemins réseau non autorisés, isolation des systèmes touchés, et durcissement de l’accès au stockage et aux systèmes d’analyse. Elle travaille désormais avec la division de réponse à incident Unit 42 de Palo Alto Networks pour évaluer l’étendue complète.

Le LLMjacking est le moteur de ce type d’attaque

Cette brèche n’est pas un accident isolé. Une semaine plus tôt, Google Threat Intelligence Group et Mandiant rapportaient que le LLMjacking — le détournement d’accès à des modèles — fait grimper les factures cloud des victimes jusqu’à 1 million de dollars en appels frauduleux via des clés d’API volées. Le mobile n’est pas l’espionnage : c’est la revente de puissance d’inférence.

Ce mobile change la lecture de l’incident Fireworks. Un attaquant qui entre par un fournisseur cloud ne cherche pas forcément les secrets les plus profonds : il cherche un chemin vers des jetons d’inférence revendables. Les poids de modèles incomplets mentionnés dans l’avis s’inscrivent dans cette logique de captation de valeur, pas dans un vol de propriété intellectuelle classique.

Ce que doit faire un client cloud après un tel avis

Un client de Fireworks reçoit l’avis sans avoir rien fait de mal — et c’est précisément le point. La règle devient : traiter la compromission d’un fournisseur amont comme une menace qui vous concerne directement. Trois vérifications s’imposent :

• Auditer les clés d’API et jetons émis. Une clé émise puis volée chez un fournisseur peut être réutilisée contre vous ailleurs. Faites tourner les secrets exposés à ce fournisseur, pas seulement ceux que vous avez « perdus ».
• Surveiller la consommation de crédits et les workloads inattendus. Le LLMjacking se voit d’abord dans la facture : un pic d’inférence que personne n’a déclenché est le symptôme le plus fiable.
• Limiter le rayon d’une fuite de données. Les données que vous confiez à un fournisseur cloud doivent être réduites au strict nécessaire — un fournisseur ne peut pas perdre ce qu’il ne détient pas.

La responsabilité partagée ne couvre pas la chaîne d’approvisionnement

Le modèle de responsabilité partagée des clouds est clair sur la frontière entre l’infrastructure et le client. Il l’est beaucoup moins sur la chaîne d’approvisionnement : quand c’est le fournisseur de votre fournisseur qui tombe, personne n’a signé de clause pour ce cas. Fireworks n’a pas « mal configuré » un stockage ; c’est l’hébergeur de ses machines de R&D qui a été compromis, et la faille a ensuite traversé la frontière.

C’est la leçon structurelle de l’incident : votre surface d’attaque inclut désormais les fournisseurs de vos fournisseurs. Un audit classique — le vôtre, celui de votre fournisseur direct — ne détecte pas ce maillon. Ce qu’il faut exiger, c’est de la traçabilité : qui héberge quoi, avec quel niveau de segmentation entre machines de développement et données clients, et quel avis daté et chiffré est publié quand ça casse.

Une semaine qui raconte la tendance

L’incident Fireworks n’est pas seul. La même semaine, le distributeur japonais Iris Ohyama a révélé que les données de 7,7 millions de clients de sa plateforme Iris Plaza avaient pu être exposées via un service cloud tiers compromis — pas ses propres systèmes. L’éditeur SEGA a signalé de son côté que 2,2 millions d’adresses e-mail avaient fui par son prestataire de newsletter, ARARA.

Trois brèches, trois fournisseurs différents, un seul schéma : le maillon faible n’est plus le client final, c’est l’écosystème de sous-traitants qui l’entoure. Pour un RSSI, la conséquence est une liste de questions à poser à chaque fournisseur cloud, et une règle de sortie claire quand les réponses manquent — un fournisseur qui ne publie pas d’avis daté après un incident est un fournisseur à remplacer.

Verdict

Si vous consommez un service cloud tiers, en particulier une plateforme d’inférence, traitez la compromission de son fournisseur amont comme votre propre incident : faites tourner les clés d’API et jetons émis, surveillez la facture et les workloads, et réduisez les données que vous confiez. La leçon de Fireworks tient en une phrase : la frontière de votre périmètre n’est plus votre console cloud, c’est la console de tous vos fournisseurs. Si votre fournisseur ne publie pas d’avis de sécurité daté et chiffré après un tel événement, c’est un signal de sortie, pas un détail de conformité.

Références

• BleepingComputer — « Fireworks AI discloses new breach after cloud provider hack » (10 novembre 2026)
• Fireworks AI — bulletin de sécurité « October 2026 Security Incident Update »
• Fireworks AI — bulletin de sécurité « October 2026 Security Incident »
• BleepingComputer — « Google: LLMjacking attacks rack up $1 million in cloud AI charges »