Una solicitud HTTP anónima puede ejecutar código en un sitio de WordPress. El error está en el núcleo, por lo que se puede explotar una instalación simple sin complementos.
Todos los sitios 6.9 y 7.0 estuvieron dentro del alcance hasta el viernes, cuando WordPress envió 6.9.5 y 7.0.2 y habilitó lo que llama actualizaciones forzadas a través de su sistema de actualización automática.
Adam Kues de Assetnote, el brazo de gestión de superficies de ataque de Searchlight Cyber, encontró la falla y la informó a través del programa HackerOne de WordPress. El artículo, publicado bajo el nombre wp2shelldice que el ataque “no tiene condiciones previas y puede ser explotado por un usuario anónimo”.
La empresa está pendiente de los detalles técnicos por ahora y en su lugar ha colocado un verificador en wp2shell.com, para que los propietarios puedan probar su propia instancia.
WordPress lanzó 6.9.5 y 7.0.2 el 17 de julio de 2026, cerrando un RCE de autenticación previa en el núcleo que una solicitud anónima puede activar contra una instalación predeterminada sin complementos. Dos rangos se ven afectados:
- 6.9.0 a 6.9.4, corregido en 6.9.5
- 7.0.0 a 7.0.1, arreglado en 7.0.2
WordPress no ha dicho si el envío forzado llega a los sitios que desactivaron las actualizaciones automáticas. Verifique lo que realmente está ejecutando en lugar de asumir que aterrizó.
7.1 beta2 incluye la misma solución. Los sitios que todavía están en 6.8 también tienen una actualización esperando, pero 6.8.6 es para el segundo error de inyección SQL en la misma ronda, informado por un equipo diferente.
La publicación de Searchlight estima que más de 500 millones de sitios web ejecutan WordPress. Esa cifra es la base de instalación total, no la población vulnerable: el código defectuoso solo existe desde la versión 6.9 en adelante, y la versión 6.9 se envió el 2 de diciembre de 2025. Por lo tanto, cada sitio afectado ejecuta una versión de menos de ocho meses y ninguno de los avisos dice cuántos sitios cubre.
WordPress es más comunicativo sobre la clase de error que el investigador. Su publicación de lanzamiento describe el hallazgo de Kues como “una confusión de rutas por lotes de API REST y un problema de inyección de SQL que conduce a la ejecución remota de código”. El lanzamiento cubre una falla crítica y otra de alta gravedad, y WordPress no dice cuál es cuál.
La página de la versión enumera los tres archivos tocados por 7.0.2, cubriendo ambas correcciones: /wp-includes/rest-api/class-wp-rest-server.php, /wp-includes/class-wp-query.php y /wp-includes/rest-api.php. El punto final por lotes no es nuevo. WordPress lo envió desde 5.6 en noviembre de 2020 y documentó públicamente el formato de solicitud desde entonces. Nada publicado hasta ahora explica qué cambió en 6.9 para abrirlo.
Ninguno de los avisos incluye un ID CVE o una puntuación CVSS, y no había aparecido ningún registro CVE hasta el 18 de julio. Los escáneres e inventarios con clave CVE no marcarán este, y CISA necesita un CVE antes de poder agregar algo al catálogo KEV. En su lugar, realice un seguimiento por número de versión.
Si no puedes actualizar hoy
Todas las mitigaciones que ofrece Searchlight se reducen a mantener a las personas que llaman anónimas fuera del punto final por lotes. Tres opciones, todas ellas provisionales hasta que actualices, y todas ellas capaces de romper integraciones legítimas:
- En un WAF, bloquee /wp-json/batch/v1 y rest_route=/batch/v1. La empresa es explícita en que ambos tienen que desaparecer, porque una regla que cubre solo la ruta /wp-json deja abierta la ruta de la cadena de consulta.
- Deshabilite la API REST de WP, que elimina al por mayor el acceso REST no autenticado.
- Un complemento breve que publica y rechaza solicitudes anónimas /batch/v1 en rest_pre_dispatch.
No se ha reportado ningún intento de explotación hasta el 18 de julio. Sin CVE para etiquetar y sin firma pública que coincida, nadie está realmente mirando todavía.
La explotación masiva de WordPress es ahora una industria. Antes de que su servidor se filtrara en junio, un solo fallo en el complemento de almacenamiento en caché llevó al equipo de WP-SHELLSTORM a más de 17.000 sitios, según su propio recuento. Ese error ya era público, ya estaba parcheado y solo funcionaba en una configuración no predeterminada.
Cuando Drupal parchó una inyección SQL anónima en su propio núcleo en mayo, Searchlight convirtió esa solución pública en un desmontaje el mismo día con dos pruebas de concepto funcionales. Eso fue error de otro y parche de otro, y nada obliga a la firma a hacer lo mismo con los suyos. Pero fue necesario un día, y las personas que pusieron en marcha ese reloj son las que ahora apuestan que el silencio les da tiempo a los defensores.
El núcleo de WordPress es de código abierto, y 7.0.1 y 7.0.2 se encuentran en el archivo de lanzamiento público, por lo que la comparación está disponible para cualquiera que la desee. Ese es el problema de todo proyecto de código abierto: no se puede enviar la solución sin enviar el mapa del error, y la única palanca que queda es qué tan rápido el parche llega a los sitios antes de que alguien lo lea.
WordPress tiró de esa palanca el viernes. El tráfico contra el lote/v1 mostrará cuándo llegan los atacantes, y las estadísticas de la propia versión de WordPress mostrarán si el parche llegó primero. Sólo uno de esos números aparece en las noticias.
