Vulnérabilité Grav CMS CVE-2026-42608 : analyse du piratage de Clop par ShinyHunters et guide de correction

Le monde de la cybercriminalité a récemment été secoué par un événement inattendu : le site de fuite de données du rançongiciel Clop a été piraté et défiguré par le groupe d’extorsion ShinyHunters. Comment un gang de hackers expérimentés a-t-il pu se faire dérober ses clés privées Tor et ses plugins ? L’enquête menée par les journalistes en sécurité a révélé l’exploitation d’une vulnérabilité Grav CMS connue sous la référence CVE-2026-42608. Cette faille de type path traversal non authentifié a permis à ShinyHunters de prendre le contrôle du serveur et d’exiger une rançon auprès des opérateurs du rançongiciel. Cet incident est bien plus qu’un simple fait divers : c’est une leçon magistrale sur les risques liés à la gestion des correctifs, applicable à toutes les organisations, des PME françaises aux plus grandes entreprises.

Contexte de l’attaque : quand chasseurs et chassés se confondent

L’affaire débute lorsque le site de fuite de Clop, un groupe russe de ransomware tristement célèbre pour ses attaques massives, est remplacé par une page de défiguration arborant le logo Pokémon de l’équipe de ShinyHunters. Ce groupe, spécialisé dans l’extorsion et la revente de données, revendique rapidement l’opération, affirmant avoir dérobé le code source, les plugins Grav CMS, les journaux serveur et surtout les clés privées du service Tor du site de fuite. ShinyHunters a alors menacé de divulguer ces informations sensibles si Clop ne payait pas une rançon.

Clop a réagi en déplaçant son site de fuite vers une nouvelle adresse Tor tout en minimisant la gravité de la brèche. « Nous ne les connaissons pas, nous n’avons jamais travaillé avec eux, et pour l’instant nous ne sommes pas en contact avec eux ; de plus, nous ne leur avons fourni aucune information, et nous ne le ferons pas, ni maintenant ni à l’avenir », a déclaré le groupe à la presse spécialisée. Toutefois, Clop a reconnu que son installation Grav n’était pas à jour, confirmant indirectement la vulnérabilité.

« Nous n’avons pas mis à jour le plugin Grav - bien que cela ait fini par arriver - mais le serveur ne contenait que du contenu (cela signifie qu’il n’y avait absolument aucune donnée ou activité financière, et qu’il ne pouvait pas y en avoir). Par conséquent, leur affirmation est sans valeur - tout comme leurs paroles. » - Clop

Cette situation est un cas d’école pour les responsables de la sécurité en France. Selon le baromètre CESIN 2025, 68 % des RSSI français considèrent la gestion des correctifs comme leur priorité absolue, mais seulement 35 % ont automatisé ce processus. En pratique, négliger une mise à jour peut transformer une simple vulnérabilité en incident majeur de sécurité, même pour des acteurs que l’on croit à l’abri.

Pourquoi cette affaire est-elle révélatrice pour le marché français ?

En France, de nombreuses PME et ETI utilisent des CMS comme Grav, WordPress ou Drupal pour leur site vitrine ou leur intranet. D’après une analyse de l’Agence nationale de la sécurité des systèmes d’information (ANSSI), près de 70 % des incidents de sécurité affectant les TPE/PME exploitent des vulnérabilités connues et non corrigées, souvent dans des composants web. L’attaque contre Clop démontre que même des organisations techniquement averties peuvent tomber si les bases de la maintenance ne sont pas respectées.

Analyse technique de la faille CVE-2026-42608 : un path traversal dans Grav Core

La vulnérabilité exploitée par ShinyHunters est une faille de type « Path Traversal » (ou Directory Traversal) affectant le cœur de Grav CMS, et non un simple plugin tiers. Traquée sous la référence CVE-2026-42608, elle permet à un attaquant non authentifié d’écrire des fichiers arbitraires sur le serveur, conduisant à une exécution de code à distance (RCE).

Le vecteur d’attaque : le paramètre __unique_form_id__

Lors du traitement d’un formulaire avec upload de fichier, Grav CMS crée un répertoire temporaire pour stocker le fichier avant de le traiter. Le chemin de ce répertoire est construit dynamiquement à l’aide de valeurs fournies par l’utilisateur via des paramètres POST, sans validation préalable suffisante. En l’occurrence, le paramètre __unique_form_id__ était directement concaténé dans le chemin de destination.

