Faille Grav CMS CVE-2026-42608 : l'attaque path traversal qui a compromis le site du ransomware Clop

L’un des rançongiciels les plus redoutés du paysage cybercriminel a vu son infrastructure compromise par une vulnérabilité de sécurité basique. En septembre 2026, le site de fuite de données du groupe Clop a été défiguré par le gang ShinyHunters. Comment une telle intrusion a-t-elle été possible ? Par l’exploitation d’une vulnérabilité de type path traversal non authentifiée dans le CMS Grav, identifiée sous le code CVE-2026-42608. La faille a permis le vol de clés privées Tor et de code source, portant un coup sévère à l’opération malveillante. Cet incident met en lumière une vérité inconfortable : les conséquences d’un défaut de mise à jour peuvent frapper n’importe quelle organisation exposée sur Internet, même celles réputées pour leur expertise technique.

Le piratage du site de Clop : une faille Grav CMS au cœur de l’attaque

L’histoire débute lorsque le site de fuite Tor de Clop, pierre angulaire de leur stratégie d’extorsion, est défiguré par un groupe rival. ShinyHunters, connu pour ses propres activités de chantage, arbore son logo Pokémon Umbreon à la place de la page d’accueil du groupe. L’intrusion est rapidement revendiquée sur leur propre plateforme. ShinyHunters affirme avoir dérobé un butin conséquent :

• Le code source des plugins Grav utilisés ;
• Les logs serveur détaillant l’activité de la plateforme ;
• Les clés privées du service Tor de Clop (leak site).

Face à cette compromission, la réaction de Clop ne se fait pas attendre. Le groupe annonce le déplacement de son site de fuite vers une nouvelle adresse onion. L’ancien domaine est maintenu temporairement avant d’être définitivement abandonné. Dans une déclaration à BleepingComputer, Clop nie catégoriquement toute forme de collaboration ou de négociation avec ShinyHunters. Le groupe russe tente de minimiser l’incident en affirmant que le serveur compromis ne contenait « aucune donnée financière ou opérationnelle ».

« We do not know them, we have never worked with them, and at the moment we are not in contact with them. »

• Clop, à BleepingComputer

Toutefois, le maillon faible est rapidement identifié : le serveur fonctionnait sous Grav CMS 1.7.43, une version de l’ancienne branche stable. Le correctif de la faille, bien que déjà intégré dans Grav 2.0 depuis avril 2026, n’avait jamais été backporté vers la branche 1.7. Cette négligence dans la gestion du cycle de vie des correctifs a offert une porte d’entrée directe aux assaillants.

Détails techniques de la vulnérabilité path traversal Grav CMS (CVE-2026-42608)

Le vecteur d’attaque via le paramètre unique_form_id

L’analyse technique révèle une vulnérabilité classique mais redoutablement efficace : un path traversal non authentifié dans le mécanisme de gestion des uploads de formulaires de Grav. Selon les détails partagés par ShinyHunters et confirmés par l’éditeur, le problème réside dans la construction des chemins temporaires pour les fichiers téléchargés.

En pratique, Grav utilise un paramètre POST nommé __unique_form_id__ pour créer un répertoire temporaire dédié à la session. Le chemin généré suit un modèle spécifique :

tmp/forms/<session_id>/<unique_id>

ShinyHunters a découvert qu’en manipulant la valeur du paramètre __unique_form_id__ et en y injectant des séquences de traversée de répertoire, il était possible de forcer la création d’un répertoire en dehors du dossier tmp/forms prévu. Par exemple, la valeur ../../../shhq permettait d’écrire un fichier uploadé à la racine de l’installation Grav, ou même ailleurs sur le système de fichiers.

Le correctif, implémenté dans Grav 2.0 puis backporté dans Grav 1.7.53.4, introduit une fonction de validation stricte, sanitizeId(). Celle-ci applique une expression régulière pour n’accepter que les identifiants conformes à un jeu de caractères sûr :

// Regex de validation de l'identifiant unique
[A-Za-z0-9,_-]{1,64}

Cette mesure simple empêche toute tentative d’injection de caractères spéciaux ou de séquences de traversée.

Versions concernées et déploiement du correctif

L’éditeur de Grav a confirmé à BleepingComputer que la vulnérabilité était authentique et que la description fournie par les attaquants était exacte. Il a également précisé un point crucial : la faille se situe dans le noyau (core) de Grav, et non dans le plugin Form. Par conséquent, la version du plugin Form (7.3.0 dans le cas de Clop) n’affecte pas la vulnérabilité ; seule la version du cœur du CMS compte.

Le tableau ci-dessous récapitule les versions concernées et l’état des correctifs :

L’éditeur a reconnu que le « gap » sécuritaire était la branche 1.7. Bien que Grav 2.0 soit la version majeure actuelle, de nombreux sites, y compris l’infrastructure sensible de Clop, fonctionnent encore avec l’ancienne branche. Cette situation est un cas d’école des retards de correction qui exposent les organisations à des risques majeurs.

Les leçons de l’incident : l’importance cruciale de la gestion des correctifs

L’ironie du sort pour le gang Clop

L’incident revêt une dimension particulièrement ironique. Un groupe spécialisé dans l’exploitation de failles de sécurité et l’extorsion de données a vu son propre outil de pression compromise par un défaut basique de gestion des correctifs. Clop a tenté de minimiser l’impact, mais les conséquences sont réelles : le vol de clés privées Tor compromet l’anonymat de leur infrastructure, la perte des logs expose leurs méthodes opérationnelles, et la confiance de leurs partenaires est entamée.

