WordPress.org incorpora revisiones automáticas de seguridad para las nuevas versiones de plugins y temas. El sistema combina IA con Jetpack Scan y podrá frenar una actualización considerada de alto riesgo antes de distribuirla a los usuarios.
WordPress está reforzando uno de los puntos más delicados de la seguridad de su ecosistema: las actualizaciones de plugins. A partir de ahora, cada nueva versión podrá ser analizada automáticamente antes de distribuirse mediante la API de actualizaciones de WordPress.org, con el objetivo de detectar vulnerabilidades, código sospechoso o posibles puertas traseras antes de que alcancen las páginas web.
La decisión responde a un problema conocido: un plugin puede superar los controles iniciales cuando entra en el directorio oficial y convertirse posteriormente en una amenaza debido a una actualización vulnerable, una cuenta de desarrollador comprometida o la introducción deliberada de código malicioso.
El nuevo mecanismo ya habría demostrado su utilidad. WordPress asegura que sus controles detectaron una puerta trasera en la actualización de un plugin con unas 20 000 instalaciones activas, evitando que esa versión comprometida llegase a distribuirse mediante el sistema normal de actualizaciones.
WordPress cambia la seguridad de las actualizaciones de plugins
Hasta ahora existía una diferencia importante entre publicar inicialmente un plugin y actualizarlo posteriormente.
Los nuevos plugins son revisados antes de incorporarse al directorio, pero sus desarrolladores pueden continuar publicando nuevas versiones con el paso del tiempo.
David Perez, colíder del equipo del repositorio oficial de plugins, resumió el problema: un complemento que hoy es seguro puede incorporar una vulnerabilidad o código malicioso en una versión futura.
Eso convierte las actualizaciones en un objetivo especialmente atractivo.
WordPress quiere introducir ahora un control de seguridad más consistente entre el momento en que un desarrollador publica una versión y el instante en que esta empieza a llegar a las instalaciones de los usuarios.
Una puerta trasera en un plugin con 20 000 instalaciones puso a prueba el sistema
El ejemplo más contundente se produjo el 28 de julio de 2026.
Una nueva versión de un plugin que contaba con aproximadamente 20 000 instalaciones activas contenía una puerta trasera.
WordPress no ha identificado públicamente el complemento.
La actualización, sin embargo, se publicó durante el denominado período de espera o cooldown. Gracias a ese intervalo, la versión comprometida no llegó a distribuirse mediante la API de actualizaciones de WordPress.org.
Wordfence alertó al equipo de plugins y el complemento dejó de estar disponible para descargar 26 minutos después de recibirse el aviso, según la información publicada.
El episodio sirve como demostración práctica del problema que WordPress intenta resolver: unos minutos pueden separar una actualización maliciosa localizada a tiempo de su distribución masiva.
Protect The Shire introdujo una espera antes de actualizar
La nueva revisión automatizada se apoya en un cambio que WordPress comenzó a aplicar el 5 de junio de 2026.
Desde entonces, las nuevas versiones de plugins y temas pasan por un período de espera antes de distribuirse mediante las actualizaciones automáticas.
La iniciativa recibe el nombre de Protect The Shire.
Inicialmente, la espera era de 24 horas, aunque posteriormente se redujo hasta las seis horas actuales.
Puede parecer contradictorio introducir deliberadamente un retraso en un sistema de actualizaciones, especialmente cuando instalar rápidamente los parches suele ser una de las principales recomendaciones de ciberseguridad.
La finalidad aquí es diferente.
WordPress pretende evitar que una actualización recién publicada pueda propagarse inmediatamente a miles de instalaciones sin disponer de tiempo para detectar una posible manipulación o vulnerabilidad crítica.
La inteligencia artificial analizará cada nueva versión
La siguiente etapa consiste en aprovechar esas horas para analizar el código.
Durante el período de espera, WordPress.org revisará los cambios introducidos en cada versión utilizando modelos de inteligencia artificial junto con Jetpack Scan.
Los resultados de ambos mecanismos se compararán y combinarán para generar una puntuación de seguridad.
Cuanto más alta sea esa puntuación, mayor será el riesgo potencial identificado.
Las versiones que permanezcan por debajo del umbral establecido seguirán el proceso habitual y podrán comenzar a distribuirse una vez concluido el período de espera.
Pero una actualización clasificada como alto riesgo será bloqueada automáticamente.
Y esa es la principal novedad.
Una actualización peligrosa podrá quedar bloqueada automáticamente
El sistema está pensado para no depender siempre de que un miembro del equipo de plugins revise manualmente una alerta antes de detener la distribución.
Si una versión supera el nivel de riesgo definido por WordPress, la actualización quedará bloqueada automáticamente.
El desarrollador recibirá entonces un correo electrónico con los resultados de la revisión.
WordPress indica que esos mensajes solo se enviarán cuando una versión haya sido bloqueada.
El autor deberá estudiar los problemas detectados, corregirlos y publicar una nueva versión.
La nueva actualización volverá a pasar por el proceso de análisis y, si obtiene una puntuación inferior al límite de alto riesgo, podrá continuar con el período normal de espera.
Una puntuación alta no significa necesariamente que el desarrollador sea malicioso
Existe aquí una distinción fundamental.
Que WordPress bloquee una actualización no significa automáticamente que haya detectado malware deliberadamente introducido por su autor.
El sistema pretende encontrar tanto comportamientos maliciosos como vulnerabilidades incorporadas accidentalmente durante el desarrollo.
Una programación insegura puede generar una puntuación elevada sin que exista ninguna intención criminal.
Esto será especialmente importante para evitar que los bloqueos automáticos se interpreten públicamente como acusaciones contra los desarrolladores.
El sistema funciona como una barrera preventiva: detecta riesgo en el código, no determina las intenciones de quien lo escribió.
Qué código puede hacer saltar las alarmas de WordPress
WordPress ha explicado algunos de los patrones capaces de aumentar la puntuación de riesgo.
Entre ellos aparecen puntos finales REST, AJAX o admin-post que no comprueben correctamente las capacidades del usuario.
El uso de un nonce por sí solo no equivale a una autorización adecuada.
También pueden levantar sospechas las consultas a la base de datos construidas sin utilizar correctamente mecanismos como $wpdb->prepare(), destinados a reducir determinados riesgos relacionados con la manipulación de consultas.
Otros comportamientos sensibles incluyen rutas de archivos, cargas, eliminaciones o inclusiones construidas directamente a partir de datos proporcionados en una solicitud.
También se analizará con especial atención unserialize() aplicado sobre datos procedentes de solicitudes o respuestas remotas.
El código ofuscado también puede elevar el riesgo
La revisión prestará atención a comportamientos que históricamente han aparecido tanto en malware como en código potencialmente peligroso.
Entre ellos figura el código descargado o evaluado dinámicamente durante la ejecución, así como código ofuscado o empaquetado.
También pueden resultar problemáticos los complementos que permitan modificar opciones, metadatos de usuarios o configuraciones sensibles mediante puntos finales accesibles por suscriptores o visitantes sin autenticar.
Esto no significa necesariamente que cualquiera de esos elementos provoque por sí solo un bloqueo.
La plataforma combinará diferentes resultados para determinar la puntuación global de riesgo.
WordPress recomienda revisar el código antes de publicarlo
El cambio también traslada parte de la responsabilidad hacia los desarrolladores.
WordPress recomienda seguir sus estándares oficiales de programación y utilizar herramientas como PHP_CodeSniffer (PHPCS) para detectar problemas antes de publicar una nueva versión.
En el ecosistema WooCommerce, se recomienda además utilizar Quality Insights Toolkit (QIT) para realizar pruebas.
El objetivo es que la revisión automática de WordPress.org sea una última barrera y no el primer momento en el que el desarrollador descubre vulnerabilidades importantes.
¿Qué pasa si WordPress bloquea un plugin por error?
Los sistemas automatizados pueden producir falsos positivos.
WordPress contempla esta posibilidad.
Si el autor considera incorrecto alguno de los resultados, podrá contactar con el equipo de plugins para solicitar una revisión.
Pero la propia plataforma advierte de que el volumen de trabajo es elevado.
Por eso recomienda que, cuando sea posible, el desarrollador corrija el problema señalado y publique otra versión, ya que probablemente será más rápido que esperar a una revisión manual de la apelación.
La nueva versión tendrá que superar nuevamente el análisis automatizado.
Los plugins son uno de los puntos críticos de WordPress
La medida resulta especialmente importante por la arquitectura del ecosistema WordPress.
Un plugin no es simplemente un pequeño añadido visual.
Dependiendo de sus permisos y funcionamiento, puede interactuar con bases de datos, usuarios, archivos, formularios, APIs, sistemas de pago, sesiones y zonas administrativas.
Una vulnerabilidad grave en un complemento ampliamente instalado puede convertirse en una oportunidad extraordinaria para los ciberdelincuentes.
Y existe un segundo escenario todavía más peligroso: comprometer directamente la infraestructura o las credenciales utilizadas para distribuir una actualización legítima.
En ese caso, el atacante puede aprovechar la confianza que los administradores ya tienen depositada en el plugin.
Una actualización que aparentemente procede del canal correcto puede contener código que nunca estuvo en versiones anteriores.
Las actualizaciones automáticas tienen una paradoja de seguridad
WordPress intenta resolver así una paradoja difícil.
Por un lado, actualizar rápidamente es esencial para corregir vulnerabilidades.
Por otro, un mecanismo capaz de instalar automáticamente nuevas versiones en miles de páginas se convierte en un canal extraordinariamente poderoso si una actualización resulta comprometida.
Protect The Shire introduce deliberadamente un pequeño grado de fricción.
La nueva revisión automatizada intenta utilizar esas seis horas para decidir si una versión parece suficientemente segura como para continuar su distribución.
El reto será conseguir que ese control no retrase innecesariamente actualizaciones urgentes destinadas precisamente a corregir vulnerabilidades críticas.
La IA se convierte en vigilante del ecosistema WordPress
La utilización de inteligencia artificial añade otro elemento relevante.
Los modelos podrán ayudar a identificar patrones sospechosos y analizar cambios entre versiones a una escala difícil de asumir exclusivamente mediante revisiones humanas.
Pero la IA no funcionará sola.
WordPress combinará sus resultados con Jetpack Scan y utilizará la información obtenida para construir una puntuación de riesgo.
Esto también obliga a controlar cuidadosamente los falsos positivos.
Bloquear erróneamente una actualización de seguridad podría tener consecuencias, especialmente para plugins utilizados por miles o millones de páginas.
El equilibrio estará entre velocidad, precisión y prevención.
Una barrera adicional antes de que el código llegue a miles de webs
El caso de la puerta trasera detectada en julio explica por qué WordPress considera necesario el cambio.
Un plugin con unas 20 000 instalaciones activas publicó una versión comprometida.
La existencia del período de espera impidió que aquella actualización llegase a distribuirse mediante la API oficial.
Ahora WordPress pretende convertir ese margen de tiempo en un control sistemático y automatizado para todas las nuevas versiones.
No significa que WordPress vaya a convertirse en una plataforma inmune a vulnerabilidades.
Tampoco garantiza que el análisis automático detecte absolutamente todo el código malicioso.
Pero sí modifica un punto crítico del modelo de seguridad: una actualización ya no tendrá vía libre simplemente porque el plugin fuese considerado seguro cuando entró originalmente en el directorio.
Cada nueva versión tendrá que volver a demostrar que no presenta señales suficientemente graves como para detenerla.
Para los propietarios de páginas WordPress, el cambio introduce una capa adicional entre el código publicado por un desarrollador y la actualización que finalmente llega a su web.
Y para los ciberdelincuentes supone un obstáculo más en uno de los ataques más rentables de la cadena de suministro: convertir una actualización en el vehículo para entrar simultáneamente en miles de páginas.
