Faille Grav CMS CVE-2026-42608 : analyse du piratage du site de fuite de Clop par ShinyHunters

Pirater des pirates : c’est le scénario surprenant qui s’est déroulé en septembre 2026. Le site de fuite de données du célèbre groupe ransomware Clop a été compromis et défiguré par le gang rival ShinyHunters. L’attaque a été rendue possible par une vulnérabilité path traversal Grav CMS non corrigée, identifiée sous le code CVE-2026-42608. Installé sur un serveur tournant sous Grav 1.7.43, le site de Clop a violé les principes les plus élémentaires de la cybersécurité, permettant à leurs ennemis de s’emparer de leurs données. Cet incident est un cas d’école pour les administrateurs de sites web. Selon une étude de Wordfence, plus de 50 % des vulnérabilités critiques des CMS sont liées à un manque de validation des entrées. Il démontre que les failles des CMS, même les plus anciennes, restent des vecteurs d’attaque extrêmement efficaces. Découvrez les détails techniques de cette intrusion, les conséquences pour le monde du cybercrime, et surtout les mesures indispensables pour protéger vos propres installations Grav contre ce type de menace.

Le contexte de l’attaque : une guerre des gangs sans merci

Qui sont Clop et ShinyHunters ?

Le groupe Clop est l’un des gangs de ransomware les plus actifs depuis 2019, connu pour ses attaques de grande envergure exploitant des failles zero-day (comme l’exploitation d’Accellion FTA ou de GoAnywhere MFT). Leur site de fuite sur le réseau Tor est leur principal outil de pression pour publier les données des victimes qui refusent de payer.

ShinyHunters, quant à eux, sont un groupe d’extorsion et de vente de données volées, devenu célèbre en 2021 pour avoir revendiqué la vente de bases de données de sociétés comme Microsoft (partiellement) et AT&T. Ils opèrent également sur le Tor et se spécialisent dans le hacking de sites pour dérober des informations et les monnayer.

L’affrontement entre ces deux entités marque une escalade dans la guerre des gangs, où les acteurs malveillants retournent leurs armes les uns contre les autres.

Chronologie détaillée de l’intrusion

Selon les informations recueillies par BleepingComputer, l’attaque s’est déroulée en plusieurs phases. Dans un premier temps, ShinyHunters a exploité la faille Grav CMS pour uploader un fichier texte sur le serveur de Clop, prouvant leur capacité à pénétrer la forteresse. Peu de temps après, ils ont défiguré le site en affichant le logo Umbreon et un lien vers leur propre site de fuite.

« Le serveur Clop a été entièrement compromis », ont déclaré les attaquants. ShinyHunters affirme avoir exfiltré plusieurs gigaoctets de données, incluant le code source du site, les plugins Grav, les logs serveur, et surtout les clés privées du service onion Tor. La divulgation de ces clés est une humiliation majeure pour Clop, car elle compromet la sécurité de leurs futures communications.

Les réactions et la migration de Clop

Clop a rapidement réagi en migrant son site de fuite vers une nouvelle adresse Tor. Le groupe a nié toute collaboration ou négociation avec ShinyHunters.

« Nous ne les connaissons pas, nous n’avons jamais travaillé avec eux et nous ne sommes actuellement pas en contact avec eux. Nous ne leur avons fourni aucune information, maintenant ni dans le futur. » - Clop à BleepingComputer

Cependant, Clop a minimisé l’impact de la fuite, affirmant que le serveur ne contenait « rien d’autre que du contenu » et aucune donnée financière. « Nous n’avons pas mis à jour le plugin Grav - mais le serveur ne contenait que du contenu (il n’y avait absolument aucune donnée ou activité financière, et il ne pouvait pas y en avoir) ». Une déclaration qui semble contredire les affirmations de ShinyHunters, mais qui souligne surtout un manque flagrant de rigueur dans la gestion des correctifs de sécurité.

Analyse technique de la CVE-2026-42608 : une faille path traversal Grav CMS

Qu’est-ce qu’une vulnérabilité de type Path Traversal ?

Une vulnérabilité de type path traversal (ou traversée de répertoires) est un défaut de sécurité qui permet à un attaquant de manipuler les chemins de fichiers sur le serveur. En utilisant des séquences comme ../, l’attaquant peut sortir du répertoire racine de l’application et accéder à des zones sensibles du système de fichiers. Dans notre cas, cela permettait à ShinyHunters d’écrire un fichier arbitraire (un webshell) en dehors des répertoires temporaires dédiés aux formulaires.

