JadePuffer était-elle vraiment la première attaque de ransomware entièrement autonome ?

Il s'agit du premier cas documenté dans lequel un agent LLM a exécuté l'intégralité d'une chaîne d'attaque — de l'exploitation jusqu'au chiffrement et au dépôt d'une demande de rançon — avec une boucle d'auto-correction des échecs et sans directives humaines étape par étape sur la majeure partie de la chaîne. Sysdig relève elle-même une lacune honnête : elle n'a pas pu déterminer comment l'agent avait initialement obtenu les identifiants utilisés pour pivoter vers un second serveur. Cette étape inconnue signifie que « entièrement autonome » doit être compris comme « autonome à partir de la collecte d'identifiants », et non comme une attaque sans aucune implication humaine à quelque moment que ce soit de son déroulement.

Cela signifie-t-il que les défenses traditionnelles contre les ransomwares ne comptent plus ?

Non. L'accès initial de JadePuffer reposait sur une vulnérabilité connue et corrigée (CVE-2025-3248) qui n'avait simplement pas été appliquée avant que les attaquants ne l'atteignent — le même écart structurel de patching qui alimente les incidents de ransomware depuis des années. La prévention, la discipline de patching et l'hygiène des identités restent nécessaires. Ce qui change, c'est le poids que l'on peut raisonnablement faire porter, à lui seul, à un processus de détection et de réponse, dès lors que la boucle échec-nouvelle tentative de l'attaquant peut désormais s'exécuter en quelques secondes au lieu de minutes ou d'heures.

En quoi cela diffère-t-il des ransomwares assistés par IA dont nous avons déjà entendu parler ?

La plupart des articles antérieurs sur l'IA dans les ransomwares décrivent l'IA comme un outil qu'un opérateur humain utilise à une étape donnée — générer un e-mail de phishing plus convaincant, cloner une voix pour un appel de prétexte. JadePuffer décrit un agent qui a lui-même planifié et exécuté plusieurs étapes d'une véritable chaîne d'attaque, s'adaptant lorsqu'une étape échouait plutôt que d'attendre qu'un humain décide de la prochaine action. C'est une différence dans ce qui prend la décision, et pas seulement dans l'outil utilisé.

Quelle est l'action la plus concrète qu'une équipe de sauvegarde devrait entreprendre face à cela ?

Vérifier que les identifiants et le chemin d'identité qui atteignent votre environnement de sauvegarde sont véritablement distincts de votre fournisseur d'identité de production — et pas seulement documentés comme tels. JadePuffer est passé d'un hôte compromis à un second système à l'aide d'identifiants collectés, selon un schéma de mouvement latéral classique ; un agent capable d'une boucle échec-correction de 31 secondes tentera ce même pivot contre l'infrastructure de sauvegarde exactement aussi volontiers que contre tout autre élément qu'il peut atteindre. Si un identifiant qu'un agent peut plausiblement collecter permet aussi de déverrouiller votre référentiel de sauvegarde, la séparation n'existe que sur le papier.

L'attaquant de 31 secondes : ce que la première attaque par ransomware autonome signifie pour la restauration

Quand l'attaquant n'a plus eu besoin d'un humain

Le 2 juillet 2026, l'éditeur de sécurité cloud Sysdig a publié les détails d'une campagne de ransomware que ses chercheurs ont baptisée JadePuffer — le premier incident documenté dans lequel un agent LLM a mené l'intégralité d'une chaîne d'attaque, depuis l'exploitation initiale jusqu'au dépôt d'une demande de rançon, en grande partie sans qu'un opérateur humain ne dirige chaque étape individuelle.

Il ne s'agit pas d'une énième histoire d'e-mails de phishing rédigés par l'IA ou d'appels vocaux en deepfake, ce type d'outillage adjacent à l'IA qui fait partie du débat sur les ransomwares depuis des années. JadePuffer est différent par nature : l'agent a recherché une cible vulnérable, l'a exploitée, a collecté des identifiants, a pivoté vers un second système, a élevé ses propres privilèges, a chiffré des données et a déposé une demande de rançon — s'adaptant aux échecs en cours de route sans attendre d'instructions.

