El equipo de WordPress anunció el lanzamiento de una comprobación de seguridad automatizada para cada actualización de plugins antes de su distribución a través de la API de WordPress.org. El sistema utiliza modelos de IA y Jetpack Scan para analizar los cambios en el código, asigna al lanzamiento una puntuación de riesgo y bloquea automáticamente la distribución de las actualizaciones con puntuaciones altas, sin intervención del equipo de moderadores. La novedad afecta a todos los desarrolladores de plugins y temas de WordPress, así como a los administradores de sitios que utilizan actualizaciones automáticas desde el panel de control de WordPress.
Problema: actualizaciones sin control
Hasta ahora, los nuevos plugins pasaban una revisión manual antes de ser añadidos al directorio de WordPress.org; sin embargo, las actualizaciones posteriores se publicaban sin ningún tipo de auditoría sistemática. Como explicó David Pérez, uno de los responsables del repositorio oficial de plugins: «Un plugin puede ser seguro hoy, pero en la siguiente versión puede aparecer una vulnerabilidad o código malicioso». La ausencia de una etapa intermedia de revisión entre el commit de la actualización y su entrega a millones de sitios creaba una ventana para ataques a través de la cadena de suministro.
El problema no es teórico. Según WordPress, el 28 de julio de 2026 el sistema automático detectó un backdoor en la actualización de un plugin no identificado con unas 20 000 instalaciones activas. La versión comprometida no se distribuyó a través de la API de WordPress.org, ya que aún se encontraba dentro del periodo de espera (cooldown). El plugin se cerró para nuevas descargas 26 minutos después de que la empresa Wordfence notificara al equipo de WordPress. Cabe señalar que WordPress no reveló el nombre del plugin y no se ha encontrado ninguna confirmación independiente de este incidente en fuentes abiertas.
Cómo funciona el nuevo sistema
Desde el 5 de junio de 2026, todos los plugins y temas de WordPress pasan por un periodo de espera obligatorio antes de su distribución a través de la API de actualizaciones; esto forma parte de la iniciativa Protect The Shire. Inicialmente, la demora era de hasta 24 horas, pero posteriormente se redujo a las seis horas actuales. La nueva comprobación automática se integra precisamente en esta ventana temporal y funciona del siguiente modo:
- Durante el periodo de espera, los cambios de cada lanzamiento se analizan con varios modelos de IA conjuntamente con Jetpack Scan.
- Los resultados se verifican de forma cruzada y se combinan en una puntuación de seguridad final: cuanto más alta es la puntuación, mayor es el riesgo potencial.
- Los lanzamientos con una puntuación de riesgo alta se bloquean automáticamente una vez finalizada la comprobación. Las actualizaciones por debajo del umbral siguen el proceso estándar de publicación.
- Los desarrolladores reciben un correo electrónico con los resultados de la comprobación solo en caso de que el lanzamiento sea bloqueado.
Una salvedad importante: una puntuación de riesgo alta no significa necesariamente que exista código malicioso. WordPress indica explícitamente que una vulnerabilidad introducida por accidente puede recibir una puntuación tan alta como un backdoor insertado de forma intencionada. El sistema mide el riesgo, no la intención.
Patrones de código que aumentan la puntuación de riesgo
WordPress ha publicado una lista concreta de patrones a los que reacciona el sistema:
- endpoints REST, AJAX y admin-post sin comprobación de permisos de acceso (un nonce por sí solo no constituye autorización);
- consultas SQL construidas sin
$wpdb->prepare(); - operaciones con archivos (rutas, cargas, eliminaciones, inclusiones) basadas en datos de la petición;
- llamadas a
unserialize()sobre datos procedentes de peticiones o respuestas remotas; - escritura en opciones, metadatos de usuarios o ajustes desde endpoints accesibles para suscriptores o usuarios no autenticados;
- carga y ejecución de código en tiempo de ejecución, código ofuscado o empaquetado.
Se recomienda a los desarrolladores revisar su código con WordPress Coding Standards y PHP_CodeSniffer. A los autores de extensiones para WooCommerce se les propone utilizar la plataforma Quality Insights Toolkit.
Qué hacer si se bloquea un lanzamiento
La única forma de levantar el bloqueo es corregir los problemas detectados y publicar una nueva versión. Si el lanzamiento actualizado obtiene una puntuación por debajo del umbral de bloqueo, pasará por el proceso estándar con un periodo de espera de seis horas. Los desarrolladores pueden apelar el resultado poniéndose en contacto con el equipo de Plugins Team; sin embargo, como señala Pérez, publicar una versión corregida casi siempre es más rápido que esperar a la revisión manual de la apelación.
Evaluación del impacto
La novedad afecta a todo el ecosistema de WordPress.org: cada plugin y cada tema distribuidos a través de la API oficial de actualizaciones, incluidas las actualizaciones con un solo clic desde el panel de control. Para los desarrolladores, esto significa la necesidad de adherirse de forma más estricta a los estándares de codificación: incluso errores de seguridad no intencionados pueden desembocar en el bloqueo del lanzamiento y retrasar la entrega de las actualizaciones a los usuarios.
Al mismo tiempo, el sistema solo cubre el canal de distribución de WordPress.org. Los plugins instalados desde fuentes de terceros o actualizados mediante mecanismos propios de los desarrolladores no están sujetos a esta comprobación. Anteriormente ya hemos escrito sobre vulnerabilidades en plugins de WordPress, y el nuevo sistema está orientado precisamente a evitar situaciones similares en la etapa de distribución.
La comprobación automática de seguridad es una evolución lógica de la iniciativa Protect The Shire, que construye de forma gradual una protección multinivel de la cadena de suministro de WordPress. Los administradores de sitios en WordPress no necesitan realizar acciones adicionales: el sistema funciona del lado de WordPress.org. Los desarrolladores de plugins deberían pasar ya su código por WordPress Coding Standards y PHP_CodeSniffer para que el próximo lanzamiento no quede bloqueado por patrones que el sistema pueda considerar de riesgo.