Le vecteur d’attaque spécifique : le paramètre __unique_form_id__

La vulnérabilité spécifique exploitée par ShinyHunters réside dans la gestion de l’upload de fichiers dans Grav CMS. Lorsqu’un formulaire contenant un champ de téléchargement est soumis, Grav crée un répertoire temporaire pour stocker le fichier. Le problème est que le nom de ce répertoire est en partie construit à partir d’une valeur fournie par l’utilisateur : le paramètre **__unique_form_id__**.

Le chemin vulnérable était construit de cette manière :

$path = 'tmp/forms/' . $session_id . '/' . $_POST['__unique_form_id__'];

Aucune validation ou assainissement du paramètre n’était effectué avant son utilisation dans le chemin. ShinyHunters a découvert que, en fournissant une valeur comme ../../../shhq, le chemin résultant devenait tmp/forms/<session_id>/../../../shhq, ce qui se résout en shhq à la racine du site. L’attaquant pouvait ensuite uploader un fichier PHP malveillant dans ce répertoire, obtenant ainsi une exécution de code à distance (RCE).

La confirmation par Grav et le correctif officiel

Grav a rapidement confirmé la légitimité de cette faille lorsque BleepingComputer leur a partagé les détails techniques.

« Yes, it’s a legitimate flaw, and the threat actor’s description is accurate. » - Grav CMS

La faille, identifiée comme CVE-2026-42608, avait en réalité été corrigée dans la branche 2.0 de Grav (version 2.0.0-beta.2) dès le mois d’avril 2026. Le correctif introduit une fonction **sanitizeId()** qui restreint les identifiants acceptés à une liste blanche très stricte :

[A-Za-z0-9,_-]{1,64}

Le problème principal est que ce correctif n’avait pas été rétroporté vers la branche 1.7, pourtant encore largement utilisée. Grav explique : « Le correctif manquait dans la ligne 1.7. Grav 2.0 est la version majeure actuelle, mais beaucoup de sites sont encore en 1.7, et le correctif n’y avait pas été rétroporté. »

Après cette divulgation publique, Grav a rapidement publié la version 1.7.53.4 pour corriger la faille sur l’ancienne branche.

Leçons techniques à retenir

Dans la pratique, nous avons observé que l’erreur ici est double. Premièrement, l’utilisation d’une donnée non fiable dans un chemin système sans validation. Deuxièmement, le défaut de rétroportage d’un correctif de sécurité critique. La fonction sanitizeId() est une excellente réponse de sécurité défensive : au lieu de filtrer les caractères dangereux (blacklist), elle n’accepte que les caractères sûrs (whitelist). L’ANSSI, dans ses guides de développement sécurisé, recommande systématiquement cette approche par liste blanche.

Impact et leçons pour la cybersécurité des CMS

Les conséquences immédiates pour Clop

Au-delà de l’humiliation, la compromission du site de fuite de Clop a des conséquences pratiques désastreuses :

• Perte de contrôle de l’infrastructure Tor : les clés privées volées peuvent permettre de rediriger ou d’écouter le trafic. Cela expose leurs opérations et celles de leurs partenaires.
• Exposition des opérations : les logs serveurs volés peuvent révéler des informations sur leurs autres cibles, leurs méthodes de travail ou des accès à d’autres infrastructures.
• Perte de crédibilité : un gang de ransomware qui ne peut pas sécuriser son propre site de fuite inspire moins de crainte auprès de ses victimes et devient une cible facile pour ses concurrents.

Les implications pour les entreprises françaises utilisant Grav CMS

Grav CMS est utilisé par des milliers d’agences web et d’entreprises en France pour des sites vitrines, des intranets ou des portails documentaires. Le défaut de rétroportage du correctif signifie que toute société utilisant Grav 1.7.x depuis avril 2026 sans mise à jour était potentiellement vulnérable. Cela représente des centaines de sites exposés en France.

Nous avons observé que de nombreuses PME confient la maintenance de leur CMS à des prestataires qui ne surveillent pas activement les CVE. Ce cas montre l’importance d’inclure la veille de sécurité dans tout contrat de maintenance web.

Par exemple, une agence web parisienne spécialisée dans les sites vitrines sous Grav aurait pu voir l’ensemble de ses projets clients compromis par cette faille. Si un prestataire ne met pas à jour son CMS, c’est toute sa chaîne de confiance qui est rompue. Selon les retours d’expérience de la communauté Grav francophone, plusieurs incidents de défacement ont été rapportés suite à la divulgation de la CVE.

