Contexte et mise en place

Depuis le 5 juin 2026, WordPress applique une période de cool‑down de six heures à chaque plugin et thème avant leur diffusion via l’API de mise à jour. Cette mesure, nommée Protect The Shire, vise à combler l’absence d’étape de validation entre le commit d’une version et sa mise à disposition aux utilisateurs finaux. Le dispositif a déjà permis d’intercepter un backdoor introduit le 28 juillet 2026 dans un plugin comptant environ 20 000 installations actives, évitant ainsi sa diffusion.

Mécanisme d’analyse automatisée

Durant la fenêtre de six heures, chaque version est soumise à une combinaison d’modèles d’intelligence artificielle et de l’outil Jetpack Scan. Les IA examinent le code source à la recherche de patterns connus, tandis que Jetpack fournit une analyse de vulnérabilités classiques. Les deux résultats sont agrégés pour produire un score de sécurité ; plus le score est élevé, plus le risque est jugé important.

Évaluation du risque et blocage

Le score est comparé à un seuil défini par l’équipe des plugins. Si le seuil est dépassé, la version est bloquée automatiquement et ne transite pas vers l’API de mise à jour. Les auteurs reçoivent alors un courriel détaillant les constats. Parmi les critères qui font grimper le score, on retrouve : l’absence de vérification de capacités sur les points d’entrée REST/AJAX, l’usage de requêtes SQL sans $wpdb->prepare(), la construction de chemins de fichiers à partir de données externes, l’appel à unserialize() sur des entrées non fiables, la manipulation d’options ou de métadonnées depuis des utilisateurs non authentifiés, ainsi que l’exécution de code récupéré dynamiquement ou obfusqué.

Implications et limites

Cette chaîne automatisée réduit le temps d’exposition d’une version malveillante de plusieurs heures à quelques minutes, comme le montre le cas du plugin bloqué 26 minutes après alerte de Wordfence. Cependant, le score élevé ne signifie pas toujours une intention malveillante ; il peut refléter une mauvaise pratique de codage qui introduit une faille involontaire. Le processus repose donc sur la capacité des développeurs à corriger rapidement les rapports et à republier une version conforme. L’absence de transparence sur le nom du plugin concerné limite l’évaluation indépendante de l’efficacité du système. Enfin, la dépendance à des modèles IA implique un risque de faux positifs ou de faux négatifs, surtout pour des constructions de code inédites qui échappent aux signatures connues.