Le 5 juin 2026, Matt Mullenweg a publié « Protect The Shire » sur le blog d’actualités WordPress.org. Il y annonce que chaque nouvelle version des plugins dans le répertoire officiel attendra un délai de 24 heures avant d’être distribuée via une mise à jour automatique. Ce changement représente un changement d’approche majeur pour la fondation WordPress. Celle-ci diminuera la priorité accordée à la vitesse de distribution, afin de laisser une place accrue à la sécurité.
Cette modification s’appliquera désormais par défaut aux plus de 61 000 plugins hébergés dans le répertoire. Le résumé de la publication fait aussi référence aux mises à jour de thèmes. Ceux-ci seraient bientôt soumis au même encadrement.
L’infrastructure d’application du délai pour les mises à jour est en service depuis le 11 août 2025. Les auteurs de plugins de fonctionnalités optionnelles pouvaient déjà l’activer sur des versions individuelles. WordPress conservera donc le même mécanisme de livraison. Il inversera toutefois la valeur par défaut. Le délai s’appliquera désormais pour chaque mise à jour de plugins.
Mullenweg a présenté cette décision comme une réponse au risque de la chaîne d’approvisionnement accéléré par l’IA. Il pointe du doigt la porte dérobée des Essential Plugins en avril et Mythos d’Anthropic comme catalyseurs.
Le rapport de sécurité 2026 de Patchstack révèle qu’environ la moitié des vulnérabilités WordPress à fort impact sont exploitées dans les 24 heures. Le tampon de sécurité retarde toutefois aussi les correctifs de sécurité légitimes. Voyons donc un peu plus en détails les conséquences de cette annonce.
L’infrastructure était déjà en place. C’est le paramètre par défaut qui vient de changer.
La fonctionnalité de publication progressive des plugins est en production depuis dix mois. Le co-créateur de WordPress, Matt Mullenweg l’a d’abord proposée en juin 2025. Il a été mis en ligne le 11 août 2025 dans Release Confirmations, la fonctionnalité de publication contrôlée existante pour les auteurs de plugins.
Un auteur de plugin qui voulait retarder les mises à jour automatiques pouvait donc choisir l’option au moment de la publication. Les sites utilisant WordPress 6.6 ou supérieur recevaient alors l’instruction d’attendre. On ne pouvait toutefois pas dire aux sites plus anciens de patienter.
L’annonce du 5 juin retire l’aspect optionnel. Chaque nouvelle version de plugins attendra désormais un délai de 24 heures avant que WordPress.org n’ordonne aux sites d’appliquer la mise à jour automatique.
Mullenweg a signalé que la fenêtre de 24 heures pourrait se réduire à quelques minutes. Cela se fera « au fur et à mesure de l’évolution du processus ». Le projet restera toutefois prudent tant que les capacités d’IA progresseront. Les mises à jour manuelles du tableau de bord du site resteront, pour leur part, immédiates.
La distinction est importante pour les auteurs de plugins qui se sont appuyés sur la distribution instantanée. Un correctif de sécurité poussé dans le répertoire n’atteindra pas le site WordPress moyen par mises à jour automatiques avant le lendemain. Ce délai peut sembler court, mais il pourrait s’avérer crucial dans certains cas.
Les administrateurs qui exécutent une surveillance indépendante des vulnérabilités pourront néanmoins encore appliquer des mises à jour en quelques minutes.
Le délai par défaut affecte les sites qui s’appuient sur la cadence de distribution de WordPress.org pour planifier leur propre fenêtre de mise à jour. Cela représente la majorité de la base installée.
L’accélération de l’IA a poussé l’adoption de ce délai aux mises à jour des plugins WordPress
La publication “Protect the Shire” (Protéger le comté) est explicite quant à sa raison d’être. Trois événements survenus au cours des sept mois précédents ont changé la lecture du risque faite par Mullenweg. On compte tout d’abord le « changement radical dans la capacité de codage » de décembre 2025, et la révélation le 7 avril 2026 du Claude Mythos Preview d’Anthropic. À ceux-ci s’ajoute une série d’incidents dans la chaîne d’approvisionnement qui ont transformé la capacité de l’IA en avantage pour l’attaquant.
Mythos est ici la référence centrale. Anthropic l’a retiré de la diffusion publique parce que des tests internes ont montré qu’il pouvait développer des exploits de travail dans 72,4 % des tentatives. Ce total diffère grandement de la base proche de zéro pour les modèles Claude précédents.
Il a identifié des milliers de vulnérabilités auparavant inconnues dans tous les principaux systèmes d’exploitation et navigateurs web. De nombreux systèmes essentiels comme cPanel, WHM, Linux, Apache, et même HTTP/2 ont ainsi dû appliquer des correctifs de sécurité de toute urgence pour combler les failles exposées.
Les incidents pourrait se multiplier avec la démocratisation de l’IA
Le modèle a été distribué à environ 40 organisations par l’intermédiaire du projet Glasswing. Il s’agit d’un consortium sur invitation seulement qui comprend notamment Amazon Web Services, Microsoft, Google, Cisco et la fondation Linux.
Les défenseurs à l’intérieur de Glasswing ont ainsi obtenu le modèle. Le public n’y a toutefois pas encore droit. L’hypothèse proposée par Mullenweg dans la publication est que l’écart d’accès se réduira avec le temps et que les agents d’IA capables de lire le code source à grande échelle seront disponibles pour les attaquants tout comme pour les défenseurs.
Les récents incidents de la chaîne d’approvisionnement ont rendu le risque abstrait concret. La porte dérobée des Essential Plugins, dormante pendant huit mois dans 31 plugins à partir d’un seul compte, a été activée le 6 avril 2026. Le malfaiteur derrière cette attaque a ainsi pu compromettre plus de 20 000 sites.
La même semaine, l’infrastructure de mise à jour de Smart Slider 3 Pro a été compromise. Une version mal gérée 3.5.1.35 a alors atteint le canal de mise à jour pendant environ six heures avant d’être détectée.
Mullenweg a fait référence à l’incident de Essential Plugins dans la publication. Il a aussi noté des attaques plus larges de la chaîne d’approvisionnement sur npm, PyPI, GitHub et RubyGems. Le schéma de celles est cohérent : une version contenant un code malveillant peut atteindre des millions de sites au cours du temps qu’il faut à un évaluateur pour la remarquer.
Une équipe de révision de plugins qui ne dort jamais
L’équipe de révision des plugins humains de WordPress.org gère une charge de travail qui évolue avec le répertoire, et non avec l’horaire de l’équipe. L’équipe de mise à jour des plugins signale, en date du 1er juin 2026, 605 soumissions de plugins pour la période précédente. 558 ont été approuvées, 201 rejetées et une file d’attente de 4 740 éléments, dont 4 170 en attente depuis plus de sept jours.
La boîte de réception du support enregistre 1 940 conversations et une moyenne quotidienne de 242 messages. Mullenweg décrit l’équipe comme « surhumaine » dans la publication. Le calcul demeure néanmoins assez simple : le commit d’un plugin existant ne déclenche aucun examen de sécurité automatisé. Mullenweg note plus de 3 000 commits dans le dépôt du plugin en une seule journée. Le risque est donc bel et bien réel.
24 heures suffisent pour une analyse assistée par l’IA
Le délai de récupération de 24 heures est le tampon qui rend possible une revue systématique assistée par l’IA sans ralentir la vitesse du développeur à un crawl. Le travail de révision a un nom dans la publication : Gandalf, un nouveau Wapuu (la famille de personnages de WordPress).
La publication n’identifie pas de modèle ou de fournisseur d’IA spécifique. Il décrit le rôle : l’analyse de sécurité pilotée par robot de chaque version de plugin avant qu’elle n’atteigne les mises à jour automatiques. La fenêtre de 24 heures correspond au délai nécessaire à l’exécution de la révision automatisée. Cette fenêtre diminue lorsque l’outillage arrive à maturité.
Le raisonnement de Mullenweg est symétrique : l’IA accélère l’attaquant, donc la défense doit utiliser l’IA pour suivre. Les chiffres de la charge de travail de l’équipe expliquent pourquoi l’examen humain seul ne peut pas absorber l’augmentation du rythme des attaques.
La mise en mémoire tampon de chaque version pour un passage automatisé est le chemin que WordPress.org a choisi ; les alternatives nécessiteraient soit d’élargir l’équipe de révision, soit de restreindre qui peut publier.
L’impact du délai du délai des mises à jour pour les hébergeurs WordPress gérés
Pour les fournisseurs d’hébergement qui exécutent des pipelines de mise à jour automatique, le délai par défaut de 24 heures déplace ce qui était auparavant une politique opérationnelle propre à l’hôte vers une norme au niveau de la plateforme.
Plusieurs hôtes gérés introduisent déjà des retards par le biais de processus de révision interne ou de préproduction (WP Engine révise les versions avant de pousser ; Pressable et Kinsta proposent une préproduction intégrée).
Pour ces hébergeurs, le délai imposé par WordPress.org à la mise à jour des plugins est conforme à la pratique existante et le nouveau paramètre par défaut est invisible pour les clients. Pour les hôtes qui transmettent des mises à jour automatiques avec une mise en place minimale,
Le délai de mise à jour des plugins WordPress lié à un récent incident
le nouveau paramètre par défaut ferme l’exposition multi-locataires que l’incident Essential Plugins a démontrée : les hôtes qui ont poussé les mises à jour automatiques entre août 2025 et avril 2026 ont distribué la porte dérobée sur l’ensemble de leur flotte WordPress sans que le répertoire ait l’occasion de la signaler.
Le délai est la différence entre la distribution d’une version compromise à des milliers de clients en quelques minutes et sa distribution après un jour, période pendant laquelle le répertoire a eu le temps de signaler la version et de l’extraire.
Ce n’est pas un substitut à la révision côté hôte, à l’analyse de logiciels malveillants ou aux environnements de préproduction. C’est une base que les clients d’hébergement reçoivent désormais par défaut, sans aucune action côté hôte.
Le commerce fonctionne dans l’autre sens pour les correctifs légitimes. Un correctif de sécurité poussé par un auteur de plugin responsable attend désormais 24 heures avant d’atteindre le site hébergé via des mises à jour automatiques. Les hôtes qui exécutent leur propre surveillance des vulnérabilités peuvent détecter le correctif, le valider et l’appliquer manuellement en quelques minutes.
Les hôtes qui dépendent de la cadence de distribution de WordPress.org verront leurs correctifs arriver un jour plus tard qu’auparavant. Pour un hébergement partagé où l’hôte ne maintient pas de workflow de mise à jour au-delà de ce que WordPress.org distribue, le client voit directement le retard. Les principaux hébergeurs WordPress gérés n’avaient pas fait de déclarations publiques sur Protect The Shire à ce jour.
Le compromis entre la vitesse et la sécurité reconnu par Mullenweg
Le délai de 24 heures pour chaque mise à jour se heurte directement à la vitesse d’exploitation des plugins WordPress. Le rapport 2026 sur l’état de la sécurité WordPress de Patchstack révèle qu’environ la moitié des vulnérabilités à fort impact de WordPress sont exploitées en 24 heures. Le délai médian pondéré est de cinq heures avant le premier exploit.
Ce délai de récupération par défaut signifie donc que pour la moitié des divulgations à fort impact, le correctif atteint les mises à jour automatiques environ au même moment où l’exploit commence à être analysé. Le délai qui protège contre une publication malveillante est toutefois le même qui retarde aussi une publication défensive.
Mullenweg a reconnu cela directement. La publication définit 2026 comme « une année de tension entre deux approches : mettre à jour aussi rapidement que possible pour rester en sécurité, et retarder la mise à jour pour rester en sécurité. »
WordPress.org choisit la sécurité en imposant ce délai aux mises à jour automatiques des plugins
Le répertoire choisit donc la deuxième approche comme option par défaut. Il parie ainsi que l’examen automatisé compressera le temps de recharge au fil du temps. La compression dépend de la rapidité avec laquelle l’examen de sécurité assisté par IA mûrit et de la fiabilité avec laquelle il détecte les types de compromis subtils utilisés par la porte dérobée des plugins essentiels. Aucun des deux facteurs n’a encore de calendrier clair.
Pour l’industrie de l’hébergement, la question pratique est de savoir qui gère l’équilibre entre sécurité contre vitesse. Avant le 5 juin, cette décision était prise par chaque auteur de plugin (par défaut : distribuer immédiatement) et chaque hébergeur (par défaut : transmettre).
Le répertoire prendra désormais la décision par défaut de manière uniforme à travers plus de 61 000 plugins. WordPress.org prévoit toutefois adaptée une approche adaptée à différentes catégories de plugins. Le filtre sera plus rapide pour les plugins de confiance, plus lent pour les catégories à haut risque, et immédiat pour les correctifs de sécurité vérifiés. La position par défaut de la plateforme est néanmoins d’appliquer un délai de 24 heures.
Qui peut activer ou désactiver le délai pour les mises à jour des plugins?
Protect the Shire est une décision technique défendable. La façon dont la décision a été prise est cohérente avec un schéma d’actions unilatérales de WordPress.org au cours des 18 derniers mois. En avril 2026, Mullenweg a qualifié la sortie récente de WordPress de « merde ennuyeuse ou médiocre » dans les comités principaux de Slack . Il a aussi annulé un retour soutenu par un comité sur l’inclusion d’Akismet dans l’écran des connecteurs WordPress 7.0.
En 2024, il a proposé des frais de redevance sur certains opérateurs WordPress commerciaux. Mullenweg a alors lancé une attaque au WordCamp US contre WP Engine. Cet affrontement fait maintenant l’objet d’un litige devant un tribunal fédéral américain.
Une motion demandant la dissolution de la Fondation a d’ailleurs été déposée par WP Engine au début de 2026. Une audience fixée au 25 juin, pose la question sous-jacente. La marque WordPress et l’infrastructure WordPress.org doivent-elles rester sous le contrôle de facto d’un seul PDG ? La décision de la cour dans cette affaire aura un impact majeur sur la communauté WordPress.
Le délai de récupération de 24 heures n’a pas été appliqué en accord avec la communauté. Un article de blog du 5 juin a simplement annoncé un nouveau paramètre par défaut sous lequel tous les auteurs de plugins du répertoire opèrent désormais. Il s’agit donc encore une fois d’une décision unilatérale de Mullenweg et Automattic.
Pour conclure sur le délai appliqué par WordPress aux mises à jour automatiques des plugins
La décision du répertoire WordPress d’appliquer un délai de 24 heures avant les mises à jour des plugins vise à augmenter la sécurité du CMS. Elle soulève toutefois certaines inquiétudes et de nombreuses critiques au sein de la communauté.
Le délai devrait ralentir la distribution de mises à jour vulnérables ou compromises. Il risque toutefois de ralentir également la distribution des correctifs de sécurité visant à combler les failles connues. Son effet sur la sécurité des sites WordPress pourraient donc être à double tranchant.
Il faut aussi noter que la communauté WordPress n’a pas été consulté avant le changement. La décision provient unilatéralement de Mullenweg et Automattic. De nombreux acteurs de la communauté y voient donc une autre dérive autoritaire du co-créateur de WordPress.
Cette nouvelle annonce soulève ainsi de nouveaux débats à propos de la gouvernance de la fondation et de la communauté WordPress. Elle vient justifier, aux yeux de certains, la demande de WP Engine de dissoudre la fondation WordPress. Cette requête devrait être entendu par un tribunal américain dans quelques semaines.
Nous espérons que cet article vous a plus et vous a éclairé sur le délai imposé par le répertoire WordPress pour chaque mise à jour automatique de plugins. Si c’est le cas, nous vous invitons à consulter nos autres articles et comparatifs de notre blog. Vous y trouverez les informations les plus récentes sur l’industrie l’hébergement et sur la création de sites web.
