Faille Grav CMS (CVE-2026-42608) : le path traversal qui a fait tomber le site de fuite de Clop

En septembre 2026, un événement pour le moins ironique a secoué la sphère cyber. Le groupe de ransomware Clop, connu pour ses cyberattaques de grande envergure, a vu son propre site de fuite de données, hébergé sur le réseau Tor, défiguré par le groupe ShinyHunters. La cause de cette intrusion humiliante ? Une vulnérabilité non corrigée dans leur CMS Grav. Cet incident, rapporté en détail par BleepingComputer, met en lumière une faille critique de type path traversal non authentifié, identifiée sous le code CVE-2026-42608. Ce cas d’école est un signal d’alarme puissant pour toutes les organisations, des startups aux grandes entreprises françaises : la sécurité de votre CMS est un pilier de votre posture cyber, et sa négligence peut avoir des conséquences désastreuses, même pour les acteurs les plus aguerris du secteur.

Le piratage du site de Clop : une leçon de vulnérabilité pour tous

Le groupe Clop utilisait un portail dédié sur le réseau Tor (onion) pour faire pression sur ses victimes en publiant les données volées. En septembre 2026, ce site a été compromis par ShinyHunters. Les assaillants ont d’abord uploadé un simple fichier texte, avant de remplacer entièrement la page d’accueil par un defacement arborant le logo Pokémon Umbreon et un lien vers leur propre site de fuite.

Selon les informations exclusives obtenues par BleepingComputer, le serveur de Clop exécutait Grav CMS dans sa version 1.7.43. L’attaque a été rendue possible par l’exploitation d’une vulnérabilité de type path traversal dans le noyau de Grav, et non dans un plugin tiers. ShinyHunters a affirmé avoir dérobé le code source du site, les plugins Grav, les logs serveur et, surtout, les clés privées du service Tor de Clop. Ce type de données est extrêmement sensible, car il permet potentiellement d’usurper l’identité du service ou de dévoiler des informations opérationnelles critiques.

Face à cette intrusion, Clop a rapidement réagi en déplaçant son site vers une nouvelle adresse .onion. Le groupe a nié toute relation avec ShinyHunters, déclarant ne pas les connaître et ne pas négocier avec eux. « Nous ne les connaissons pas, nous n’avons jamais travaillé avec eux, et pour l’instant nous ne sommes pas en contact avec eux », a affirmé Clop à BleepingComputer. Le groupe a reconnu que son installation Grav n’était pas entièrement à jour, mais a minimisé l’impact de la fuite, assurant que le serveur ne contenait « que du contenu » et aucune donnée financière.

Toutefois, le mal était fait. L’image de l’infaillibilité des cybercriminels professionnels en a pris un coup. Si Clop, un groupe bénéficiant de ressources conséquentes, peut être victime d’une simple faille de mise à jour, qu’en est-il des équipes IT françaises, souvent sous-staffées et confrontées à une dette technique importante ? Ce scénario illustre parfaitement pourquoi le patch management doit rester la priorité numéro un de toute stratégie de cybersécurité.

Décryptage technique de la faille Grav CMS (CVE-2026-42608)

La vulnérabilité au cœur de cet incident est une faille de type unauthenticated path traversal. Pour faire simple, elle permet à un attaquant non authentifié de téléverser un fichier à un emplacement arbitraire sur le serveur, pouvant mener à une exécution de code à distance (RCE).

Mécanisme de l’attaque

Le problème résidait dans la gestion des téléchargements de fichiers via les formulaires Grav. Lors de la soumission d’un formulaire, Grav créait un répertoire temporaire basé sur des paramètres POST, dont le fameux __unique_form_id__. Le chemin généré ressemblait à :

tmp/forms/<session_id>/<unique_id>

Le piège résidait dans l’absence de validation de la valeur de l’identifiant unique (<unique_id>). ShinyHunters a expliqué avoir injecté des séquences de traversée de répertoire, comme ../../../shhq, pour forcer Grav à écrire en dehors du dossier tmp/forms prévu. Le fichier malveillant pouvait alors être déposé n’importe où sous l’installation Grav, par exemple dans le répertoire web racine, menant à une exécution de code à distance.

Chronologie de l’attaque :

1. Détection d’une instance Grav 1.7.43 vulnérable.
2. Injection de la séquence ../../../shhq dans le paramètre __unique_form_id__.
3. Upload d’un fichier texte, puis d’une page de defacement complète.
4. Exfiltration des logs, clés privées et code source.
5. Ransom demandé par ShinyHunters à Clop.

La correction apportée par Grav

Après avoir été alerté par BleepingComputer, l’équipe Grav a confirmé la légitimité de la faille et l’exactitude de la description fournie par les hackers.

“Yes, it’s a legitimate flaw, and the threat actor’s description is accurate.” - Équipe Grav.

Le correctif, introduit dans Grav 2.0.0-beta.2 en avril 2026, consiste en une fonction sanitizeId() qui valide strictement l’identifiant fourni. Désormais, seuls les caractères correspondant à l’expression régulière [A-Za-z0-9,_-]{1,64} sont acceptés, ce qui bloque toute tentative d’injection de ../.

Problème : ce correctif n’avait pas été rétroporté sur la branche stable la plus utilisée, Grav 1.7. Cela a laissé des milliers de sites vulnérables pendant plusieurs mois, y compris celui de Clop.

“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.” - Équipe Grav.

Grav a finalement publié la version 1.7.53.4 pour corriger la faille sur l’ancienne branche.

Pourquoi le plugin Form n’est-il pas en cause ?

