Faille de chemin d'accès Grav CMS : comment ShinyHunters a compromis le site de fuites de Clop

En septembre 2026, un événement inattendu a secoué l’écosystème des ransomwares : le site de fuites du groupe Clop a été défiguré par le gang d’extortion ShinyHunters. Cette intrusion a été rendue possible par une faille de chemin d’accès Grav CMS non corrigée, identifiée sous la référence CVE-2026-42608. Cet incident démontre qu’aucune organisation, pas même les cybercriminels, n’est à l’abri d’une exploitation logicielle. Dans cet article, nous analysons les détails de cette compromission, les mécanismes techniques de la vulnérabilité, et les mesures à prendre pour protéger vos installations Grav.

Contexte de l’attaque : Clop et ShinyHunters

Le ransomware Clop et son site de fuites

Clop est l’un des groupes de ransomware les plus actifs, connu pour ses campagnes ciblant les grandes entreprises via des vulnérabilités de transfert de fichiers et des accès distants. Comme de nombreux gangs, Clop utilise un site sur le réseau Tor pour publier les données des victimes qui refusent de payer. Ce site de fuites est hébergé sur un serveur utilisant Grav CMS, un système de gestion de contenu open source basé sur des fichiers plats.

ShinyHunters : un groupe d’extortion

ShinyHunters est un groupe d’extortion qui se fait connaître en revendiquant des accès non autorisés à des bases de données et en exigeant des rançons. Début septembre 2026, ses membres ont annoncé avoir pénétré le serveur de Clop, défiguré la page d’accueil avec leur logo Umbreon Pokémon et extrait des informations sensibles. Selon leur propre site de fuites, ils auraient dérobé du code source, des plugins Grav, des journaux serveur et les clés privées du service Tor de Clop.

La compromission du site de fuites

L’attaque s’est déroulée en deux temps : d’abord un petit fichier texte a été déposé, puis le site a été entièrement remplacé par une page de défacement. Clop a confirmé l’incident et a rapidement migré son site vers une nouvelle adresse Tor, tout en maintenant temporairement l’ancienne. Le groupe russe a nié toute négociation avec ShinyHunters, déclarant à BleepingComputer : « Nous ne les connaissons pas, nous n’avons jamais travaillé avec eux et nous ne sommes pas en contact avec eux ». Il a également minimisé l’impact, affirmant que le serveur ne contenait que du contenu, sans données financières. Cependant, quelques jours plus tard, Clop a été retiré du site de fuites de ShinyHunters, ce qui suggère qu’un arrangement a peut-être eu lieu.

Détails techniques de la faille exploitée

La vulnérabilité CVE-2026-42608 : un défaut de validation de chemin

La racine de la compromission est une faille de parcours de répertoire (path traversal) dans le cœur de Grav CMS, identifiée sous le code CVE-2026-42608. Ce type de vulnérabilité permet à un attaquant d’écrire des fichiers en dehors des répertoires prévus en manipulant les chemins d’accès. Dans ce cas, le problème résidait dans la gestion des téléchargements de formulaires.

Le vecteur d’attaque : paramètre unique_form_id

ShinyHunters a expliqué à BleepingComputer que la faille se trouvait dans le mécanisme de création des répertoires temporaires pour les uploads. Lors de l’envoi d’un formulaire, Grav construit un chemin temporaire comme suit :

tmp/forms/<session_id>/<unique_id>

En fournissant des séquences de traversée de répertoire (par exemple ../../../shhq) dans le paramètre __unique_form_id__, l’attaquant pouvait forcer le CMS à créer un répertoire en dehors de tmp/forms. Un fichier malveillant pouvait alors être écrit à un emplacement arbitraire, comme dans le répertoire web accessible, permettant l’exécution de code.

La correction apportée par Grav