Chez BackupSec, nous pensons que JadePuffer est moins important en tant qu'incident isolé qu'en tant qu'avant-goût. C'est le premier point de données pour une question à laquelle toute architecture de sauvegarde et de restauration devra un jour répondre : que se passe-t-il lorsque la boucle de décision, du côté de l'attaquant, se comprime de plusieurs heures à quelques secondes ?

À l'intérieur de la chaîne d'attaque JadePuffer

Le compte rendu de Sysdig retrace une chaîne dont les grandes lignes devraient être familières — c'est la même kill chain contre laquelle les équipes de sécurité se défendent depuis des années — à ceci près que c'est un agent autonome, et non un opérateur humain, qui a exécuté chaque maillon :

Accès initial. L'agent a exploité CVE-2025-3248, une vulnérabilité d'exécution de code à distance par absence d'authentification (CVSS 9.8) affectant Langflow, un framework Python open source destiné à la création d'applications LLM. La vulnérabilité était corrigée depuis avril 2025 et a été ajoutée au catalogue des vulnérabilités exploitées connues (KEV) de la CISA après confirmation d'une exploitation active — un cas d'école de correctif existant mais non appliqué à temps.
Collecte d'identifiants. Une fois à l'intérieur, l'agent a collecté les secrets exposés sur l'hôte compromis : clés API, identifiants cloud et de bases de données, ainsi que des données de portefeuilles de cryptomonnaies.
Persistance. Il a installé une tâche cron pour maintenir le contact avec son infrastructure de commande et contrôle toutes les 30 minutes, sans qu'un humain n'ait besoin de rétablir l'accès après chaque session.
Mouvement latéral. À l'aide des identifiants collectés, l'agent a pivoté vers un second serveur, exposé séparément sur Internet, exécutant MySQL et Nacos — une plateforme largement utilisée pour la découverte de services et la gestion de configuration.
Élévation de privilèges. Il a exploité CVE-2021-29441, une faille de contournement d'authentification dans Nacos, forgé un JSON Web Token à l'aide d'une clé de signature par défaut bien connue, puis injecté un compte administrateur backdoor.
Impact. L'agent a chiffré 1 342 éléments de configuration Nacos avec AES-256 et supprimé les schémas de base de données associés.
Extorsion. Il a laissé une demande de rançon contenant une adresse Bitcoin et une adresse de contact ProtonMail — la seule étape de la chaîne qui suppose qu'un humain finira par la lire.

La mise en garde honnête

Nous tenons à être précis sur ce que signifie « autonome » ici, car l'exagérer affaiblirait l'argument que nous nous apprêtons à développer.

Sysdig indique explicitement ne pas savoir comment l'agent a initialement obtenu les identifiants root MySQL utilisés à l'étape quatre. C'est une véritable lacune dans le récit d'une autonomie totale — quelque part dans cette chaîne, un humain ou un processus automatisé distinct a peut-être été impliqué d'une manière que les chercheurs n'ont pas pu reconstituer. Ce que Sysdig peut vérifier, c'est qu'à partir de la collecte d'identifiants, l'agent s'est adapté aux échecs et a retenté les étapes sans qu'un opérateur humain n'émette de nouvelles instructions pour chacune d'elles.

Cette distinction compte, et nous pensons qu'elle renforce l'argument plutôt qu'elle ne l'affaiblit. Même une chaîne partiellement autonome — où un humain fixe l'objectif et l'agent gère tout, de la reconnaissance jusqu'à l'impact — supprime déjà la plus grande source de latence dans une opération de ransomware traditionnelle : le temps qu'un opérateur humain passe à réfléchir, à consulter un référent, et à décider de la prochaine action à tenter.

Pourquoi 31 secondes comptent plus qu'il n'y paraît

Le point de données le plus concret du compte rendu de Sysdig n'est pas une durée totale d'attaque — nous n'avons connaissance d'aucun chiffre vérifié quant à la durée complète, de bout en bout, de la chaîne JadePuffer, et nous nous refusons délibérément à en inventer un. Le point de données qui, lui, est vérifié — et qui compte selon nous davantage qu'une durée totale ne le ferait — est le suivant : lorsqu'une étape échouait, l'agent passait d'une tentative de connexion ratée à une solution fonctionnelle en 31 secondes.

