La brèche Klue : comment un jeton oublié depuis 2022 a touché 200 entreprises
Lire la version audio
L'article sur les API expliquait qu'une clé API mérite la même prudence qu'un mot de passe. L'incident Klue, révélé en juin 2026, montre ce qui se passe quand une clé de ce genre reste active pendant des années après avoir cessé d'être utile.
Ce qui s'est passé
Entre le 11 et le 24 juin 2026, des attaquants ont utilisé un identifiant d'intégration ancien, un jeton OAuth émis en 2022 dans le cadre d'un projet pilote limité et jamais révoqué depuis, pour accéder à l'infrastructure d'intégration de Klue, une entreprise spécialisée dans les logiciels de veille concurrentielle. Depuis cet accès initial, les attaquants ont poussé une mise à jour de code malveillante conçue pour récolter d'autres jetons OAuth, ceux qui permettent à Klue de se connecter aux plateformes de ses propres clients, notamment Salesforce. Avec ces jetons volés, les attaquants ont pu se faire passer pour Klue directement à l'intérieur des environnements Salesforce de près de 200 organisations clientes, et en extraire des données. Parmi les entreprises touchées figurent plusieurs sociétés de cybersécurité reconnues, dont Huntress, Recorded Future, Tanium et Jamf.
Le jeton OAuth, une clé API qu'on oublie d'annuler
Un jeton OAuth fonctionne exactement comme la clé API décrite dans l'article dédié : une autorisation numérique qui permet à un service d'agir au nom d'un autre, sans avoir à repartager un mot de passe à chaque connexion. Le problème central de cet incident ne vient pas d'une faiblesse du mécanisme OAuth lui-même, mais d'une négligence beaucoup plus banale : ce jeton précis avait été créé pour un projet pilote limité en 2022, et personne ne l'avait révoqué une fois ce pilote terminé. Il est resté actif et fonctionnel pendant plus de quatre ans, un accès permanent que plus personne ne surveillait activement, jusqu'à ce qu'un attaquant le découvre et s'en serve.
L'attaque en cascade : une seule brèche devient 200
Le point le plus révélateur de cet incident tient à sa mécanique de propagation : aucune des 200 organisations touchées n'a été attaquée directement. Les attaquants ont compromis un seul fournisseur, Klue, puis se sont appuyés sur la confiance déjà accordée entre Klue et chacune de ses plateformes clientes pour atteindre toutes ces organisations à la fois, sans avoir besoin de percer les défenses propres à chacune d'entre elles. C'est le principe même d'une attaque de la chaîne d'approvisionnement logicielle (supply chain) : plutôt que d'attaquer directement une cible bien défendue, l'attaquant vise un intermédiaire plus petit, moins surveillé, mais connecté avec un niveau de confiance élevé à des dizaines ou des centaines d'organisations en même temps.
L'ironie : des entreprises de cybersécurité elles-mêmes touchées
Que plusieurs entreprises spécialisées dans la cybersécurité figurent parmi les victimes de cette brèche illustre un point déjà rencontré cette semaine sur ce site (voir l'article sur le piratage d'Aura) : aucune organisation, quelle que soit son expertise en sécurité, n'est à l'abri d'une brèche survenue chez un fournisseur tiers auquel elle avait accordé sa confiance. Une entreprise peut parfaitement sécuriser ses propres systèmes tout en restant exposée par un maillon plus faible ailleurs dans sa chaîne de fournisseurs, un maillon qu'elle ne contrôle pas et qu'elle ne voit souvent pas du tout.
Le rebondissement : des pirates piratés par d'autres pirates
Cet incident a pris une tournure inhabituelle par la suite. Le groupe cybercriminel Icarus a revendiqué la brèche initiale et menacé de publier les données volées si Klue ne payait pas de rançon. Un second groupe a ensuite affirmé avoir lui-même compromis Icarus et dérobé les données déjà volées par ce premier groupe, un rebondissement rare qui montre qu'un groupe de cybercriminels n'est pas lui-même à l'abri d'être piraté à son tour, avec pour conséquence que des données déjà exfiltrées une fois peuvent se retrouver entre les mains d'un troisième acteur, totalement imprévisible dès le départ.
Ce que ça change, concrètement
Pour une organisation qui accorde un accès à un service tiers, même temporaire ou limité à un simple essai, cet incident rappelle qu'un jeton ou une clé d'intégration doit être révoqué activement une fois son usage terminé, plutôt que supposé expiré ou oublié de lui-même. Maintenir un inventaire réel des accès tiers encore actifs, et pas seulement de ceux créés récemment, aurait suffi à éviter cette brèche précise. Pour un simple utilisateur, ça reste un rappel supplémentaire qu'une donnée confiée à un service peut fuiter par un partenaire technique complètement invisible et jamais choisi directement, une raison de plus de limiter, quand c'est possible, les informations partagées même avec des services a priori dignes de confiance.