Faille Grav CMS CVE-2026-42608 : retour sur le piratage du site de Clop par ShinyHunters

Le 25 septembre 2026, une information aussi surprenante que révélatrice secoue le monde de la cybersécurité : le site de fuite de données du groupe rançongiciel Clop a été piraté. L’attaquant ? ShinyHunters, un groupe concurrent. Le vecteur d’attaque ? Une vulnérabilité de type path traversal non authentifiée dans Grav CMS, identifiée sous le code CVE-2026-42608. Ce cas d’école démontre avec une ironie cinglante qu’aucune infrastructure, pas même celle des cybercriminels les plus aguerris, n’est à l’abri d’une faille de sécurité Grav CMS non corrigée. L’analyse technique qui suit décortique l’attaque et propose des pistes concrètes pour sécuriser vos propres systèmes.

Grav CMS CVE-2026-42608 : Anatomie d’un piratage

Le déroulé de l’attaque ShinyHunters

L’histoire est savoureuse pour les observateurs de la cybersécurité. Le groupe Clop, connu pour ses attaques de grande envergure (MOVEit, GoAnywhere), a vu son propre outil de pression se retourner contre lui. ShinyHunters, un groupe extorqueur rival, a réussi à s’introduire sur le serveur Tor hébergeant le site de fuite de Clop. L’objectif ? Défigurer le site (defacement) en affichant le logo Pokémon Umbreon et voler des données sensibles.

Clop a rapidement déplacé son site vers une nouvelle adresse .onion, confirmant l’intrusion tout en minimisant son ampleur. Le groupe a nié toute négociation ou paiement à ShinyHunters.

“We do not know them, we have never worked with them, and at the moment we are not in contact with them ; furthermore, we have not provided them with any information, nor will we do so-either now or in the future.” - Clop à BleepingComputer.

Malgré ces dénégations, ShinyHunters a affirmé avoir dérobé le code source du site, les plugins Grav CMS, les journaux de connexion (logs serveur) et, plus inquiétant, les clés privées du service Tor. Ces éléments constituent une mine d’or pour déstabiliser un adversaire et prouvent que les mesures OPSEC d’un groupe rançongiciel peuvent être contournées par un simple défaut de maintenance.

Le défaut path traversal dans le paramètre unique_form_id

Le point central de cette affaire est la vulnérabilité CVE-2026-42608. Il s’agit d’une faille de type directory path traversal non authentifiée, située dans le cœur de Grav CMS (et non dans le plugin Form, comme certains auraient pu le croire).

ShinyHunters a expliqué à BleepingComputer que le serveur victime tournait sous Grav CMS 1.7.43. La vulnérabilité résidait dans la gestion des téléchargements de fichiers via les formulaires. Le code vulnérable utilisait des valeurs fournies par l’utilisateur via des paramètres POST lors de la création de répertoires temporaires pour les téléchargements, sans valider ces valeurs comme des composants de chemin sûrs.

Le paramètre identifié est __unique_form_id__. La valeur de ce paramètre était insérée dans un chemin temporaire de type :

tmp/forms/<session_id>/<unique_id>

En injectant des séquences de type directory traversal (par exemple ../../../shhq) dans le paramètre __unique_form_id__, un attaquant non authentifié pouvait forcer Grav CMS à créer un répertoire de téléchargement en dehors du dossier tmp/forms prévu. Conséquence directe : le fichier téléchargé (une simple coquille web ou un script malveillant) pouvait être écrit à n’importe quel endroit de l’arborescence du site.

La correction tardive : le backport vers la branche 1.7

Grav a confirmé la vulnérabilité et a expliqué que le correctif consistait à ajouter une fonction sanitizeId() qui filtre strictement les identifiants acceptés. L’expression régulière (allowlist) est la suivante :

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

Cette mesure bloque immédiatement toute tentative d’injection de caractères spéciaux comme les points (.) ou les slashes (/). Le correctif était déjà présent dans Grav CMS 2.0 (dès la version 2.0.0-beta.2), publié en avril 2026. Cependant, la branche 1.7, pourtant largement déployée, n’avait pas reçu ce correctif.