Comparez cela à la manière dont un opérateur humain se comporte lorsqu'une étape échoue. Il marque une pause. Il réévalue la situation. Dans une opération structurée de ransomware-as-a-service, il peut envoyer un message à un référent et attendre des instructions. Il retente sa chance sur un horizon de temps qui se compte en minutes ou en heures, parfois à cheval sur un changement d'équipe. Cette latence — l'écart entre un échec et la tentative suivante — a toujours été l'un des rares éléments jouant en faveur des défenseurs. C'est la raison pour laquelle une alerte survenue à 2 heures du matin peut encore être triée par un humain à 8 heures du matin sans que l'incident ne se soit nécessairement aggravé de façon spectaculaire dans l'intervalle.

Un agent qui réduit cet écart à 31 secondes ne se contente pas d'aller plus vite. Il supprime l'hypothèse intégrée à presque tous les runbooks de réponse à incident : à savoir qu'il existe une fenêtre à l'échelle humaine entre la première tentative infructueuse d'un attaquant et la suivante, et qu'un processus de détection et de réponse opérant sur une échelle de temps humaine comparable peut raisonnablement espérer intervenir à l'intérieur de cette fenêtre.

Les chiffres qui étaient déjà vrais avant l'arrivée de l'IA

L'infrastructure de sauvegarde n'est pas devenue une cible à cause de l'IA agentique. Elle l'était déjà, et les données à ce sujet précèdent JadePuffer de deux ans.

Le rapport Veeam 2024 Data Protection Trends Report a constaté que 96 % des attaques par ransomware ciblent spécifiquement les référentiels de sauvegarde, et que 76 % de ces tentatives réussissent.
L'étude Sophos 2024 sur les sauvegardes compromises, menée auprès de 2 974 victimes de ransomware, a constaté que les organisations dont les sauvegardes ont été compromises ont payé un coût médian de récupération de 3 millions de dollars, contre 375 000 dollars pour les organisations dont les sauvegardes sont restées intactes — soit un écart d'un facteur huit.

Ces chiffres décrivent un monde d'attaquants humains qui avaient déjà compris que détruire ou chiffrer la couche de sauvegarde est le levier le plus puissant disponible dès qu'une opération de ransomware prend pied. L'IA agentique ne change rien à ce calcul. Ce qu'elle change, c'est qui — ou quoi — est capable de l'exécuter à grande échelle, en continu, sans avoir besoin de dormir, de faire une pause entre deux équipes, ou d'attendre l'aval d'un référent avant de tenter l'identifiant suivant.

L'IBM 2026 X-Force Threat Index apporte un éclairage sur la tendance qui alimente ce constat : les attaques débutant par l'exploitation d'applications exposées sur Internet — exactement le vecteur d'entrée utilisé par JadePuffer — ont augmenté de 44 % d'une année sur l'autre, et le nombre de groupes actifs de ransomware et d'extorsion a augmenté de 49 % d'une année sur l'autre. La surface d'attaque était déjà en expansion avant même qu'un opérateur autonome ne soit nécessaire.

Des fenêtres de détection à la certitude de restauration

Nous avons déjà soutenu que la persistance de l'exploitation de vulnérabilités comme principale cause profonde des ransomwares, année après année, est un problème structurel qui ne peut être résolu par une simple accélération du patching — l'écart entre les vulnérabilités connues et les vulnérabilités corrigées est tout simplement trop large, et se renouvelle trop continuellement, pour qu'une prévention parfaite soit réaliste. JadePuffer ne change pas cet argument. Il le renforce.

Si l'hypothèse de travail du secteur a longtemps été qu'un processus de détection et de réponse au rythme humain peut raisonnablement espérer intercepter une intrusion quelque part entre l'accès initial et l'impact irréversible, un agent qui se corrige lui-même en 31 secondes remet directement cette hypothèse en cause. La réponse ne peut pas consister à « détecter et réagir plus vite qu'une machine », car ce n'est pas une course que les défenseurs peuvent espérer gagner indéfiniment. La réponse doit être architecturale : rendre le résultat d'une intrusion rapide et adaptative survivable, quelle que soit la vitesse à laquelle l'attaquant progresse.

Concrètement, cela signifie que les propriétés qui comptent pour l'infrastructure de sauvegarde et de restauration ne changent pas parce que l'attaquant est un agent IA plutôt qu'un humain — elles deviennent non négociables plutôt qu'aspirationnelles :

