Exploitation de la faille path traversal Grav CMS (CVE-2026-42608) : retour sur l'attaque Clop par ShinyHunters

Imaginez un instant que l’infrastructure de votre pire concurrent soit compromise par une simple négligence de mise à jour. C’est ce qui est arrivé au groupe de ransomware Clop en septembre 2026. Leur site de fuite a été défiguré et leurs données internes volées par le groupe ShinyHunters via une vulnérabilité de type path traversal dans Grav CMS (CVE-2026-42608).

Cet incident, rapporté en exclusivité par BleepingComputer, est un cas d’école pour les professionnels de la cybersécurité. Il démontre avec une clarté brutale que la gestion des correctifs (patch management) et le durcissement des applications web ne sont pas de simples options techniques, mais des nécessités vitales pour toute organisation. Plongeons dans les détails techniques de cette compromission, analysons son retentissement et établissons une feuille de route concrète pour sécuriser vos propres instances Grav face aux menaces actuelles.

Contexte de l’incident : Clop, ShinyHunters et la guerre des gangs 2.0

Le 25 septembre 2026, le site .onion utilisé par le ransomware Clop pour publier les données de ses victimes affichait un tout autre message. Le groupe ShinyHunters, connu pour ses activités d’extorsion et de revente de données, avait pris le contrôle du serveur et y avait placardé sa signature numérique : le logo du Pokémon Umbreon, accompagné d’un lien vers son propre site de fuite.

Clop, après un silence de quelques jours, a confirmé la compromission tout en minimisant son ampleur.

“Nous ne les connaissons pas, nous n’avons jamais travaillé avec eux, et nous ne sommes pas en contact avec eux. Le serveur ne contenait que du contenu (c’est-à-dire qu’il n’y avait absolument aucune donnée ou activité financière là-bas).” - Clop à BleepingComputer.

Cette déclaration est à prendre avec des pincettes. De son côté, ShinyHunters a affirmé avoir exfiltré des données extrêmement sensibles : le code source de l’infrastructure de Clop, des plugins Grav, les logs serveur, et surtout les clés privées du service Tor utilisé par le site de fuite. Le groupe a même émis une demande de rançon, menaçant de divulguer ces fichiers si aucun paiement n’intervenait.

Ironie du sort, cette attaque entre cybercriminels illustre parfaitement les dynamiques de l’écosystème de la menace. Bien que Clop ait nié toute négociation, son nom a rapidement disparu du site de ShinyHunters, un signe habituellement interprété par les experts comme le début de discussions actives. Pour les observateurs, ce silence en dit long sur la porosité des alliances dans le monde souterrain de la cybercriminalité. L’incident force Clop à déplacer son site de fuite vers une nouvelle adresse .onion, rendant caduque leur ancienne infrastructure.

Détails techniques de la vulnérabilité path traversal Grav CMS

Au cœur de cette compromission se trouve une faille de sécurité dans le cœur même de Grav CMS, la CVE-2026-42608. Selon les informations partagées par ShinyHunters avec BleepingComputer, le serveur cible exécutait Grav CMS 1.7.43, une version de la branche stable 1.7.x.

La vulnérabilité est une faille de type path traversal non authentifiée. Elle permet à un attaquant de manipuler les chemins de fichiers sur le serveur pour écrire du contenu en dehors des répertoires autorisés. En termes simples, un attaquant peut injecter des séquences de type ../ pour “remonter” dans l’arborescence des répertoires du serveur.

Le vecteur d’attaque : le paramètre unique_form_id

La faille réside spécifiquement dans la gestion des téléchargements de formulaires. Le paramètre POST __unique_form_id__ était utilisé par Grav pour créer des répertoires temporaires sous tmp/forms/<session_id>/<unique_id>. Aucune validation stricte n’était appliquée à ce paramètre.

ShinyHunters a exploité cette absence de contrôle en injectant des séquences de directory traversal dans la valeur de __unique_form_id__.

// Code vulnérable (simplifié)
$uniqueId = $_POST['__unique_form_id__'];
$tmpDir = DIR_TMP . '/forms/' . session_id() . '/' . $uniqueId;
if (!is_dir($tmpDir)) {
    mkdir($tmpDir, 0777, true);
}
// Le fichier uploadé est ensuite déplacé dans $tmpDir

En soumettant une requête POST avec la valeur ../../../shhq pour __unique_form_id__, le répertoire temporaire était créé en dehors de la hiérarchie prévue, dans un répertoire racine du site. Le fichier téléchargé (un Web Shell PHP) pouvait alors être placé n’importe où dans l’arborescence, rendant son accès direct par le navigateur possible.

“Oui, il s’agit d’une faille légitime, et la description de l’attaquant est précise.” - Grav à BleepingComputer.

Le correctif : une simple validation de chaîne

Le correctif, implémenté dans Grav 2.0 (version 2.0.0-beta.2) dès avril 2026, introduit une fonction sanitizeId(). Cette fonction applique une allowlist très restrictive sur la valeur du paramètre :

// Code corrigé (simplifié)
$uniqueId = sanitizeId($_POST['__unique_form_id__']);
// La fonction sanitizeId vérifie le regex [A-Za-z0-9,_-]{1,64}

Cette mesure simple, mais radicalement efficace, empêche toute tentative d’injection de path traversal. En n’acceptant que des caractères alphanumériques et quelques symboles inoffensifs, la fonction bloque les séquences ../ et toute autre manipulation de chemin.