Le saviez-vous ? Le CERT-FR a émis une alerte concernant la CVE-2026-42608, recommandant une mise à jour immédiate des instances Grav en version 1.7. Si vous êtes en France, cette alerte a probablement été relayée par votre hébergeur.

Une comparaison entre les branches Grav

Les entreprises doivent impérativement planifier une migration vers Grav 2.x pour bénéficier des correctifs de sécurité à long terme.

Guide pratique : comment se protéger de la CVE-2026-42608 et des attaques similaires

Étape 1 : Mettre à jour Grav CMS sans attendre

La toute première action à réaliser est de vérifier la version de votre instance Grav et de la mettre à jour.

Procédure de mise à jour vers Grav 1.7.53.4 ou supérieur :

1. Connectez-vous à votre serveur via SSH.
2. Sauvegardez l’intégralité des fichiers et de la base de données.
3. Placez votre site en mode maintenance.
4. Exécutez la commande suivante dans le répertoire racine de Grav :

   bin/gpm selfupgrade
   

5. Vérifiez la version installée. Vous devez être en 1.7.53.4 ou supérieur (ou sur une version 2.x stable).
6. Videz le cache de Grav :

   bin/grav clear-cache
   

7. Testez le site en backend et en frontend avant de désactiver le mode maintenance.

Si vous hésitez entre rester en 1.7 ou migrer en 2.0, sachez que la version 1.7 est en fin de vie. La migration vers Grav 2.0 est l’investissement de sécurité le plus sûr pour l’avenir.

Étape 2 : Analyse des logs pour détecter une compromission

Si vous gérez un site sous Grav et que vous n’avez pas encore effectué la mise à jour, il est impératif de vérifier si votre serveur n’a pas déjà été compromis. Les tentatives d’exploitation de la CVE-2026-42608 laissent des traces dans les logs d’accès.

Recherchez les motifs suivants dans vos logs Apache ou Nginx :

• Requêtes POST contenant le paramètre __unique_form_id__.
• Valeurs suspectes de ce paramètre incluant ../ ou des chemins absolus.
• Téléchargements de fichiers avec des extensions PHP, PHTML, PHP5 dans des répertoires inhabituels.

Une entreprise qui aurait été compromise pourrait trouver des webshells dans le dossier webroot/ ou tmp/. Un simple grep dans les logs Apache peut révéler l’attaque :

grep -E '__unique_form_id__.*\.\./' /var/log/apache2/access.log

Si vous trouvez des traces d’exploitation, l’analyse médico-légale doit être immédiate. Voici les actions à mener :

1. Isoler le serveur du réseau.
2. Changer tous les mots de passe (base de données, FTP, administration).
3. Révoquer tous les tokens API et clés SSH.
4. Restaurer la dernière sauvegarde propre.
5. Effectuer une analyse de sécurité complète avant remise en production.

Étape 3 : Durcir la configuration de votre serveur Grav

Au-delà du simple correctif, un durcissement global de votre infrastructure est recommandé pour vous protéger contre les futures vulnérabilités.

Selon les recommandations de l’ANSSI, la mise à jour des composants logiciels est l’une des mesures les plus efficaces contre les attaques de type ransomware. Un serveur à jour est un serveur protégé.

Conclusion : ne sous-estimez jamais les failles « simples »

L’affaire du piratage du site de Clop par ShinyHunters est bien plus qu’une simple anecdote croustillante sur la guerre des gangs. C’est une démonstration brutale qu’aucune infrastructure, aussi obscure soit-elle, n’est à l’abri d’une erreur humaine de gestion des correctifs. La vulnérabilité path traversal Grav CMS (CVE-2026-42608) est désormais publique. Les chercheurs en sécurité, les concurrents de Clop, mais aussi les défenseurs, analysent ses moindres implications.

Si vous administrez un site sous Grav CMS, le message est clair et urgent : mettez à jour votre installation sans délai vers la version 1.7.53.4 ou 2.x. Ne commettez pas la même erreur que le gang Clop. Dans la cybersécurité moderne, la réactivité face aux correctifs de sécurité n’est pas une option, c’est la seule ligne de défense fiable entre votre serveur et la prochaine compromission.

Vérifiez votre version de Grav dès maintenant. Mettez à jour. Protégez vos données.