WordPress ha anunciado la puesta en marcha de 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. El objetivo es analizar posibles problemas de seguridad y garantizar que no existan riesgos.
David Perez, codirector del equipo oficial de plugins de WordPress, explicó que los nuevos plugins se revisan antes de entrar en el directorio, pero las actualizaciones se publican de forma continua después. 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 consistente entre la confirmación de una versión y su distribución a los usuarios podía abrir la puerta a ataques maliciosos.
La plataforma de gestión de contenidos indicó que su revisión automatizada detectó una puerta trasera introducida en una versión de un plugin con alrededor de 20.000 instalaciones activas el 28 de julio de 2026. Dado que la versión se encontraba dentro de una ventana de enfriamiento, la versión comprometida 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 por la empresa de seguridad WordPress Wordfence. WordPress no reveló el nombre del plugin.
Desde el 5 de junio de 2026, todos los plugins y temas de WordPress pasan por un período de enfriamiento antes de distribuirse 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 inmediatamente a los usuarios finales. El período de enfriamiento actual es de 6 horas, reducido desde las 24 horas introducidas inicialmente.
El último esfuerzo pretende cerrar otra brecha de seguridad crítica: una puntuación de alto riesgo para la versión de un plugin o tema debe detener automáticamente su distribución sin la intervención del equipo de plugins. Todo el proceso sigue los siguientes pasos:
- Durante el período de enfriamiento, los cambios de cada versión se analizan en WordPress.org mediante modelos de inteligencia artificial (IA) junto con Jetpack Scan.
- Los resultados se verifican de forma cruzada y se combinan en una puntuación de seguridad: una puntuación más alta implica un riesgo potencialmente mayor.
- Las versiones con una puntuación de alto riesgo se bloquean automáticamente una vez completada la revisión, mientras que las que están por debajo de ese umbral continúan el proceso normal.
- Los responsables de la confirmación de plugins reciben un correo electrónico con los hallazgos. Los correos solo se envían en escenarios en los que se bloquea un plugin.
Cabe señalar que una puntuación de alto riesgo no indica necesariamente intención maliciosa, ya que la puntuación también tiene en cuenta fallos de seguridad introducidos inadvertidamente, del mismo modo que señala malware intencionado.
En un comentario posterior, Perez detalló que la revisión de seguridad busca las mismas clases de vulnerabilidades que cualquier auditoría de seguridad, e instó a los desarrolladores a seguir los estándares de codificación de WordPress y las reglas de PHP_CodeSniffer (PHPCS) para validar su código y garantizar la calidad. A quienes publican extensiones de WooCommerce se les recomienda utilizar la plataforma de pruebas Quality Insights Toolkit (QIT).
Otros patrones que también podrían elevar la puntuación de riesgo son los siguientes:
- Puntos finales REST, AJAX o admin-post sin comprobación de capacidades (un nonce por sí solo no es autorización)
- Consultas construidas sin $wpdb->prepare()
- Rutas de archivos, cargas, eliminaciones o inclusiones construidas a partir de datos de la solicitud
- unserialize() sobre datos de la solicitud o sobre una respuesta remota
- Opciones, metadatos de usuario o ajustes escritos desde puntos finales accesibles para suscriptores o usuarios no autenticados
- Código obtenido o evaluado en tiempo de ejecución, y código ofuscado o empaquetado
Una vez que se bloquea una versión, la única forma de que el desarrollador elimine las restricciones es revisar los hallazgos, corregir los problemas y publicar una nueva versión. Si la nueva versión obtiene una puntuación por debajo del umbral de alto riesgo, continúa con el proceso normal de enfriamiento.
Si un hallazgo parece incorrecto, los autores pueden contactar con el equipo de plugins. Por favor, comprendan que el equipo gestiona un gran volumen de revisiones, por lo que publicar una versión corregida casi siempre es más rápido que esperar una revisión manual de una apelación.
Deja una respuesta