El 5 de junio Matt Mullenweg anunció Protect The Shire: cada release nuevo de plugin o tema en WordPress.org esperará hasta 24 horas antes de llegar a las auto-actualizaciones. Lo presentan como escudo contra ataques de cadena de suministro, con un Wapuu llamado Gandalf revisando código con IA. Suena bien en un post con referencias a Tolkien. En la práctica, si gestionas webs de clientes, te acabas de ganar un día más de ventana de exposición cada vez que un desarrollador publique un parche de seguridad.
No me opongo a desconfiar de los commits. De hecho, el propio autor del plugin RAPL lo cuenta con claridad en DEV Community: prefiere pasar por un checkpoint a confiar ciegamente en que nadie venderá su plugin a un comprador malicioso, como pasó con Essential Plugins. El problema no es la desconfianza. El problema es que WordPress ha movido la palanca de seguridad hacia el lado equivocado del equilibrio sin contarte las condiciones.
Porque la actualización manual sigue siendo instantánea. El zip nuevo ya está en el directorio. Lo que se retrasa es la tubería de auto-update y la notificación masiva. Eso crea una escena absurda: la ficha del plugin muestra la versión nueva mientras miles de paneles de administración siguen en la anterior hasta veinticuatro horas después. Si tienes diez sitios con auto-updates activados, ahora dependes de que alguien entre a pulsar «actualizar» cuando salga un CVE caliente. ¿Cuántos clientes de pyme hacen eso sin que se lo pidas tú?
Mullenweg escribe que 2026 será el año de la tensión entre «actualizar rápido para estar seguro» y «retener actualizaciones para estar seguro». Correcto. Pero la decisión ya no la tomas tú ni tu hosting: la toma el directorio de forma uniforme sobre más de 61.000 plugins. Webhosting.today lo resume bien: antes el trade-off lo negociaba cada autor y cada proveedor; ahora el default es esperar un día entero.
Y aquí es donde me pierdo con el relato oficial. Nos venden IA como ventaja defensiva —tokens y tiempo donde antes no había revisión humana posible—, pero no hay field guide de Gandalf. No sabemos qué entrena, qué falsos positivos genera ni cómo prioriza un parche urgente frente a un release de features. Hosting Advice lo señala con educación: sin detalles técnicos, estamos confiando en una caja negra que retrasa parches reales mientras promete cazar malware futuro.
En mi experiencia gestionando WordPress para terceros, la mayoría de incidentes no vienen de un autor malvado que compra un plugin popular. Vienen de sitios desactualizados porque nadie mira el panel. Patchstack lleva años diciendo que una parte importante de vulnerabilidades de alto impacto se explota en las primeras horas tras la divulgación. Esas mismas horas son las que WordPress acaba de regalar al otro bando cuando el fix legítimo queda en cola.
El argumento de Mullenweg sobre Essential Plugins y los ataques en npm o PyPI es válido como contexto. Pero copiar el modelo de «distrust by default» de GitHub sin copiar sus herramientas de transparencia deja al ecosistema en una posición incómoda. Los hosts gestionados —SiteGround, Kinsta, los de siempre— no tienen que cambiar nada en su infra, pero sí van a recibir tickets de clientes preguntando por qué «WordPress va lento» con las actualizaciones. Spoiler: no va lento; va cauteloso, y tú eres quien debe explicarlo.
Lo irónico es que esto llega justo cuando WordPress 7.0 Armstrong presume de modernizar el dashboard e integrar IA nativa en el core. Te instalan conectores de Claude y ChatGPT en el editor, pero cuando toca proteger el ecosistema de plugins la respuesta es un cronómetro fijo de 24 horas y un meme de Gandalf. No encaja del todo.
¿Hay salida? Para parches críticos, Mullenweg menciona vías para acelerar la entrega, pero no están documentadas con la misma claridad que el retraso general. Si eres agencia o freelance, toca revisar tus políticas: quizá desactivar auto-updates ciegos y montar un pipeline propio —staging, prueba, despliegue— sea más trabajo, pero al menos controlas el trade-off. Confiar en que Gandalf acorte el plazo «a minutos» en un futuro próximo me suena a promesa de roadmap, no a SLA.
Protect The Shire protege contra el escenario del plugin comprado por un villano. Eso es raro pero catastrófico. Lo cotidiano es otro: sitios expuestos porque el parche bueno tardó un día en bajar por la tubería automática. WordPress ha elegido protegerse de un ataque espectacular asumiendo el coste de miles de ventanas pequeñas. Me parece una apuesta razonable desde la org, pero carísima para quien factura mantenimiento y responde ante un cliente hackeado.
Si mañana tu plugin de caché publica un fix para una fallo que permite escalada de privilegios, y tu cliente tiene auto-updates activadas en producción sin staging, prefieres que el parche llegue en cinco minutos o que espere veinticuatro horas mientras Gandalf lo revisa?