# Chemin vulnérable dans Grav Core 1.7.x
tmp/forms/<session_id>/<unique_id>

# Si l'attaquant fournit __unique_form_id__ = ../../../shhq
# Le chemin devient :
tmp/forms/session123/../../../shhq
# Soit /shhq à la racine web, où le fichier uploadé est déposé.

En utilisant des séquences de traversal (../../../), l’attaquant peut faire écrire le fichier uploadé en dehors du répertoire temporaire prévu, par exemple dans un répertoire web accessible. Il suffit alors d’uploader un fichier PHP malveillant (un webshell) pour prendre le contrôle total du serveur. ShinyHunters a utilisé cette technique pour dérober les clés privées Tor et le code source de l’infrastructure de Clop.

Le correctif et la faille de backport

Grav a confirmé que la description de la vulnérabilité fournie par ShinyHunters était exacte. « Oui, c’est une faille légitime, et la description de l’acteur de la menace est précise », a indiqué l’équipe de développement. La faille a été corrigée dans Grav 2.0 (version bêta 2) dès avril, mais le correctif n’avait pas été rétroporté vers la branche stable 1.7, laissant les installations comme celle de Clop (Grav 1.7.43) exposées.

« La faille vit dans le cœur de Grav, pas dans le plugin Form. La version du plugin Form ne change rien au fait qu’un site soit vulnérable. C’est la version du cœur qui compte. » - Grav, confirmant la CVE-2026-42608.

Le correctif implémente une fonction sanitizeId() qui filtre rigoureusement l’entrée selon une allowlist d’expressions régulières : [A-Za-z0-9,_-]{1,64}. Après divulgation publique, Grav a rétroporté le correctif vers la branche 1.7 avec la version 1.7.53.4.

« C’est la branche 1.7 qui constitue le talon d’Achille, a expliqué Grav à BleepingComputer. Grav 2.0 est la version majeure actuelle, mais de nombreux sites tournent encore sur la 1.7, et le correctif n’avait pas encore été rétroporté. » Cette situation est un exemple classique de faille de backport, un risque bien connu dans l’industrie du logiciel où les versions « legacy » ou stables ne reçoivent pas les correctifs de sécurité avec la même diligence que les branches majeures.

Les leçons à tirer pour la sécurité des CMS en France

Au-delà du spectacle médiatique, l’attaque du site de Clop par ShinyHunters offre des enseignements concrets pour toute organisation utilisant un CMS.

La gestion des branches legacy, un angle mort de la sécurité

De nombreuses entreprises utilisent des versions stables mais anciennes de leurs CMS. Le raisonnement est souvent le suivant : « Si cela fonctionne, pourquoi mettre à jour ? » L’affaire Grav démontre que ce raisonnement est dangereux. La branche 1.7 de Grav était maintenue, mais le correctif critique n’y a pas été appliqué avant qu’un incident ne se produise. En France, où le tissu économique est composé de nombreuses PME utilisant des solutions mutualisées ou des versions figées de CMS, ce risque est sous-estimé.

« Dans notre pratique d’audit de sécurité, nous rencontrons fréquemment des architectures où la branche stable du CMS est délaissée, faute de temps ou de budget, alors même que l’éditeur publie des correctifs de sécurité. » Cela vaut pour Grav, mais aussi pour WordPress (avec ses plugins abandonnés) ou Drupal.

L’importance cruciale de la validation des entrées

La CVE-2026-42608 est un rappel brutal de l’un des principes fondamentaux de la sécurité applicative : ne jamais faire confiance aux entrées utilisateur. Un simple paramètre POST (__unique_form_id__), non nettoyé, a permis la compromission totale d’un serveur. Selon l’ANSSI, les vulnérabilités liées à une mauvaise gestion des entrées représentent encore plus de 60 % des failles d’applications web.

Par ailleurs, cette affaire souligne l’importance de comprendre l’architecture de ses composants. Grav a précisé que la vulnérabilité se trouve dans le cœur (core) et non dans le plugin Form. Si les administrateurs s’étaient concentrés uniquement sur la mise à jour des plugins, le serveur serait resté vulnérable. La connaissance précise de l’empreinte logicielle est donc un prérequis.

Les bonnes pratiques pour sécuriser votre CMS

Voici une liste d’actions concrètes à mettre en œuvre pour prévenir ce type d’incident :

