wp2shell: ejecución de código sin autenticación en WordPress y cómo bloquearla
wp2shell es una cadena de ejecución remota de código sin autenticación en el núcleo de WordPress que combina dos fallos, CVE-2026-63030 y CVE-2026-60137. WordPress la corrigió el 17 de julio de 2026 con las versiones 7.0.2, 6.9.5 y 6.8.6, y los primeros ataques llegaron en pocas horas.
Actualiza primero el núcleo de WordPress, porque solo el parche elimina el fallo. ReportedIP Hive bloquea el patrón de ataque en todos los planes, también en el gratuito, desde la versión 2.1.25 del 19 de julio de 2026. Eso protege los sitios que aún no tienen el parche y frena también las variantes del ataque.
¿Qué es wp2shell?
wp2shell es el nombre de dos vulnerabilidades del núcleo de WordPress que se explotan juntas. Ninguna de las dos permite ejecutar código por sí sola. Encadenadas, llevan una petición anónima hasta una nueva cuenta de administrador.
- CVE-2026-60137 (inyección SQL). WordPress no sanea correctamente el parámetro
author__not_indeWP_Query. En la API REST se alimenta desdeauthor_exclude. Por sí solo, el fallo solo es alcanzable cuando un plugin o un tema pasa datos no verificados a ese parámetro. - CVE-2026-63030 (confusión de rutas en el batch REST). El endpoint
/wp-json/batch/v1valida y reparte las subpeticiones en dos bucles separados. Una subpetición con una ruta mal formada desincroniza las dos listas, de modo que una petición se ejecuta con el controlador de otra ruta. Así el parámetro vulnerable llega a la consulta de entradas sin iniciar sesión.
¿Qué versiones de WordPress están afectadas?
La confusión de rutas llegó con WordPress 6.9, así que la cadena completa solo funciona en 6.9 y 7.0. La inyección SQL por sí sola se remonta a 6.8. Las notas de la versión 7.0.2 de WordPress detallan las correcciones.
| Rama | Afectadas | Corregido en | Cadena completa |
|---|---|---|---|
| 7.0 | 7.0.0 a 7.0.1 | 7.0.2 | Sí |
| 6.9 | 6.9.0 a 6.9.4 | 6.9.5 | Sí |
| 6.8 | 6.8.0 a 6.8.5 | 6.8.6 | No |
WordPress.org forzó la actualización en los sitios afectados mediante el sistema de actualizaciones automáticas. Los sitios con las actualizaciones automáticas desactivadas, o con un hosting que retiene las actualizaciones del núcleo, siguen expuestos hasta que alguien los actualice a mano. La CISA añadió ambas CVE a su catálogo de vulnerabilidades explotadas activamente el 21 de julio de 2026, y la ficha NVD de CVE-2026-63030 recoge los detalles.
¿Cómo llega el ataque hasta la shell?
Cada paso de la cadena es una petición POST al endpoint batch, enviada a /wp-json/batch/v1 o a ?rest_route=/batch/v1. Dentro de la petición, una subruta mal formada provoca la confusión de rutas y un batch anidado transporta la inyección SQL. La inyección lee datos de la base de datos, y las peticiones siguientes crean un nuevo administrador a través de la ruta REST de usuarios. Con una cuenta de administrador, subir un plugin le da al atacante ejecución de código en el servidor.
Patchstack detectó los primeros intentos de explotación unos 90 minutos después de la publicación de 7.0.2. Hasta el 22 de julio de 2026 había bloqueado más de 65.000 intentos desde más de 1.500 direcciones IP, el 97 por ciento dirigidos al endpoint batch.
¿Cuántos ataques wp2shell ve ReportedIP?
Nuestros servidores honeypot reconocen las peticiones wp2shell como un tipo de ataque propio desde el 5 de septiembre de 2026. Entre el 5 y el 28 de septiembre de 2026 enviaron 601 reportes sobre 347 direcciones IP distintas, con 3.196 peticiones registradas. 580 de los 601 reportes contenían el batch anidado del que depende el ataque. El 29 de septiembre de 2026, 51 de las 347 direcciones tenían una puntuación de confianza de 75 o más, el umbral de la blacklist de ReportedIP.
El ataque sigue activo más de dos meses después del parche. Los escáneres prueban cada sitio WordPress que encuentran, porque algunos sitios siguen sin parchear. El informe de ataques de mayo a julio cubre las semanas en torno a la divulgación.
¿Cómo bloquea ReportedIP Hive wp2shell?
El firewall de Hive revisa cada petición de los visitantes que no han iniciado sesión. Examina la URL, el user agent y el cuerpo de la petición antes de que WordPress la procese. Con Extended Protection activada, la revisión ocurre incluso antes de que cargue WordPress. Desde la versión 2.1.25, el firewall lee el cuerpo en bruto y decodificado, así que una carga codificada dentro de un batch JSON queda visible para las mismas firmas.
La versión 2.1.25 añadió dos reglas que apuntan a la estructura del ataque y no a una sola palabra clave:
waf_rest_batch_desyncdetecta las subrutas mal formadas que el analizador batch rechaza, como varias barras iniciales o un esquema con el host vacío. Cambiar una ruta mal formada por otra no sirve para pasar.waf_rest_batch_nesteddetecta una subpetición cuyo cuerpo es a su vez un batch. El ataque no puede prescindir de este anidamiento sin perder la confusión de rutas.waf_sqli_unionya bloqueaba antes de 2.1.25 la inyecciónUNION SELECTde la que depende el paso de creación del administrador.
Las tres reglas forman parte de la base gratuita que se incluye en el plugin. Por eso funcionan en todos los planes y sin sincronizar reglas. Los sitios con Priority Sync en el plan Professional reciben las mismas reglas por la entrega firmada y pueden añadir las firmas más profundas de los niveles de paranoia 2 y 3. En nuestra batería de pruebas, las llamadas batch normales, las URL relativas al protocolo y las URL absolutas pasan las dos reglas batch. La guía del firewall para WordPress explica los niveles de reglas, las excepciones y la página de bloqueo.
¿Qué deben hacer ahora los administradores de WordPress?
- Revisa la versión del núcleo en cada sitio y actualiza a 7.0.2, 6.9.5 o 6.8.6 o posterior.
- Busca cuentas de administrador que nadie de tu equipo haya creado y plugins que no hayas instalado.
- Actualiza ReportedIP Hive a la versión actual desde Plugins, o haz clic en Comprobar si hay actualizaciones en la fila del plugin.
- En los sitios Professional, haz clic en Sync now en la página de reglas para traer al momento el conjunto de reglas actual.
La documentación del firewall describe la entrega de reglas y cómo permitir una petición bloqueada por error.
Preguntas frecuentes
¿ReportedIP Hive sustituye la actualización del núcleo de WordPress?
Hive no sustituye la actualización del núcleo, porque solo el parche elimina el fallo. El firewall bloquea el patrón de petición antes de que llegue al código vulnerable. Eso protege un sitio hasta que recibe el parche y frena las variantes del ataque. Aun así, cada sitio debería usar WordPress 7.0.2, 6.9.5 o 6.8.6 o posterior.
¿Están protegidos contra wp2shell los sitios con Hive gratuito?
Los sitios gratuitos están protegidos en cuanto usan Hive 2.1.25 o posterior. Las dos reglas batch y la regla UNION SELECT forman parte de la base que se incluye en el plugin, así que no hace falta un plan de pago ni sincronizar reglas. El plan Professional añade firmas más profundas y actualizaciones diarias de las reglas.
¿Bloquean las nuevas reglas peticiones batch REST legítimas?
Las peticiones batch normales pasan, porque las reglas solo detectan subrutas mal formadas y un batch anidado en el cuerpo de una subpetición. Las llamadas batch del editor de bloques no tienen ninguna de esas formas. Si un plugin de tu sitio envía una, puedes crear una excepción para esa regla desde el Event Log de Hive.