C’est exactement ce qui a piégé Clop. Leur installation en 1.7.43 était vulnérable, et ce n’est qu’après la divulgation publique de l’exploit par ShinyHunters que Grav a backporté le correctif dans la version 1.7.53.4.

“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 à BleepingComputer.

Cette situation soulève une question cruciale pour la gestion des risques : que faire des branches logicielles maintenues en fin de vie ou orphelines de correctifs ?

Leçons opérationnelles : l’angle mort des infrastructures web

L’illusion de la sécurité des infrastructures cybercriminelles

De nombreuses entreprises pensent que les cybercriminels sont des experts en sécurité. Clop prouve le contraire : ils utilisent les mêmes outils (CMS, serveurs web, bases de données) que les entreprises légitimes, avec les mêmes négligences. Un Grav, WordPress, ou Drupal mal mis à jour est une porte ouverte, quel que soit l’occupant du serveur.

Exemple concret : Une PME française spécialisée dans la gestion de documents sensibles a été compromise en 2025 suite à l’exploitation d’une faille de type path traversal sur un plugin de formulaire non mis à jour. L’attaquant a téléchargé une backdoor et exfiltré l’intégralité de la base de données clients. Le parallèle avec l’attaque de Clop est frappant : le vecteur initial est identique, seule l’identité de la victime change.

Le mythe de l’invulnérabilité des infrastructures criminelles vole en éclats. La leçon est claire : la sécurité ne dépend pas de la nature de l’organisation, mais de la rigueur des maintenances applicatives.

Statistiques clés sur la sécurité des CMS :

• Selon le rapport ANSSI 2025 sur les menaces, les vulnérabilités liées aux CMS représentent plus de 30% des vecteurs d’intrusion initiaux sur les applications web.
• Une étude d’Edgedelta (2026) indique que 40% des sites sous Grav CMS utilisent encore une version de la branche 1.7.x.
• Le temps moyen entre la divulgation d’une faille CMS et son exploitation massive est de moins de 72 heures (Verizon DBIR 2026).

L’impact OPSEC d’un CMS mal maintenu

Le vol des clés privées Tor est une catastrophe opérationnelle pour Clop. Sans ces clés, il est impossible de prouver la légitimité d’un nouveau site .onion. Un attaquant pourrait usurper l’identité du groupe, ou rediriger les victimes vers un faux site de fuite. Pour une entreprise, la perte de clés privées SSO, de certificats TLS ou de clés de signature de code aurait des conséquences analogues. Cet incident souligne donc l’importance de la gestion du cycle de vie des clés et des certificats, un aspect souvent négligé dans les politiques de sécurité.

Mesures concrètes pour sécuriser votre CMS Grav

Mettre à jour Grav CMS vers la version 1.7.53.4 ou 2.0

Si vous utilisez encore Grav CMS 1.7.x, vous devez impérativement migrer vers la version 1.7.53.4 ou, mieux, vers Grav 2.x. La version 2.0 intègre nativement les correctifs pour cette vulnérabilité et bénéficie d’un support actif.

Action immédiate : Vérifiez votre version actuelle dans l’interface d’administration ou via la console avec la commande php bin/gpm version.

Procédure : Suivez le guide de mise à jour officiel de Grav. Sauvegardez impérativement votre site et votre base de données avant toute opération.

Tableau comparatif : Vulnérabilité CVE-2026-42608 par version

Défense en profondeur : WAF, logs et permissions

Un WAF (Web Application Firewall) comme ModSecurity avec la règle OWASP Core Rule Set (CRS) aurait bloqué la tentative d’injection de path traversal. La règle clé est de bloquer les requêtes HTTP contenant les patterns ../ dans les paramètres GET/POST (sauf si strictement nécessaire).

Configuration recommandée pour ModSecurity :

SecRule ARGS "@rx \.\./" "id:930110,phase:2,deny,status:403,msg:'Path Traversal Attack'"

Il est impératif de tester ces règles en mode DetectionOnly avant de les appliquer en On pour éviter de bloquer du trafic légitime. Une analyse des logs d’audit de ModSecurity permet d’identifier les faux positifs.

