ShinyHunters pirate le site de fuite de Clop via une traversée de chemin dans Grav CMS
Le 25 septembre 2026, BleepingComputer a confirmé que le gang ShinyHunters a compromis le site de fuite du ransomware Clop en exploitant CVE-2026-42608, une traversée de chemin non authentifiée de Grav corrigée en avril mais jamais rétroportée sur la branche 1.7. Si vous tournez encore sous Grav 1.7, passez en 1.7.53.4 sans attendre.
Avril 2026. Grav corrige en privé une traversée de chemin non authentifiée dans Grav 2.0, sous la référence CVE-2026-42608. Début septembre 2026. Le gang ShinyHunters exploite cette même faille pour défigurer le site de fuite du ransomware Clop. 24 septembre 2026. Grav rétroporte enfin le correctif sur la branche 1.7 avec la version 1.7.53.4. Pourquoi c’est important : même les opérateurs de ransomware tournent avec un CMS obsolète — et l’écart entre le correctif et son rétroportage a laissé cinq mois de fenêtre ouverte.
Un gang de ransomware défigure un autre gang de ransomware
L’affaire a l’allure d’un règlement de comptes entre groupes criminels. Le site de fuite de Clop, hébergé sur Tor, a été compromis plus tôt en septembre par ShinyHunters, un gang d’extorsion connu. ShinyHunters a d’abord déposé un petit fichier texte, puis a remplacé le site par un défacement pleine page arborant son logo Pokémon Umbreon et un lien vers son propre site de fuite.
Le gang revendique le vol du code source, des plugins Grav, des journaux serveur et des clés privées du service onion de Clop, et a assorti sa prise d’une demande de rançon, menaçant de publier les fichiers si Clop ne payait pas. Clop a depuis annoncé une nouvelle adresse onion, tout en niant tout contact avec ShinyHunters : « Nous ne les connaissons pas, nous n’avons jamais travaillé avec eux, et nous ne sommes pas en contact avec eux. » Sur le fond, le gang russe conteste la valeur du butin : « le serveur ne contenait que du contenu », affirme-t-il, sans activité financière ni données exploitables.
La faille : un identifiant de formulaire qu’on laisse sortir du dossier
Le vecteur est une traversée de chemin d’une banalité redoutable, située dans le cœur de Grav et non dans le plugin Form, comme Grav l’a précisé. Au moment du dépôt d’un fichier, le CMS construit un répertoire temporaire à partir de valeurs fournies par des paramètres POST, sans les valider comme composants de chemin sûrs.
Le paramètre incriminé est unique_form_id. Sa valeur est insérée dans un chemin du type tmp/forms/<session_id>/<unique_id>. ShinyHunters a démontré qu’en fournissant des séquences de traversée — ../../../shhq — pour cet identifiant, on force Grav à créer le répertoire de dépôt hors de tmp/forms, puis à écrire le fichier téléversé ailleurs sous l’installation du CMS. BleepingComputer a transmis les détails techniques à Grav, qui a confirmé mot pour mot la description : « Oui, c’est une faille légitime, et la description de l’acteur de la menace est exacte. »
La correction tient en une fonction : sanitizeId(), qui n’accepte désormais que des identifiants correspondant à la liste blanche [A-Za-z0-9,_-]{1,64}. Tout caractère hors de cet ensemble — dont les points et les barres obliques qui composent une traversée — est rejeté avant d’entrer dans le chemin.
Un correctif d’avril, rétroporté en septembre
La chronologie est la leçon de l’affaire. Grav a corrigé la faille plus tôt dans l’année dans Grav 2.0 (version 2.0.0-beta.2), avec un avis publié le 27 avril. Mais le correctif n’avait pas été rétroporté sur la branche 1.7, pourtant encore largement déployée. Le site de Clop tournait sous Grav 1.7.43 — une version vulnérable, donc, alors même que la branche 2.x était protégée depuis des mois.
« L’écart, c’était la ligne 1.7 », a reconnu Grav auprès de BleepingComputer. « Grav 2.0 est la version majeure actuelle, mais beaucoup de sites sont encore en 1.7, et ce correctif n’y avait pas encore été rétroporté. » Ce n’est qu’après la transmission des détails d’exploitation par BleepingComputer que Grav a rétroporté le correctif et publié Grav 1.7.53.4 le 24 septembre. La fenêtre d’exposition, entre l’avis d’avril et le rétroportage, approche donc les cinq mois.
Le chiffre qui compte n’est pas la sévérité de la faille — une traversée de chemin non authentifiée, exploitable sans compte — mais la vitesse du rétroportage. La majorité des sites Grav en production ne sont pas sur la dernière version majeure ; pour eux, le correctif d’avril n’existait tout simplement pas.
L’ironie n’a échappé à personne. Clop, qui a bâti sa réputation sur l’exploitation de la faille MOVEit en 2023 et l’extorsion de milliers d’organisations, se retrouve victime de la méthode qu’il applique aux autres. Le gang a d’ailleurs retiré ShinyHunters de son propre site de fuite — un geste qui, selon BleepingComputer, survient généralement quand des négociations sont en cours, même si ShinyHunters a refusé de commenter. La leçon opérationnelle est brutale : personne, pas même les opérateurs de ransomware, n’est à l’abri d’un correctif non rétroporté.
Ce que l’affaire dit de la dette de mise à jour
Le paradoxe est instructif : Clop, qui vit d’extorquer des organisations mal patchées, s’est fait compromettre par la même négligence qu’il exploite chez les autres — une installation Grav pas entièrement à jour. Clop l’a d’ailleurs admis sans détour : « Nous n’avions pas mis à jour le plugin Grav — cela a fini par arriver, mais le serveur ne contenait que du contenu. »
La leçon dépasse le cas criminel. La branche 1.7 de Grav est typique des logiciels dont la maintenance s’arrête de fait à la sortie de la version majeure suivante, alors qu’une large base continue de l’utiliser. Quand un correctif de sécurité n’est pas rétroporté, la publication de l’avis devient une feuille de route pour les attaquants : elle décrit la faille et désigne la population vulnérable, sans lui offrir de remède. C’est exactement ce qui s’est produit ici.
La mécanique de la traversée, pas à pas
Pour comprendre pourquoi la faille est si simple à exploiter, il faut suivre le chemin du fichier. Quand un formulaire Grav reçoit un dépôt, le CMS construit un répertoire temporaire du type tmp/forms/<session_id>/<unique_id>. La valeur unique_id provient du paramètre unique_form_id, envoyé par le client. Tant que cette valeur est un identifiant propre, le fichier atterrit dans tmp/forms, là où il doit rester.
Le bug : Grav 1.7 ne vérifiait pas que cette valeur était un composant de chemin sûr. En envoyant ../../../shhq comme identifiant, l’attaquant remonte de trois niveaux dans l’arborescence et force la création du répertoire hors de tmp/forms. Le fichier téléversé est ensuite écrit à cet endroit arbitraire, sous la racine de l’installation. À partir de là, écrire un webshell ou écraser un fichier de configuration devient une affaire de quelques requêtes.
La correction de Grav est exemplaire par sa simplicité : la fonction sanitizeId() n’accepte plus que les identifiants de la forme [A-Za-z0-9,_-]{1,64}. Ni point, ni barre oblique, ni séquence de remontée. C’est exactement le genre de correctif qu’on aimerait voir rétroporté immédiatement — et c’est précisément ce qui a manqué pendant cinq mois.
Verdict
Si vous exploitez un site sous Grav 1.7, mettez à niveau vers 1.7.53.4 immédiatement : la faille est non authentifiée, documentée publiquement depuis avril, et déjà exploitée en conditions réelles. Si vous êtes sous Grav 2.x, vous êtes protégé depuis des mois — mais vérifiez tout de même votre version, car le correctif n’a atteint la branche 2.0 qu’en version 2.0.0-beta.2. Si vous maintenez un logiciel avec plusieurs branches, retenez la leçon structurelle : un correctif publié sans rétroportage vers les branches encore déployées est un correctif à moitié livré, et l’avis qui l’accompagne devient un manuel d’attaque.