Publié le · mis à jour le · Équipe EPNB
Faille RevSlider : corriger soi-même une extension WordPress vulnérable, et quand ne pas le faire
Retour sur la faille RevSlider exploitée par SoakSoak, le correctif manuel de l'époque et la bonne méthode pour gérer une extension WordPress vulnérable.
Article historique, réécrit en 2026. La faille décrite concernait les anciennes versions de Slider Revolution (RevSlider) en 2014. Le correctif manuel est conservé à titre d’exemple : il ne remplace pas la mise à jour de l’extension.
La faille
Fin 2014, la campagne SoakSoak a compromis des milliers de sites WordPress en exploitant une faille de l’extension RevSlider, souvent livrée avec des thèmes premium. Certaines fonctions d’administration, appelées en AJAX, ne vérifiaient pas que l’utilisateur était connecté et autorisé. Un visiteur anonyme pouvait alors télécharger le fichier wp-config.php (avec les identifiants de la base de données) et, selon les cas, déposer des fichiers malveillants.
Beaucoup de propriétaires de sites ne savaient même pas que l’extension était installée, puisqu’elle était intégrée au thème et ne se mettait pas à jour avec les autres.
Le correctif manuel de l’époque
Quand on ne peut pas mettre à jour une extension tout de suite, par exemple parce que la nouvelle version casse le thème, on peut corriger soi-même la faille, à condition de bien la comprendre. Ici, il manquait un contrôle des droits. Le correctif consistait à n’enregistrer les actions AJAX d’administration que pour un administrateur, dans la méthode addActionAjax du fichier revslider/inc_php/base_admin.class.php (ce fichier pouvait exister en plusieurs exemplaires, dans le dossier des extensions et dans celui du thème) :
protected static function addActionAjax($ajaxAction, $eventFunction){
require_once(ABSPATH . 'wp-includes/pluggable.php');
if (current_user_can('manage_options')) {
self::addAction('wp_ajax_'.self::$dir_plugin."_".$ajaxAction, $eventFunction);
self::addAction('wp_ajax_nopriv_'.self::$dir_plugin."_".$ajaxAction, $eventFunction);
}
}
Les correctifs qui circulaient alors se contentaient souvent de bloquer l’accès à wp-config.php : ils traitaient la conséquence, pas la cause.
Pourquoi c’est une solution d’urgence
Un correctif manuel :
- est écrasé à la prochaine mise à jour de l’extension ;
- ne couvre que la faille connue, pas les suivantes ;
- doit être documenté, sinon personne ne sait qu’il existe.
C’est un pansement, le temps de faire la vraie mise à jour.
La bonne méthode aujourd’hui
- Tenir l’inventaire des extensions et des thèmes, y compris des extensions intégrées à un thème, avec leur version.
- Surveiller les alertes de sécurité les concernant.
- Mettre à jour en préproduction d’abord, tester les parcours importants, puis déployer.
- Remplacer les extensions abandonnées par des alternatives maintenues.
- En cas de compromission, changer tous les mots de passe (WordPress, base de données, FTP ou SSH), régénérer les clés de
wp-config.php, rechercher les fichiers modifiés et restaurer une sauvegarde saine si nécessaire.