WordPress bloque les mises à jour à risque

Ce qui se passe

David Perez, co-responsable de l'équipe du répertoire officiel des plugins, pose le problème en une phrase : « Les nouveaux plugins sont examinés avant d'entrer dans le répertoire, mais les mises à jour partent ensuite en continu. » Autrement dit, un plugin sûr à son entrée pouvait introduire une vulnérabilité, ou du code malveillant, à n'importe quelle version suivante — sans qu'aucune étape de revue ne s'intercale entre le commit et la distribution.

Depuis le 9 septembre 2026, chaque publication passe par une revue de sécurité automatisée avant d'être servie par l'API de mise à jour de WordPress.org.

Comment la chaîne fonctionne

Elle s'appuie sur un dispositif déjà en place : depuis le 5 juin 2026, l'initiative Protect The Shire impose à tout plugin et tout thème une période de refroidissement avant diffusion par les mises à jour automatiques — actuellement six heures, contre 24 à son introduction.

Pendant ce délai, les modifications de la version sont analysées par des modèles d'IA et par Jetpack Scan ;
les résultats sont recoupés puis combinés en un score de risque — plus il est haut, plus le risque est jugé élevé ;
au-dessus du seuil, la distribution est bloquée automatiquement, sans intervention de l'équipe ; en dessous, la publication suit son cours ;
l'auteur reçoit un courriel détaillant les constats — uniquement en cas de blocage.

Le dispositif a déjà servi : le 28 juillet 2026, il a détecté une porte dérobée dans la version d'un plugin totalisant environ 20 000 installations actives. La publication étant dans sa fenêtre de refroidissement, la version compromise n'a jamais atteint les sites. Le plugin a été fermé au téléchargement 26 minutes après l'alerte remontée par Wordfence. WordPress n'a pas communiqué son nom.

Ce que ça change si vous publiez

Le score cherche, dit Perez, « les mêmes classes de vulnérabilités que n'importe quel audit de sécurité ». Les motifs qui le font monter forment une checklist directement utilisable :

endpoints REST, AJAX ou admin-post sans contrôle de capacité — un nonce seul n'est pas une autorisation ;
requêtes construites sans $wpdb->prepare() ;
chemins de fichiers, envois, suppressions ou inclusions bâtis à partir de données de requête ;
unserialize() sur des données de requête ou sur une réponse distante ;
options, métadonnées utilisateur ou réglages écrits depuis un endpoint accessible aux abonnés ou aux visiteurs non authentifiés ;
code récupéré ou évalué à l'exécution, code obfusqué ou empaqueté.

Un score élevé ne signifie pas une intention malveillante : il attrape aussi bien la faute involontaire que le code hostile. Mais le recours est le même — corriger et publier une nouvelle version. Contester auprès de l'équipe reste possible et, de l'aveu de Perez, presque toujours plus lent.

Les outils recommandés côté auteur : les WordPress Coding Standards avec PHP_CodeSniffer, et le Quality Insights Toolkit (QIT) pour les extensions WooCommerce.

À retenir

Le modèle qui se met en place — délai de refroidissement, analyse automatique, blocage sur score — vaut bien au-delà de WordPress. C'est la réponse logique aux attaques par mise à jour piégée, dont l'écosystème npm et les registres de paquets font régulièrement les frais. Pour un auteur de plugins, le changement concret est qu'un défaut d'autorisation ne coûte plus une mauvaise note dans un audit : il coûte une publication bloquée.