Un avis de sécurité a été publié concernant une vulnérabilité dans le plugin Photo Gallery by 10Web, qui compte plus de 200 000 installations. Cette faille concerne la gestion des **commentaires d’images** par le plugin et expose certains sites à une **modification non autorisée des données** par des attaquants non authentifiés (c’est-à-dire des acteurs qui n’ont pas besoin de s’enregistrer ou de se connecter au site).
Le plugin Photo Gallery by 10Web est largement utilisé sur des sites WordPress pour créer et afficher des galeries d’images, des diaporamas et des albums avec divers agencements visuels. On le trouve fréquemment sur des sites de photographie, des portfolios et des sites d’entreprises qui s’appuient fortement sur du contenu visuel.
À propos de la vulnérabilité
La faille peut être exploitée par des visiteurs **non authentifiés**, ce qui signifie que n’importe quel internaute peut déclencher l’exploitation sans être connecté. Cette caractéristique augmente sensiblement l’ampleur du risque, car il n’existe pas de barrière d’entrée comme l’obligation de s’inscrire ou d’obtenir un niveau de permission spécifique.
Il est important de souligner que la fonctionnalité concernée — les **commentaires d’images** — n’est disponible que dans la version **Pro** du plugin. Les sites qui n’utilisent pas cette fonctionnalité ne sont donc pas exposés à ce cas d’utilisation précis.
Ce qui a mal tourné
La vulnérabilité provient d’une absence de vérification des autorisations dans la fonction delete_comment() du plugin.
Concrètement, le plugin ne vérifie pas si la requête visant à supprimer un commentaire d’image émane d’un utilisateur qui a effectivement le droit d’effectuer cette action. Dans l’écosystème WordPress, il est attendu des extensions qu’elles valident les capacités ou permissions des utilisateurs avant de modifier le contenu du site. Cette vérification manque ici, ce qui conduit le plugin à accepter des demandes de suppression même lorsqu’elles proviennent d’utilisateurs non authentifiés.
Outre le contrôle des capacités, les bonnes pratiques recommandent d’utiliser des protections complémentaires (par exemple des nonces pour les requêtes côté front-end/back-end et des vérifications côté serveur) ; l’absence ou l’insuffisance de ces contrôles accroît la surface d’attaque.
Ce que peuvent faire les attaquants
Un acteur malveillant peut supprimer de manière arbitraire des **commentaires d’images** sur un site affecté. Cette vulnérabilité a reçu une notation de gravité de **5.3** (niveau moyen). Elle n’autorise pas une compromission complète du site ni une prise de contrôle du serveur, mais permet bien la suppression non autorisée de données — en l’occurrence des commentaires rattachés aux images.
Pour des sites qui s’appuient sur ces commentaires pour l’engagement des utilisateurs, l’historique de modération ou la preuve d’interaction, la suppression non autorisée peut entraîner une perte d’informations, une perturbation des échanges et une atteinte à la confiance des visiteurs.
L’avis officiel de Wordfence détaille la vulnérabilité :
“The Photo Gallery by 10Web – Mobile-Friendly Image Gallery plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the delete_comment() function in all versions up to, and including, 1.8.36. This makes it possible for unauthenticated attackers to delete arbitrary image comments. Note: comments functionality is only available in the Pro version of the plugin.”
En résumé, la faiblesse technique permet à un attaquant d’envoyer une requête formatée qui sera acceptée par le plugin et traitera la suppression sans vérification préalable des droits de l’auteur de la requête.
Quelles versions peuvent être exploitées
La faille impacte **toutes les versions** du plugin jusqu’à et y compris la version **1.8.36**. Le problème est strictement lié à la fonctionnalité de suppression des commentaires d’images ; de ce fait, l’exploitation est limitée aux sites qui exécutent la version **Pro** du plugin et qui ont activé la fonctionnalité de commentaires.
Aucune configuration serveur particulière ni interaction spéciale d’un utilisateur ne sont nécessaires : l’exigence pour qu’une attaque réussisse se limite au fait que le plugin vulnérable soit actif et exploitable sur le site.
Ce que les propriétaires de sites doivent faire
Un correctif est disponible. Les propriétaires de sites doivent mettre à jour le plugin Photo Gallery by 10Web vers la version **1.8.37** ou ultérieure, qui inclut la correction de sécurité permettant de résoudre ce problème. Si une mise à jour immédiate n’est pas réalisable, la désactivation temporaire du plugin ou de la fonctionnalité de commentaires empêchera l’exploitation jusqu’à ce que la mise à jour puisse être appliquée.
En pratique, maintenir les extensions à jour reste la mesure directe et la plus efficace pour corriger ce type de vulnérabilité.
Featured Image by Shutterstock/Roman Samborskyi
Étapes détaillées de correction et recommandations opérationnelles
Voici un ensemble d’actions concrètes et recommandées, détaillées et adaptées aux propriétaires et administrateurs WordPress, pour réduire le risque et corriger la vulnérabilité :
- Mettre à jour le plugin : appliquer la mise à jour vers la version 1.8.37 ou supérieure via le tableau de bord WordPress (Extensions → Extensions installées → Mettre à jour) ou via un outil en ligne de commande si vous utilisez WP-CLI. Vérifiez l’historique et le changelog du plugin pour confirmer l’inclusion du correctif.
- Tester en environnement de staging : avant de déployer sur la production, effectuez la mise à jour sur une copie de staging pour vérifier la compatibilité avec d’autres extensions et le thème. Cela réduit les risques d’effet de bord.
- Créer des sauvegardes : réalisez une sauvegarde complète (fichiers + base de données) avant la mise à jour afin de pouvoir restaurer l’état antérieur si un problème survient.
- Désactiver la fonctionnalité de commentaires : si la mise à jour n’est pas immédiatement possible, désactivez la fonctionnalité de commentaires d’images dans la configuration du plugin Pro ou désactivez entièrement le plugin jusqu’à correction.
- Contrôler les journaux : examinez les logs d’accès (web server) et les journaux d’application pour repérer des requêtes suspectes ciblant la suppression de commentaires (toutes requêtes POST/GET non usuelles ou depuis des IPs répétées).
- Auditer les suppressions récentes : comparez les sauvegardes récentes et l’historique des modifications pour vérifier si des commentaires importants ont été supprimés sans autorisation. Si des suppressions non autorisées sont détectées, documentez-les et restaurez depuis une sauvegarde si nécessaire.
- Utiliser une solution de WAF : une Web Application Firewall (WAF) peut bloquer des requêtes anormalement formatées et réduire la surface d’attaque pour les périodes où un correctif n’est pas encore appliqué.
- Informer les parties prenantes : si des données utilisateur ou des commentaires publics ont été affectés, rédigez un résumé factuel de l’incident à partager avec les équipes concernées (modération, communication, support) afin de coordonner la réponse.
Comment vérifier si votre site a été ciblé
Pour déterminer si votre site a été victime d’exploitation liée à cette vulnérabilité, procédez aux vérifications suivantes :
- Historique des suppressions : examinez la base de données (table des commentaires ou tables spécifiques au plugin) pour détecter des suppressions récentes. Si vous conservez des sauvegardes régulières, comparez l’état des commentaires entre plusieurs sauvegardes.
- Journaux d’accès : recherchez des requêtes vers des endpoints liés à la suppression de commentaires (requêtes POST/GET inhabituelles, paramètres identifiables). Notez les adresses IP, les User-Agent et les fréquences de requêtes.
- Logs d’administration : si vous avez activé des plugins d’audit (ex. Simple History, WP Activity Log), vérifiez les actions de suppression et identifiez si elles proviennent d’un compte authentifié ou d’une origine non authentifiée.
- Recherche de motifs : identifiez si plusieurs suppressions ont suivi un schéma (mêmes paramètres, mêmes références d’image, mêmes horodatages rapprochés) — signe typique d’exploitation automatisée.
- Scanner de vulnérabilités : exécutez un scan avec des outils de sécurité reconnus (ex. WPScan, Sucuri scanner) pour identifier les versions vulnérables et d’autres faiblesses potentielles sur le site.
Mesures supplémentaires recommandées
Au-delà de la correction immédiate, adoptez ces bonnes pratiques de sécurité pour limiter la probabilité d’exposition à d’autres vulnérabilités :
- Principe du moindre privilège : assurez-vous que seuls les comptes ayant besoin d’un accès à la modération puissent supprimer des commentaires (permissions minimales).
- Protection des endpoints : utilisez des jetons (nonces) pour valider les requêtes côté client et côté serveur, et vérifiez systématiquement les capacités métiers (via current_user_can() ou équivalent) avant toute modification de données.
- Mises à jour régulières : planifiez un processus de maintenance pour appliquer les mises à jour de WordPress, des thèmes et des extensions de façon régulière et contrôlée.
- Monitoring et alerting : activez une surveillance qui alerte sur des événements critiques (nombre élevé de suppressions, erreurs 500 répétées, tentatives d’accès suspectes).
- Sauvegardes automatisées : conservez plusieurs points de restauration, avec une stratégie de rétention adaptée (ex. sauvegardes quotidiennes conservées 30–90 jours selon le besoin).
Recommandations techniques pour les développeurs
Pour les développeurs d’extensions ou d’intégrations qui souhaitent comprendre comment corriger ou éviter ce type de problème, voici quelques pratiques et éléments techniques à considérer :
- Vérifier les capacités : avant de supprimer une ressource, vérifier systématiquement si l’utilisateur en cours possède la capacité requise (ex.
current_user_can('moderate_comments')ou une capacité métier définie pour l’extension). - Valider les requêtes : utilisez des nonces (ex.
check_admin_referer()pour les requêtes côté admin ouwp_verify_nonce()pour les traitements personnalisés) afin d’attester de l’origine des actions effectuées depuis l’interface. - Contrôles côté serveur : ne vous fiez pas exclusivement aux contrôles côté client (JavaScript). Toutes les vérifications d’autorisation doivent être répétées côté serveur avant toute opération sensible.
- Journaliser les actions : consignez les actions critiques (suppression, modification, création) avec l’identité de l’auteur, l’heure et l’IP pour faciliter les audits a posteriori.
- Traiter correctement les réponses : renvoyez des codes HTTP appropriés (401 pour non authentifié, 403 pour non autorisé) et des messages explicites, sans divulguer d’informations techniques sensibles.
Exemple de modèle de contrôle auteurisation (pseudo-code PHP) :
// Avant d'effectuer la suppression
if ( ! is_user_logged_in() ) {
wp_send_json_error( 'Utilisateur non authentifié', 401 );
}
if ( ! current_user_can( 'moderate_comments' ) ) {
wp_send_json_error( 'Permission insuffisante', 403 );
}
// Vérification du nonce si applicable
if ( ! wp_verify_nonce( $_REQUEST['_wpnonce'], 'delete_image_comment' ) ) {
wp_send_json_error( 'Token invalide', 400 );
}
// Procéder à la suppression
wp_delete_comment( $comment_id, true );
wp_send_json_success( 'Commentaire supprimé' );
Notez que le nom exact de la capacité (moderate_comments dans cet exemple) doit correspondre aux règles métiers et à la logique du plugin : certains cas d’utilisation requièrent des capacités personnalisées ou des rôles spécifiques.
Scénarios post-exploitation et réponses à envisager
Si vous découvrez que votre site a été affecté (commentaires supprimés), évaluez l’étendue et suivez une procédure structurée :
- Identifier l’impact : recensez les éléments supprimés et l’ampleur (nombre de commentaires, comptes impactés).
- Collecter des preuves : conservez les logs et captures d’écran, exportez les entrées de la base de données pertinentes pour analyse.
- Restaurer si nécessaire : si la suppression a causé une perte de données critiques, restaurez depuis une sauvegarde cohérente. Informez les équipes concernées.
- Appliquer le correctif : installez la version corrigée du plugin et vérifiez que la suppression ne peut plus être provoquée sans autorisation.
- Revoir la sécurité : profitez de l’incident pour réévaluer les contrôles d’accès, les politiques de sauvegarde et les procédures de déploiement.
Questions fréquentes (FAQ)
Q : Est-ce que tous les sites utilisant Photo Gallery by 10Web sont vulnérables ?
R : Non, l’exploitation concerne uniquement les versions du plugin jusqu’à la 1.8.36 et, de façon pratique, les installations utilisant la fonctionnalité de **commentaires d’images** disponible dans la version **Pro**.
Q : Cette vulnérabilité permet-elle une prise de contrôle totale du site ?
R : Non. Selon l’analyse de la vulnérabilité, elle autorise la suppression non autorisée de commentaires d’images mais ne confère pas, à elle seule, un accès administratif complet ni l’exécution arbitraire de code serveur.
Q : Que faire si je ne peux pas mettre à jour le plugin tout de suite ?
R : Désactivez temporairement le plugin ou sa fonctionnalité de commentaires d’images. Parallèlement, surveillez les logs et appliquez d’autres mesures de réduction du risque (WAF, restrictions IP si pertinent).
Q : Dois-je informer mes utilisateurs si des commentaires ont été supprimés ?
R : Si la suppression a affecté des contributions publiques ou a un impact sur l’expérience utilisateur, il est conseillé de communiquer de façon factuelle avec les personnes concernées, en expliquant l’incident et les mesures prises pour corriger la situation.
Conclusion
La vulnérabilité découverte dans Photo Gallery by 10Web illustre l’importance de la vérification stricte des autorisations et du suivi des mises à jour sur les installations WordPress. Bien que le risque n’ait pas l’ampleur d’une compromission complète du serveur, la possibilité de suppression non autorisée de commentaires peut avoir des conséquences non négligeables pour la modération, l’engagement et la conservation de preuves.
Pour réduire ce risque : appliquez la mise à jour vers la version **1.8.37** ou ultérieure, testez les correctifs en staging, maintenez des sauvegardes régulières et mettez en place des contrôles d’accès robustes. Ces mesures combinées limitent l’exposition et renforcent la résilience de votre site face à ce type d’incident.