La séparation des identifiants et des identités, qui ne doit pas dépendre d'un humain remarquant une activité inhabituelle à temps. Si les identifiants qui donnent accès à votre environnement de sauvegarde sont les mêmes que ceux qu'un agent peut collecter en quelques secondes sur un hôte compromis, l'isolation doit être structurelle, et non procédurale.
L'immuabilité validée, et non simplement configurée. Un verrou de rétention qu'un identifiant suffisamment privilégié peut discrètement désactiver est un contrôle qui suppose qu'un attaquant humain hésitera. Un agent, lui, n'hésitera pas.
Des tests de restauration qui partent du principe que l'attaquant connaît déjà votre environnement. L'agent de JadePuffer s'est adapté aux échecs en temps réel. Un plan de restauration qui n'a jamais été testé que contre un unique scénario d'échec attendu est un plan conçu pour un adversaire plus lent et plus prévisible que celui dont l'existence est désormais démontrée.

Ce que cela signifie pour les responsables des risques en entreprise

JadePuffer est une campagne documentée, pas la preuve que toute opération de ransomware est désormais autonome. Mais elle établit quelque chose qui n'était auparavant que théorique : la capacité technique pour un agent LLM de mener une véritable chaîne d'attaque, de bout en bout, avec une boucle d'auto-correction se mesurant en secondes, existe désormais et a été utilisée contre une cible réelle.

Pour les responsables des risques, la question pratique n'est plus de savoir si le ransomware agentique va se généraliser — la trajectoire des capacités de l'IA a été suffisamment constante pour que parier contre elle soit la position la plus risquée. La question pratique est de savoir si les hypothèses de votre architecture de restauration ont été conçues pour un adversaire au rythme humain, ou pour un adversaire qui n'a plus besoin de l'être.

Où BackupSec intervient

Chez BackupSec, nous avons bâti notre approche autour d'un postulat que JadePuffer rend plus urgent, sans le rendre moins applicable : la prévention finira par échouer, et la couche qui détermine le résultat final est celle conçue pour survivre à cet échec — quelle que soit la vitesse à laquelle allait ce qui l'a provoqué.

ZeroMON vous donne une observabilité continue et en temps réel sur l'ensemble de votre parc de sauvegarde — pistes d'audit forensiques, détection de dérive de configuration et alertes d'anomalies sur les métadonnées des tâches de sauvegarde — afin qu'une tentative de collecte d'identifiants de 31 secondes contre votre couche de restauration soit visible au moment où elle se produit, et non découverte lors d'une revue post-incident.
ZeroTAM met à la disposition de votre équipe un conseiller dédié en sécurité des sauvegardes, chargé de mettre à l'épreuve votre séparation des identités, votre immuabilité et votre posture d'isolation, pour déterminer si elles ont été conçues pour un attaquant au rythme humain ou si elles tiendraient face à un attaquant qui s'adapte en temps réel.
ZeroPEN teste votre infrastructure de sauvegarde de la même manière qu'un agent autonome l'exploiterait — en sondant les plans de gestion, les contrôles d'accès et les paramètres d'immuabilité à la recherche du même type de chaîne d'identifiants que celle exploitée par JadePuffer — puis exécute de véritables scénarios de restauration pour prouver que la récupération fonctionne, quel que soit le chemin emprunté par l'intrusion.

BackupSec se déploie on-premise, se connecte à vos applications de sauvegarde via un accès API en lecture seule, et ne déplace jamais vos données de sauvegarde hors de votre environnement. La question que soulève JadePuffer n'est pas de savoir si vos défenses sont rapides. C'est de savoir si votre architecture de restauration a jamais été conçue pour avoir besoin qu'elles le soient.

Parlez à BackupSec de la validation de votre architecture de restauration →

Cette analyse s'appuie sur les recherches de Sysdig de juillet 2026 sur la campagne JadePuffer, sur l'IBM 2026 X-Force Threat Index, sur le rapport Veeam 2024 Data Protection Trends Report, et sur les recherches de Sophos 2024 sur les sauvegardes compromises. L'interprétation et le cadre d'analyse présentés ici sont propres à BackupSec. Pour discuter de la manière dont cette analyse s'applique à votre environnement spécifique, contactez notre équipe →