1. Audit régulier des versions : Tenez un inventaire précis de toutes vos instances CMS, incluant la version du cœur et de chaque plugin. Utilisez des outils d’analyse de dépendances.
2. Veille de sécurité active : Abonnez-vous aux flux de sécurité de l’éditeur (GitHub Advisory Database, mailing lists, CVE feeds). Un bulletin de sécurité doit déclencher une alerte.
3. Automatisation du patching : Mettez en place une procédure de déploiement automatisé (CI/CD, gestion de configuration comme Ansible ou Puppet) pour appliquer les correctifs de sécurité dans un délai défini (ex : 48h pour les correctifs critiques).
4. Principe du moindre privilège sur les répertoires d’upload : Assurez-vous que les répertoires où les fichiers uploadés sont stockés ne sont pas exécutables (supprimez les droits d’exécution via .htaccess ou la configuration Nginx).
5. Segmentation réseau : Ne jamais héberger un CMS public sur le même serveur ou le même segment réseau que les bases de données contenant des données sensibles ou des systèmes critiques.
6. Sauvegardes et plan de remédiation : Préparez un plan de réponse aux incidents basé sur la compromission de votre CMS. Avoir une sauvegarde propre permet de reconstruire rapidement un serveur sans verser de rançon.

Guide pratique pour corriger la vulnérabilité Grav CMS sur votre serveur

Si vous utilisez Grav CMS, voici les étapes à suivre immédiatement pour vérifier si vous êtes exposé à la CVE-2026-42608 et appliquer le correctif.

1. Identifiez votre version de Grav

Connectez-vous à votre serveur et exécutez la commande suivante dans le répertoire racine de votre installation Grav :

cd /var/www/html
php bin/grav version

Ou consultez la variable version dans le fichier user/config/system.yaml ou l’interface d’administration.

2. Évaluez le niveau de risque

Consultez le tableau suivant pour déterminer la criticité de l’action :

3. Appliquez le correctif immédiatement

Pour mettre à jour Grav 1.7.x vers la version corrigée (1.7.53.4 ou ultérieure), utilisez le gestionnaire de plugins Grav :

cd /var/www/html
bin/gpm self-upgrade

Si vous êtes en version 2.x, vérifiez que vous êtes bien sur une version supérieure à 2.0.0-beta.2. Grav conseille vivement de migrer vers la branche 2.x si vous êtes encore en 1.7, car c’est la version activement maintenue.

« Nous exhortons toute personne utilisant encore la branche 1.7 à mettre à niveau vers la version 1.7.53.4. Les utilisateurs des versions actuelles de Grav 2.x sont déjà protégés contre cette vulnérabilité depuis des mois. » - Grav

4. Vérifiez l’absence de compromission

Après la mise à jour, il est impératif de rechercher des signes de compromission :

• Vérifiez les fichiers .php modifiés ou ajoutés récemment dans les répertoires web (webshells).
• Consultez les logs serveur (Apache, Nginx) pour des requêtes POST suspectes contenant des séquences ../ ou des tentatives d’upload.
• Vérifiez l’intégrité de vos fichiers de configuration, notamment les clés privées et les fichiers .env.

5. Renforcez la configuration

Assurez-vous que la fonction sanitizeId() est bien présente dans les fichiers sources de votre installation mise à jour (elle se trouve dans le noyau Grav). Si vous aviez des formulaires personnalisés, vérifiez qu’ils respectent bien la nouvelle validation.

Conclusion : la gestion des correctifs comme pilier de la résilience

L’histoire du piratage du site de Clop par ShinyHunters est bien plus qu’une anecdote dans le monde obscur de la cybercriminalité. C’est une démonstration éclatante que la sécurité ne se décrète pas : elle se construit, correctif après correctif. La vulnérabilité Grav CMS CVE-2026-42608 a prouvé qu’un simple oubli de mise à jour, couplé à un défaut classique de validation d’entrée, suffit à compromettre l’infrastructure d’un groupe entier, aussi expérimenté soit-il.

En France, où les obligations de sécurité du RGPD et les recommandations de l’ANSSI imposent une vigilance constante, cet incident doit servir de déclencheur. La mise à jour de votre CMS n’est pas une corvée technique, c’est un acte de gestion des risques. Vérifiez votre version de Grav dès aujourd’hui. Ne laissez pas un simple paramètre __unique_form_id__ non sanitisé compromettre l’ensemble de votre sécurité numérique.