Par ailleurs, bien que Clop affirme que le serveur ne contenait que du contenu et aucune donnée financière, la compromission des clés Tor et du code source des plugins constitue un désastre opérationnel. Selon le principe de défense en profondeur, un site public peut servir de point d’entrée vers des systèmes plus sensibles. Dans le cas de Clop, cette intrusion démontre que les mêmes faiblesses qui affectent les entreprises légitimes frappent également les infrastructures criminelles.

Implications pour les organisations légitimes

Pour les DSI, RSSI et administrateurs web français, cette affaire est un signal d’alarme puissant. Elle démontre que la veille sécurité et l’application des correctifs ne peuvent souffrir aucun délai, en particulier sur les branches maintenues mais vieillissantes des logiciels.

Dans le cadre de la directive NIS 2, les entités essentielles et importantes doivent démontrer leur capacité à gérer les vulnérabilités. L’absence de correctif sur un serveur exposé, même s’il est dédié à une activité criminelle dans le cas de Clop, constitue une défaillance majeure des processus de sécurité. Pour les entreprises légitimes, une telle négligence pourrait entraîner des sanctions financières significatives, en plus de l’atteinte à la réputation.

« The gap was the 1.7 line. Grav 2.0 is the current major version, but plenty of sites are still on 1.7, and that fix hadn’t been backported there yet. »

• Grav CMS, à BleepingComputer

Cette citation de l’éditeur souligne la difficulté du backporting et le fossé sécuritaire qui peut exister entre une branche majeure et une branche Legacy. Les équipes doivent donc :

1. Identifier et inventorier toutes les instances de logiciels en fin de vie ou en mode maintenance.
2. Planifier une migration vers les versions supportées actuellement.
3. Mettre en place des mesures compensatoires (WAF, restriction d’accès) en attendant la migration.

Recommandations pour sécuriser vos installations Grav CMS

Face à cette menace, les mesures à prendre sont claires et urgentes pour toute organisation utilisant Grav CMS.

Mise à jour immédiate vers la version corrigée

La première ligne de défense est l’application du correctif. Si vous utilisez la branche 1.7 de Grav, la mise à jour vers Grav 1.7.53.4 est impérative. Pour les utilisateurs de la branche 2.0, assurez-vous de disposer de la version 2.0.0-beta.2 ou d’une version ultérieure.

Procédure de mise à jour conseillée :

1. Auditer votre parc de serveurs pour identifier les versions de Grav en production.
2. Sauvegarder l’intégralité de l’installation (fichiers et base de données).
3. Tester la mise à jour dans un environnement de pré-production.
4. Déployer le correctif sur les serveurs de production.
5. Vérifier le bon fonctionnement des formulaires et des pages.

Mesures de défense en profondeur

Au-delà du correctif, il est essentiel de renforcer la sécurité globale de l’infrastructure. Un plan de remédiation complet doit inclure les actions suivantes, conformément aux bonnes pratiques du guide de sécurisation des CMS de l’ANSSI :

1. Inventaire des actifs : Cartographier l’ensemble des instances Grav CMS déployées sur le périmètre.
2. Veille CVE automatisée : S’abonner aux flux de sécurité de Grav CMS et des dépendances critiques.
3. Gestion des correctifs : Définir un délai de correction contractuel pour les vulnérabilités critiques (ex: 48h à 72h).
4. Validation : Scanner les applications après correction pour confirmer l’élimination de la faille.
5. Segmentation : Isoler le serveur web des bases de données et du réseau interne.
6. Défense périmétrique : Déployer un WAF avec des règles spécifiques contre les path traversals.
7. Formation : Sensibiliser les développeurs et administrateurs aux risques des injections de chemin.

Cas concret : une organisation française vulnérable Prenons l’exemple d’une collectivité locale utilisant Grav 1.7.43 pour son portail de démarches administratives. Ce site permet le dépôt de pièces justificatives par les administrés. Sans le correctif CVE-2026-42608, un attaquant pourrait exploiter la faille d’upload pour déposer un webshell, prendre le contrôle du serveur, et exfiltrer les données personnelles stockées sur la base de données adjacente. Ce scénario illustre parfaitement comment une vulnérabilité critique peut mettre en danger les données de citoyens et l’intégrité des services publics.

Conclusion : l’importance d’une veille sécurité active

L’histoire du piratage du site de Clop par ShinyHunters via une faille Grav CMS est riche d’enseignements. Elle nous rappelle que la cybersécurité est une discipline sans répit, où la négligence d’un seul correctif peut avoir des conséquences retentissantes. La vulnérabilité CVE-2026-42608, exploitée dans un contexte de guerre entre groupes cybercriminels, aurait tout aussi bien pu viser une entreprise légitime, avec des conséquences potentiellement bien plus lourdes sur le plan réglementaire (RGPD, NIS 2) et économique.

La leçon est double. Premièrement, la gestion des correctifs doit être une priorité absolue, en particulier sur les branches maintenues mais parfois délaissées des applications. Le défaut de backporting de Grav a exposé des milliers de sites pendant plusieurs mois. Deuxièmement, la défense en profondeur reste la meilleure stratégie : un WAF, une segmentation réseau et une surveillance active peuvent limiter l’impact d’une faille connue.

Que vous soyez un RSSI en charge de la sécurité d’un grand groupe ou un administrateur web d’une PME, l’heure est à la vérification. Avez-vous identifié vos instances Grav ? Sont-elles à jour ? L’été 2026 a montré que personne, pas même les cybercriminels les plus aguerris, n’est à l’abri d’un défaut de mise à jour. La faille Grav CMS CVE-2026-42608 doit servir d’électrochoc pour accélérer la migration vers les versions supportées et renforcer la discipline des correctifs au sein des organisations.