WordPress 6.9.5 y 7.0.2 corrigen
wp2shell, una vulnerabilidad de ejecución remota de código (RCE) 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 estaban 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.
Versiones afectadas:
- 6.9.0 – 6.9.4: afectada
- 7.0.0 – 7.0.1: afectada
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 (RCE) previa a
la autenticación en el núcleo que una solicitud anónima podía activar en una
instalación predeterminada sin plugins. Dos rangos de versiones se ven
afectados:
- 6.9.0 a 6.9.4, corregido en la versión 6.9.5
- 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. Verifique la versión que está
utilizando 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 el segundo error de inyección SQL de la misma ronda, reportado por
otro equipo.
La publicación de Searchlight estima que 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, y ninguno de los avisos especifica cuántos sitios se ven
afectados.
WordPress es más transparente sobre la clasificación del error que el propio
investigador. En su publicación,
describe el hallazgo de Kues
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 publicación cubre un fallo crítico y otro de alta gravedad, y WordPress
no especifica cuál es cuál.
La
página de la versión
enumera los tres archivos afectados por la versión 7.0.2, que incluyen ambas
correcciones: /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. WordPress lo incluye
desde la versión 5.6 (noviembre de 2020) y ha documentado públicamente el
formato de la solicitud desde entonces. Hasta el momento, no se ha publicado
ninguna explicación sobre qué cambió en la versión 6.9 para que se hiciera
público.
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, y CISA necesita un CVE antes de poder añadirlo al
catálogo KEV. En su lugar, realice el seguimiento por número de versión.
Mitigación
Todas las medidas de mitigación que ofrece Searchlight se basan en impedir
que usuarios anónimos accedan al endpoint de procesamiento por lotes.
Hay tres opciones, todas provisionales hasta que actualice, y todas pueden
interrumpir integraciones legítimas:
-
En el WAF, bloquee tanto /wp-json/batch/v1 como
rest_route=/batch/v1. La empresa insiste en que ambos deben
bloquearse, ya que una regla que solo cubra la ruta /wp-json deja
abierta la ruta de la cadena de consulta. - Desactive la API REST de WordPress, lo que bloquea completamente el acceso REST no autenticado.
-
Un plugin sencillo que publica y rechaza las solicitudes anónimas de
/batch/v1 en rest_pre_dispatch. Hasta el 18 de julio no se
había reportado ningún intento de explotación. Sin una CVE que etiquetar ni
una firma pública que la coincida, nadie está investigando realmente.
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. Ese fallo ya era
público, ya había sido parcheado y solo funcionaba con una configuración no
predeterminada.
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 para quien la desee. Este es el dilema de todo
proyecto de código abierto: 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. Solo una de esas cifras suele aparecer
en las noticias.
Fuente:
THN