Las versiones 6.9.5 y 7.0.2 de WordPress corrigen wp2shell, una vulnerabilidad de ejecución remota de código en el núcleo que permite a atacantes anónimos ejecutar código en instalaciones predeterminadas, incluso sin plugins.
Una solicitud HTTP anónima puede ejecutar código en un sitio de WordPress. El fallo reside en el núcleo, por lo que una instalación básica sin plugins es vulnerable.
Todos los sitios con las versiones 6.9 y 7.0 estuvieron expuestos hasta el viernes, cuando WordPress lanzó las versiones 6.9.5 y 7.0.2 e implementó las actualizaciones forzadas mediante su sistema de actualización automática. Las versiones afectadas fueron 6.9.0 a 6.9.4 y 7.0.0 a 7.0.1.
Adam Kues, de Assetnote, la división de gestión de la superficie de ataque de Searchlight Cyber, descubrió la vulnerabilidad y la reportó a través del programa HackerOne de WordPress. El informe técnico, publicado bajo el nombre de wp2shell, indica que el ataque no requiere condiciones previas y puede ser explotado por un usuario anónimo.
La empresa aún no ha revelado los detalles técnicos y ha habilitado una herramienta de análisis en wp2shell.com para que los propietarios puedan probar sus propias instancias.
WordPress lanzó las versiones 6.9.5 y 7.0.2 el 17 de julio de 2026, solucionando una vulnerabilidad de ejecución remota de código previa a la autenticación en el núcleo. Los rangos de versiones afectados fueron 6.9.0 a 6.9.4, corregido en la versión 6.9.5, y 7.0.0 a 7.0.1, corregido en la versión 7.0.2.
WordPress no ha confirmado si la actualización forzada llega a los sitios que desactivaron las actualizaciones automáticas. Se recomienda verificar la versión en uso en lugar de asumir que la actualización se instaló.
La versión 7.1 beta2 incluye la misma corrección. Los sitios que aún usan la versión 6.8 también tienen una actualización pendiente, pero la versión 6.8.6 corrige un segundo error de inyección SQL de la misma ronda, reportado por otro equipo.
Según Searchlight, más de 500 millones de sitios web usan WordPress. Esta cifra corresponde a la base total de instalaciones, no a la población vulnerable: el código defectuoso solo existe a partir de la versión 6.9, que se lanzó el 2 de diciembre de 2025. Por lo tanto, todos los sitios afectados usan una versión con menos de ocho meses de antigüedad.
WordPress describe el hallazgo como una confusión en el enrutamiento por lotes de la API REST y un problema de inyección SQL que conduce a la ejecución remota de código. La página de la versión 7.0.2 enumera tres archivos afectados: /wp-includes/rest-api/class-wp-rest-server.php, /wp-includes/class-wp-query.php y /wp-includes/rest-api.php. El endpoint de procesamiento por lotes no es nuevo, pues WordPress lo incluye desde la versión 5.6 de noviembre de 2020.
Ninguno de los avisos incluye un ID de CVE ni una puntuación CVSS, y hasta el 18 de julio no se había registrado ningún CVE. Los escáneres e inventarios con clave CVE no lo detectarán. Se recomienda realizar el seguimiento por número de versión.
Todas las medidas de mitigación de Searchlight se basan en impedir que usuarios anónimos accedan al endpoint de procesamiento por lotes. Las opciones incluyen bloquear en el WAF tanto /wp-json/batch/v1 como rest_route=/batch/v1, desactivar la API REST de WordPress para bloquear completamente el acceso REST no autenticado, o utilizar un plugin que rechace las solicitudes anónimas de /batch/v1 en rest_pre_dispatch.
La explotación masiva de WordPress se ha convertido en una industria. Antes de que su servidor se filtrara en junio, una sola vulnerabilidad en un plugin de caché permitió al grupo WP-SHELLSTORM acceder a más de 17.000 sitios según sus propios cálculos.
El núcleo de WordPress es de código abierto, y tanto la versión 7.0.1 como la 7.0.2 se encuentran en el archivo de versiones públicas, por lo que la comparación está disponible. El dilema de todo proyecto de código abierto es que no se puede publicar la solución sin publicar el mapa del error, y la única opción que queda es la rapidez con la que el parche llega a los sitios antes de que alguien lo lea.
WordPress activó esa opción el viernes. El tráfico contra batch/v1 mostrará cuándo llegan los atacantes, y las estadísticas de versiones de WordPress mostrarán si el parche llegó primero.
Con Información de blog.segu-info.com.ar