Le problème, et c’est là toute la genèse de l’incident, est que ce correctif n’avait pas été backporté vers la branche 1.7.x. “Le décalage était la branche 1.7”, a reconnu Grav. “Grav 2.0 est la version majeure actuelle, mais de nombreux sites tournent encore sur 1.7, et le correctif n’y avait pas été porté.” Cette situation a laissé des milliers de sites vulnérables pendant plusieurs mois.

Portée et impact de la CVE-2026-42608

L’impact de cette faille dépasse largement le cadre de la rivalité entre groupes cybercriminels. Elle met en lumière plusieurs points critiques pour l’ensemble de l’écosystème.

L’incident souligne la complexité de la gestion des correctifs (patch management) dans un environnement hétérogène. Il démontre aussi la dépendance des entreprises à l’égard de leurs chaînes d’approvisionnement logicielles (Software Supply Chain) : une seule faille dans un CMS peut compromettre des milliers de sites.

L’ANSSI rappelle régulièrement que la majorité des intrusions réussies exploitent des vulnérabilités connues et non corrigées. Cet événement en est une parfaite illustration, bien que le “patient zéro” soit lui-même un acteur malveillant.

Les risques concrets pour une organisation victime d’une telle faille sont multiples :

1. Prise de contrôle totale du site web : installation de Web Shells et accès persistant au serveur.
2. Vol de données sensibles : bases de données, fichiers de configuration, code source propriétaire.
3. Atteinte à la réputation : défacement du site, divulgation de données internes.
4. Utilisation du serveur comme point d’appui : pivot vers d’autres systèmes internes, hébergement de contenu malveillant.
5. Compromission des communications : dans le cas de Clop, vol des clés privées du service Tor.

Guide de sécurisation pour les administrateurs Grav

Suite à la divulgation publique par BleepingComputer, Grav a réagi en backportant le correctif vers la branche 1.7, publiant la version 1.7.53.4 dès le 26 septembre 2026. Les administrateurs doivent agir sans délai pour sécuriser leurs instances.

Mettre à jour vers une version corrigée

La première étape, la plus critique, est la mise à jour de votre instance Grav vers une version non vulnérable.

• Vérifiez votre version actuelle dans l’interface d’administration.
• Si vous utilisez Grav 1.7.x, mettez à jour vers la version 1.7.53.4 immédiatement.
• Si vous utilisez Grav 2.x, vous êtes déjà protégé par le correctif.

La mise à jour peut être effectuée via l’interface d’administration ou en ligne de commande :

bin/gpm self-upgrade

Dans la pratique, de nombreuses équipes repoussent les mises à jour par crainte de régressions ou d’incompatibilités avec des plugins tiers. Pourtant, les risques liés à l’exploitation d’une vulnérabilité publique comme la CVE-2026-42608 sont bien plus graves que ceux d’une mise à jour planifiée. Testez la mise à jour dans un environnement de staging avant de l’appliquer en production, mais ne retarde pas son application. La migration vers Grav 2.x est également fortement recommandée pour bénéficier du support actif et des correctifs de sécurité à long terme.

Auditer et durcir la configuration

La mise à jour est indispensable, mais une sécurité pérenne nécessite une approche plus globale. Voici une checklist de durcissement pour les administrateurs Grav :

1. Restreindre les permissions des fichiers : Vérifiez que les répertoires user/, cache/ et tmp/ ont les permissions les plus restrictives possibles (755 pour les répertoires, 644 pour les fichiers). Les répertoires ne doivent pas être exécutables.
2. Empêcher l’exécution de PHP dans les dossiers d’upload : Ajoutez une directive php_flag engine off dans un fichier .htaccess ou une configuration équivalente pour les répertoires d’upload.
3. Configurer un WAF (Web Application Firewall) : Mettez en place des règles de sécurité pour bloquer les tentatives de path traversal (mots-clés comme ../, %2e%2e%2f).
4. Surveiller les logs d’accès : Analysez régulièrement vos logs pour détecter des requêtes POST anormales contenant des séquences de traversée de répertoires.
5. Réaliser des audits de sécurité réguliers : Utilisez des outils de scan de vulnérabilités ou faites appel à des experts pour tester la sécurité de votre application web.
6. Appliquer le principe du moindre privilège : Le compte système exécutant le serveur web ne doit avoir accès qu’aux fichiers strictement nécessaires.

Conclusion : la cybersécurité, une vigilance de tous les instants

L’exploitation de la faille path traversal Grav CMS CVE-2026-42608 par ShinyHunters contre Clop est bien plus qu’un fait divers de la guerre des gangs informatiques. C’est une démonstration éclatante d’un principe fondamental de la sécurité : la confiance ne suffit pas. La vérification rigoureuse des correctifs et la gestion proactive des configurations sont les seules garantes d’une infrastructure saine.

Cet incident nous rappelle qu’aucune organisation, aussi compétente soit-elle dans son domaine d’expertise, n’est à l’abri d’une négligence basique. Une installation non mise à jour est une porte ouverte aux attaquants, qu’ils soient des concurrents malveillants ou des cybercriminels opportunistes.

Avez-vous audité votre parc de CMS récemment ? Avez-vous vérifié que toutes vos instances Grav sont à jour et configurées de manière sécurisée ? La sécurité n’est pas un état, c’est un processus continu. Correctif après correctif, audit après audit, c’est ainsi que l’on construit une résilience durable face aux menaces de demain.