WordPress : 11 334 failles en 2025, et 91 % viennent des plugins

Patchstack coordonne une grande partie des divulgations de failles de l'écosystème WordPress, via son programme de bug bounty et son rôle d'autorité CVE. Son rapport State of WordPress Security in 2026, publié en février, dresse le bilan de 2025 : 11 334 nouvelles vulnérabilités, soit 42 % de plus qu'en 2024. Le cœur de WordPress n'en compte que 6, toutes de faible priorité. Tout le reste vient des extensions : 91 % des plugins, 9 % des thèmes.

Une dépendance comme les autres

Un plugin WordPress est exactement ce qu'est un paquet npm pour une application JavaScript : du code tiers, écrit par quelqu'un d'autre, qui s'exécute avec tous les droits de votre site. Un site en cumule souvent plusieurs, chacun maintenu à son rythme, parfois par une seule personne. C'est pourquoi le volume de failles suit le nombre d'extensions plutôt que la qualité du cœur.

Toutes ces failles ne se valent pas. Patchstack estime que 4 124 d'entre elles (36 %) justifiaient une règle de protection, et que 1 966 (17 %) étaient assez graves pour être exploitées à grande échelle. Ce sous-ensemble est celui qui progresse le plus : +113 % de failles hautement exploitables en un an. Les extensions payantes ne sont pas plus sûres : 1 983 rapports valides (29 % du total) les concernent, dont 76 % exploitables en conditions réelles, et elles comptent trois fois plus de failles activement exploitées que les extensions gratuites.

Cinq heures, et souvent pas de correctif

Deux chiffres résument le problème. D'abord, 46 % des failles n'avaient aucun correctif de l'éditeur au moment de leur publication : mettre à jour ne sert à rien quand il n'existe pas de mise à jour. Ensuite, pour les failles les plus exploitées, le délai médian pondéré entre la publication et l'exploitation de masse est de cinq heures, et environ la moitié des failles à fort impact ont été exploitées dans les 24 heures.

Le pare-feu de l'hébergeur ne comble pas l'écart. Patchstack a testé les protections de plusieurs hébergeurs contre des attaques réelles : sur des failles WordPress connues et exploitées, elles n'ont bloqué que 12 % des attaques, et 26 % sur un échantillon plus large. Une règle WAF générique reconnaît une injection SQL classique, mais pas une requête parfaitement légitime adressée à une action AJAX qu'un plugin a oublié de protéger.

Anatomie de la faille la plus exploitée

Selon Patchstack, le contrôle d'accès défaillant est la classe de failles la plus exploitée en 2025. Dans un plugin, elle prend presque toujours la même forme : un point d'entrée (action AJAX, route REST) qui exécute une opération sensible sans vérifier qui la demande. Le hook wp_ajax_nopriv_ rend l'action accessible aux visiteurs non connectés, et l'absence de current_user_can() et de vérification de nonce fait le reste.

// Vulnerable: any visitor, logged in or not, can change any option
add_action('wp_ajax_nopriv_myplugin_save', 'myplugin_save');
add_action('wp_ajax_myplugin_save', 'myplugin_save');
function myplugin_save() {
    update_option($_POST['key'], $_POST['value']);
    wp_send_json_success();
}

// Fixed: logged-in admins only, nonce checked, allowlisted option
add_action('wp_ajax_myplugin_save', 'myplugin_save');
function myplugin_save() {
    check_ajax_referer('myplugin_save');
    if (!current_user_can('manage_options')) {
        wp_send_json_error(null, 403);
    }
    $value = sanitize_text_field(wp_unslash($_POST['value'] ?? ''));
    update_option('myplugin_banner_text', $value);
    wp_send_json_success();
}

La version vulnérable permet à n'importe qui de modifier n'importe quelle option du site, par exemple users_can_register et default_role, ce qui suffit à s'inscrire comme administrateur. Le même schéma existe côté API REST : une route déclarée avec 'permission_callback' => '__return_true' est publique, quelle que soit la sensibilité de ce qu'elle fait.

Réduire l'exposition

1. 1.Supprimez les plugins désactivés ou inutiles : un plugin désactivé reste sur le disque, et ses fichiers restent souvent accessibles directement.
2. 2.Activez les mises à jour automatiques des extensions (disponibles depuis WordPress 5.5) au moins pour les correctifs de sécurité : face à un délai de cinq heures, une mise à jour manuelle arrive trop tard.
3. 3.Suivez les avis de sécurité de vos extensions et, pour les failles sans correctif, désactivez l'extension ou appliquez un correctif virtuel ciblé.
4. 4.Durcissez le reste : define('DISALLOW_FILE_EDIT', true) dans wp-config.php, double authentification pour les administrateurs, et aucune copie de wp-config.php laissée sur le serveur.