WordPress revisará cada actualización de plugin con IA antes de distribuirla
El repositorio oficial bloquea de forma automática las versiones que superen un umbral de riesgo. El sistema ya frenó una puerta trasera en un plugin con 20.000 instalaciones activas.
Los plugins de WordPress pasarán por una revisión de seguridad automatizada antes de llegar a la API de actualizaciones de WordPress.org. El repositorio oficial ha empezado a analizar cada versión nueva en busca de vulnerabilidades y código malicioso, y bloquea sin intervención humana las que superan un umbral de riesgo. El equipo de plugins lo explica en el anuncio del cambio.
El movimiento cubre un hueco conocido: los plugins se revisan al entrar en el directorio, pero después las actualizaciones salían sin más filtro. "Un plugin puede ser seguro hoy e introducir una vulnerabilidad, o código malicioso, en una versión futura", dice David Perez, co-líder del equipo del repositorio oficial de plugins. Sin ese paso intermedio entre el commit y la distribución a los usuarios, la puerta quedaba abierta.
El caso que precipitó el cambio
El 28 de julio de 2026 el sistema detectó una puerta trasera introducida en una versión de un plugin con unas 20.000 instalaciones activas. La versión comprometida no llegó a distribuirse porque cayó dentro de la ventana de espera. Wordfence alertó al equipo y el plugin se cerró a descargas 26 minutos después. WordPress no ha desvelado de qué plugin se trata.
Esa ventana de espera forma parte de Protect The Shire, en marcha desde el 5 de junio de 2026: todo plugin y tema pasa por un periodo de enfriamiento antes de distribuirse por auto-updates. Ahora son seis horas, cuando la iniciativa arrancó con 24. La idea es meter fricción para que una actualización maliciosa no llegue a los usuarios al instante.
Durante ese periodo, los cambios de cada versión se analizan con modelos de IA en WordPress.org junto a Jetpack Scan. Los resultados se contrastan y se combinan en una puntuación de seguridad: más alta, más riesgo. Por encima del umbral, la versión se bloquea sola al terminar la revisión; por debajo, sigue el proceso normal. Los autores reciben un correo, pero solo cuando se les ha bloqueado algo. Una puntuación alta no implica mala fe: también cuenta fallos introducidos sin querer.
Qué mira el análisis
Perez afirma que la revisión "busca las mismas clases de vulnerabilidad que cualquier auditoría de seguridad", y recomienda pasar las normas de codificación de WordPress y PHPCS. Entre los patrones que disparan la puntuación: endpoints REST, AJAX o admin-post sin comprobación de capacidades —un nonce no es autorización—, consultas sin $wpdb->prepare(), rutas, subidas, borrados o includes construidos con datos de la petición, unserialize() sobre datos de entrada o respuestas remotas, opciones o metadatos escritos desde endpoints alcanzables por suscriptores, y código evaluado en tiempo de ejecución u ofuscado.
Para levantar el bloqueo hay un solo camino: revisar los hallazgos, corregir y publicar una versión nueva. Si vuelve a puntuar por debajo del umbral, sigue el cooldown normal. Si el hallazgo parece erróneo se puede reclamar, aunque Perez avisa de que publicar la corrección es casi siempre más rápido que esperar una revisión manual.
El repositorio mueve decenas de miles de plugins y buena parte de los sitios del mundo tira de auto-updates, así que el escáner automático cambia la rutina de quien publica: conviene limpiar los avisos de PHPCS antes de etiquetar una versión, porque ahora una puntuación alta corta la distribución sin que nadie del equipo de plugins tenga que mirarla. Para quien administra sitios, la decisión de fondo sigue siendo la misma de siempre: qué actualizaciones deja en automático y cuáles revisa antes.
