WordPress implementará revisiones de seguridad automatizadas mediante IA para cada actualización de plugins y temas antes de su distribución. El sistema asignará un puntaje de riesgo y bloqueará automáticamente aquellas versiones que presenten vulnerabilidades o código malicioso. Los desarrolladores deberán corregir los fallos detectados para que sus actualizaciones puedan ser publicadas.

WordPress ha anunciado que está lanzando una revisión de seguridad automatizada para cada versión de un plugin antes de que se distribuya a través de la API de actualizaciones de WordPress.org, con el fin de analizar posibles problemas de seguridad y garantizar que no haya riesgos involucrados.

"Los plugins nuevos se revisan antes de entrar en el directorio, pero las actualizaciones se envían continuamente después de eso", afirmó David Perez, colíder del Equipo del Repositorio Oficial de Plugins de WordPress aquí. "Un plugin puede ser seguro hoy e introducir una vulnerabilidad o código malicioso en una versión futura".

WordPress señaló que la falta de un "paso de revisión constante" entre el commit de una versión y la entrega del plugin a los usuarios finales significaba que podía abrir la puerta a ataques maliciosos.

La plataforma de gestión de contenidos (CMS) destacó que su revisión automatizada detectó una puerta trasera (backdoor) en la versión de un plugin con unos 20.000 instalaciones activas el 28 de julio de 2026. Debido a que la versión estaba dentro de una ventana de enfriamiento, la versión comprometida del plugin nunca llegó a distribuirse a través de la API de actualizaciones de WordPress.org.

El plugin fue cerrado para descargas 26 minutos después de que el Equipo de Plugins fuera alertado sobre la actualización por la empresa de seguridad de WordPress, Wordfence. WordPress no reveló el nombre del plugin.

El periodo de enfriamiento

Desde el 5 de junio de 2026, cada plugin y tema de WordPress pasa por un periodo de enfriamiento aquí antes de ser distribuido mediante actualizaciones automáticas como parte de una nueva iniciativa de seguridad llamada Protect The Shire. La idea es introducir cierta fricción en el proceso para que las actualizaciones maliciosas no lleguen a los usuarios finales inmediatamente. El periodo de enfriamiento es actualmente de 6 horas, reducido de las 24 horas introducidas en aquel entonces.

El último esfuerzo pretende cerrar otra brecha de seguridad crítica: una puntuación de riesgo alta para la versión de un plugin o tema debería detener automáticamente la distribución sin la intervención del Equipo de Plugins. Todo el proceso sigue estos pasos:

* Durante el periodo de enfriamiento, los cambios en cada versión son analizados en WordPress.org por modelos de inteligencia artificial (IA) junto con Jetpack Scan.
* Los resultados se verifican y combinan en una puntuación de seguridad: una puntuación más alta se traduce en un riesgo potencialmente mayor.
* Las versiones con una puntuación de riesgo alta se bloquean automáticamente una vez finalizada la revisión, mientras que las que estén por debajo de ese umbral continuarán el proceso normal.
* Los responsables del commit del plugin reciben un correo electrónico con los hallazgos. Los correos solo se envían en escenarios donde un plugin es bloqueado.

Dicho esto, cabe señalar que una puntuación de riesgo alta no indica necesariamente una intención maliciosa, ya que la puntuación también tiene en cuenta fallos de seguridad introducidos inadvertidamente, al igual que marca el malware intencional.

En un comentario posterior, Perez explicó que la revisión de seguridad "busca las mismas clases de vulnerabilidades que cualquier auditoría de seguridad", instando a los desarrolladores a seguir los Estándares de Codificación de WordPress aquí y las reglas de PHP_CodeSniffer (PHPCS aquí) para validar su código y asegurar la calidad. A los desarrolladores que publican extensiones de WooCommerce se les recomienda utilizar la plataforma de pruebas Quality Insights Toolkit (QIT aquí).

Otros patrones que también podrían elevar la puntuación de riesgo son los siguientes:

* Endpoints de REST, AJAX o admin-post sin una comprobación de capacidad (un nonce por sí solo no es autorización).
* Consultas creadas sin $wpdb->prepare().
* Rutas de archivos, cargas, eliminaciones o inclusiones creadas a partir de datos de solicitud.
* unserialize() en datos de solicitud o en una respuesta remota.
* Opciones, meta de usuario o ajustes escritos desde endpoints accesibles por suscriptores o usuarios no autenticados.
* Código obtenido o evaluado en tiempo de ejecución, y código ofuscado o empaquetado.

Cómo solucionar un bloqueo

Una vez que una versión es bloqueada, la única forma de que tú, como desarrollador, consigas que se eliminen las restricciones es revisar los hallazgos, solucionar los problemas y publicar una nueva versión. Si la nueva versión obtiene una puntuación inferior al umbral de riesgo alto, continuará a través del proceso normal de enfriamiento.

"Si un hallazgo parece incorrecto, los autores pueden contactar con el Equipo de Plugins", dijo Perez. "Por favor, comprende que el equipo gestiona un alto volumen de revisiones, por lo que publicar una versión corregida es casi siempre más rápido que esperar una revisión manual de una apelación".

Fuente:
THN