Gestion des accès et principes de moindre privilège

L’attaque de ShinyHunters n’a pas nécessité de privilèges administrateur initiaux. Cela rappelle que les comptes de service et les permissions systèmes doivent être strictement contrôlés.

• Le serveur web doit s’exécuter avec un compte système dédié ayant un accès en écriture limité aux dossiers cache, images, assets.
• Les répertoires temporaires (tmp/forms) ne doivent pas être exécutables.
• Utilisez l’authentification multifacteur (MFA) pour l’interface d’administration de Grav.
• Activez la journalisation des actions administrateurs pour tracer toute modification suspecte.

Surveillance et détection des incidents

Les logs d’accès du serveur web doivent être centralisés dans un SIEM. Des alertes doivent être créées sur les patterns d’attaque connus.

Exemple d’alerte Elasticsearch (Elastic Security) :

event.module: \"nginx\" AND http.request.uri: \"*__unique_form_id__*../*\"

Si Clop avait surveillé ses logs en temps réel, l’attaque aurait pu être stoppée à la phase de reconnaissance, bien avant le défacement et le vol de données.

Préparer un plan de réponse aux incidents (PRI)

L’affaire Clop/ShinyHunters a démontré l’importance d’avoir un plan de réponse aux incidents prêt à être exécuté. Clop a immédiatement déplacé son site vers un nouveau domaine Tor. Dans une entreprise, le PRI doit inclure :

• L’isolation immédiate du serveur compromis (déconnexion du réseau).
• La sauvegarde des logs et des images mémoire pour l’analyse forensique.
• La communication de crise (interne, clients, régulateur CNIL).
• La remédiation (nettoyage du serveur, mise à jour, restauration depuis une sauvegarde propre).
• Le retour d’expérience (Retex) pour améliorer la sécurité.

Checklist actionnable pour les DSI :

1. Identifier tous les CMS utilisés dans votre Système d’Information (Grav, WordPress, Drupal, etc.).
2. Vérifier les versions de chaque instance.
3. Appliquer les correctifs de sécurité dès leur publication (Vendor Advisories).
4. Activer les logs d’accès et d’erreur du serveur web (Apache / Nginx).
5. Analyser les logs pour détecter des tentatives d’exploitation (pattern ../, ..\\, etc.).
6. Mettre en place un WAF pour filtrer les entrées malveillantes.
7. Tester la restauration de votre site à partir d’une sauvegarde propre.

En France, la directive NIS 2 et le RGPD (Article 32 : sécurité du traitement) imposent aux entreprises de prendre des mesures techniques appropriées. Une fuite de données exploitant une vulnérabilité CMS non corrigée expose l’entreprise à des sanctions. L’affaire Clop/ShinyHunters, bien que se déroulant dans le Dark Web, est transposable à n’importe quelle organisation négligeant la maintenance de ses applicatifs web.

Conclusion : un signal d’alarme pour les DSI français

L’affaire du piratage du site de Clop par ShinyHunters n’est pas un simple fait divers cybercriminel. C’est une démonstration éclatante que la sécurité d’un CMS ne tolère aucun compromis. Que vous soyez une PME, un grand groupe ou une agence gouvernementale, le scénario est le même : un serveur non mis à jour, une vulnérabilité connue (CVE-2026-42608), et c’est tout votre système d’information qui peut s’effondrer.

La leçon à tirer de cette faille de sécurité Grav CMS est simple mais vitale : la sécurité web repose sur la rigueur quotidienne des mises à jour, la surveillance des logs et l’application des principes de l’OWASP. Chez Clop, l’erreur a été de penser que leur infrastructure Tor les mettait à l’abri. Dans votre organisation, l’erreur serait de repousser à demain la mise à jour de votre CMS.

Prochaine action à mener : Vérifiez dès maintenant la version de votre Grav CMS et appliquez la mise à jour 1.7.53.4 ou migrez vers Grav CMS 2.0. N’attendez pas qu’un incident similaire ne survienne dans votre infrastructure.