Une confusion courante est de penser que la faille se situe dans le plugin Form. Grav a explicitement clarifié que le bug se trouve dans le cœur de Grav (Grav core), pas dans le plugin. Ainsi, la version du plugin Form (par exemple, 7.3.0) n’a aucun impact sur l’exposition à la vulnérabilité. C’est la version du noyau de Grav qui détermine le niveau de risque.

Tableau récapitulatif des versions concernées

Leçons pour la cybersécurité des organisations françaises

Cet incident transfrontalier résonne particulièrement fort dans le paysage de la cybersécurité française, marqué par une vigilance accrue de l’ANSSI et une pression réglementaire forte (RGPD, NIS 2). Il dépasse la simple anecdote technique pour devenir un véritable cas pratique de gestion des risques.

1. Le Patch Management reste le maillon faible de la chaîne de sécurité Selon le rapport 2025 du CLUSIF, près de 70% des incidents de sécurité web sont liés à l’exploitation de vulnérabilités connues pour lesquelles un correctif existait. Le cas de Clop en est l’illustration parfaite. La leçon est brutale : si un gang de cybercriminels aguerris peut être mis à terre par un manque de mise à jour, les entreprises françaises, qui gèrent parfois des centaines d’instances CMS, doivent faire de la gestion des correctifs une priorité stratégique.

2. La gestion des branches obsolètes par les éditeurs est un enjeu critique Grav a reconnu que le correctif existait sur la version 2.0 mais n’avait pas été backporté. Ce problème récurrent dans l’écosystème open source impose aux équipes techniques de :

• Auditer régulièrement leurs versions de CMS.
• Ne pas hésiter à migrer vers les versions majeures supportées, même si la migration est coûteuse en temps.
• Mettre en place une veille sur les CVE via le bulletin de l’ANSSI ou des flux RSS spécialisés.

3. La conformité RGPD impose une sécurité des données par défaut L’Article 32 du RGPD oblige les responsables de traitement à mettre en œuvre des mesures techniques et organisationnelles appropriées pour garantir un niveau de sécurité adapté au risque. L’exploitation de la faille Grav CMS CVE-2026-42608 sur un site traitant des données personnelles (formulaires de contact, cookies, comptes utilisateurs) pourrait entraîner une sanction de la CNIL pour manquement à l’obligation de sécurité. Un correctif de sécurité existant et non appliqué est un facteur aggravant majeur en cas de contrôle.

4. La technique du Directory Traversal est toujours efficace Beaucoup de pentesters et de bug bounty hunters vous le diront : les vulnérabilités les plus simples sont souvent les plus négligées. Le path traversal est une technique connue depuis les débuts du web. Pourtant, elle continue de faire des ravages car elle repose sur un manque de validation des entrées utilisateur, une erreur de programmation fondamentale que l’OWASP place toujours dans le Top 10 des risques de sécurité des applications web.

Comment protéger votre installation Grav CMS face à CVE-2026-42608 ?

Voici les étapes concrètes à mettre en œuvre immédiatement pour sécuriser vos instances Grav et prévenir ce type d’intrusion.

Liste de contrôle post-incident Grav :

• Mise à jour immédiate : Si vous utilisez Grav 1.7, mettez à jour vers la version 1.7.53.4. Si vous utilisez Grav 2.x, assurez-vous d’être sur la dernière version stable.
• Vérification de l’intégrité : Analysez les répertoires tmp/ et cache/ à la recherche de fichiers suspects (webshells, fichiers texte inattendus).
• Rotation des secrets : Si votre site a été potentiellement exposé, révoquez et remplacez toutes les clés API, mots de passe de base de données et certificats TLS.
• Surveillance des logs : Analysez les logs d’accès Apache ou Nginx pour détecter les requêtes contenant des séquences de traversée (../ , %2e%2e , ..\).

Vérification de la version actuelle de Grav : Vous pouvez déterminer votre version directement depuis la ligne de commande :

php -r "require 'vendor/autoload.php'; echo Grav\Common\Grav::instance()['config']->get('system.version');"

Renforcement des permissions : Appliquez le principe du moindre privilège sur les répertoires sensibles :

chmod 755 user/pages
chmod 644 user/config/system.yaml
find . -type f -name '*.php' -exec chmod 644 {} \;

Mettre en place un WAF : Un WAF (Web Application Firewall) peut bloquer les tentatives d’exploitation de type path traversal de manière proactive. Les règles OWASP ModSecurity Core Rule Set sont particulièrement efficaces contre ce type d’injection et peuvent vous offrir une protection en attendant l’application du correctif.

“Si une mise à jour critique est disponible pour votre CMS, votre fenêtre de vulnérabilité est ouverte dès l’instant où le correctif est publié. Les attaquants le savent et l’exploitent.”

Conclusion : l’humilité cyber comme moteur de la résilience

L’affaire du piratage de Clop via la faille Grav CMS CVE-2026-42608 est bien plus qu’un fait divers de la cybercriminalité. C’est une démonstration éclatante que la sécurité est un processus dynamique, jamais un état acquis. Personne n’est à l’abri d’un oubli de mise à jour, pas même les plus grands prédateurs du web.

Pour les RSSI et les DSI français, cette affaire doit servir de déclic. La vulnérabilité Grav CMS que nous avons détaillée est aujourd’hui corrigée, mais demain, une autre faille, sur un autre CMS, émergera. La question n’est pas de savoir si une attaque aura lieu, mais quand. Votre capacité à réagir, à patcher et à auditer vos systèmes définira votre résilience.

Passez à l’action dès aujourd’hui. Vérifiez vos installations Grav, appliquez les correctifs de sécurité, et formez vos équipes aux fondamentaux de la sécurité web. La cybersécurité se gagne à chaque mise à jour, et l’erreur de Clop doit devenir votre leçon.