Le développeur de Grav, après avoir reçu les détails techniques, a confirmé l’exactitude de la description. La vulnérabilité avait été signalée et corrigée dans Grav 2.0 (version 2.0.0-beta.2) dès avril 2026, via une fonction sanitizeId() qui n’accepte que les identifiants correspondant à l’expression régulière [A-Za-z0-9,_-]{1,64}. Cependant, la correction n’avait pas été rétroportée vers la branche 1.7, laissant des installations comme celle de Clop (version 1.7.43) exposées. Après la divulgation, Grav a publié la version 1.7.53.4 qui intègre le correctif. Grav a précisé : « Le bogue se trouve dans le cœur de Grav, pas dans le plugin Form. C’est la version du cœur qui compte. »

Conséquences de l’incident pour l’écosystème cyber

Réactions des groupes impliqués

Cet incident a mis en lumière les tensions entre groupes criminels. ShinyHunters a tenté d’extorquer Clop en menaçant de divulguer les fichiers volés. De son côté, Clop a minimisé l’importance des données, affirmant que le serveur ne contenait que du contenu. Pourtant, la compromission d’un site de fuites est un coup dur pour la réputation d’un gang ransomware, d’autant plus que les clés privées Tor auraient pu compromettre l’anonymat de leurs opérations.

Leçons pour les administrateurs de CMS

Cet événement rappelle que la gestion des mises à jour de sécurité est cruciale, même pour les infrastructures critiques. Selon Grav, « de nombreux sites sont encore sur la branche 1.7 ». Voici les enseignements clés :

• Maintenir à jour son CMS : les correctifs de sécurité doivent être appliqués rapidement. Une faille connue depuis plusieurs mois dans Grav 2.0 n’avait pas été rétroportée, mais les versions 2.x étaient protégées.
• Segmenter les serveurs : un site exposé (comme un site de fuites) ne devrait pas héberger d’informations critiques.
• Surveiller les journaux : les activités anormales de téléchargement peuvent indiquer une tentative d’exploitation.
• Effectuer des revues de code tierces : la faille a été découverte par des chercheurs, mais elle aurait pu l’être plus tôt par un audit interne.

Comment se protéger contre les failles de type path traversal

Mise à jour et gestion des versions

La première ligne de défense consiste à appliquer les mises à jour. Pour Grav, migrer vers la branche 2.0 est fortement recommandé. Si vous devez rester en 1.7, installez immédiatement la version 1.7.53.4. Pour tout CMS, abonnez-vous aux alertes de sécurité et testez les correctifs dans un environnement de staging avant le déploiement.

Bonnes pratiques de configuration

• Restreindre les permissions d’écriture : le répertoire temporaire (tmp/forms) ne doit pas être accessible via le web.
• Valider les entrées utilisateur : toute donnée provenant de formulaires doit être filtrée pour éviter les injections de chemin. Utilisez des listes blanches de caractères.
• Désactiver les téléchargements non nécessaires : si votre site n’a pas besoin d’uploads, supprimez la fonctionnalité ou protégez-la par authentification.

Surveillance et détection

Mettez en place une solution de détection d’intrusion (IDS) qui surveille les accès anormaux aux fichiers. Les tentatives de path traversal laissent souvent des traces comme ../ dans les logs. Voici un exemple de règle de détection simple à intégrer dans votre SIEM :

# Détection des séquences de traversée dans les paramètres GET/POST
alert tcp any any -> $HTTP_SERVERS 80 (msg:"Path traversal attempt"; content:"../"; nocase; sid:100001;)

Toutefois, cette règle n’est qu’un exemple basique. Une approche plus robuste consiste à analyser le comportement des requêtes avec un moteur de corrélation.

Conclusion : prioriser la sécurité de son CMS

L’attaque de ShinyHunters contre Clop illustre parfaitement comment une faille de chemin d’accès Grav CMS non corrigée peut compromettre même des acteurs aguerris. Aucun système n’est infaillible, mais des gestes simples - mettre à jour son CMS, valider les entrées, segmenter ses serveurs - réduisent considérablement la surface d’attaque. Chez les développeurs, la responsabilité de rétroporter les correctifs est tout aussi cruciale. En tant qu’administrateur, vérifiez dès aujourd’hui la version de votre Grav CMS et appliquez les mises à jour nécessaires. La cybersécurité est une vigilance de chaque instant.