Se ha revelado una cadena de vulnerabilidades crítica de ejecución remota de código (RCE) denominada "wp2shell" en el núcleo de WordPress. Este fallo pone en riesgo a más de 500 millones de sitios web, permitiendo que atacantes no autenticados tomen el control total de los sitios. La vulnerabilidad es el resultado de la combinación de dos fallos: el CVE-2026-63030 (confusión en la ruta de lote de la API REST) y el CVE-2026-60137 (una inyección SQL).

Se ha revelado una cadena crítica de vulnerabilidades de ejecución remota de código (RCE) previa a la autenticación, apodada "wp2shell", en el núcleo de WordPress, poniendo en riesgo a unos 500 millones de sitios web de ser tomados completamente por atacantes no autenticados.

La cadena combina dos fallos rastreados por separado: CVE-2026-63030, un problema de confusión de rutas por lotes de la API REST, y CVE-2026-60137, una vulnerabilidad de inyección SQL en el parámetro author__not_in de WP_Query, para lograr el compromiso total del servidor en una instalación de WordPress estándar sin ningún plugin instalado.

WordPress impulsa aproximadamente el 43 por ciento de todos los sitios web a nivel mundial, lo que convierte a esta en una de las revelaciones de seguridad de CMS más trascendentales en la memoria reciente.

Lo que diferencia a wp2shell de los problemas de seguridad típicos de WordPress es que no requiere ninguna precondición: ni una cuenta válida, ni un plugin vulnerable, ni una configuración especial, ni interacción del usuario. Cualquier atacante anónimo capaz de alcanzar una instancia vulnerable de WordPress a través de la red puede comprometerla directamente.

Descubrimiento: Un modelo de IA lo encontró por 25 dólares

El fallo fue descubierto por el investigador de seguridad Adam Kues, del equipo de investigación Assetnote de Searchlight Cyber, utilizando un método poco convencional: un proyecto de investigación de vulnerabilidades impulsado por IA, basado en el modelo GPT-5.6 Sol Ultra de OpenAI.

Kues adaptó un "prompt" publicado originalmente por OpenAI, que se había utilizado para ayudar al modelo a resolver la conjetura matemática "Cycle Double Cover", y lo redirigió al código base del núcleo de WordPress, instruyendo al modelo para buscar una cadena de pre-autenticación a RCE utilizando hasta cuatro agentes de investigación paralelos durante al menos seis horas.

Kues instruyó explícitamente al modelo para que no consultara registros de cambios, el historial de git ni internet para comparar con versiones parcheadas, obligándolo a descubrir el error puramente mediante el análisis de código desde principios básicos. También se le indicó al modelo que podía clonar y auditar dependencias de terceros si una cadena completa requería errores en librerías subyacentes como el propio PHP o MySQL.

El resultado: Sol identificó una inyección SQL completa de pre-autenticación dentro del código base, algo que Kues dudó inicialmente dado el historial de una década de WordPress sin vulnerabilidades importantes de pre-autenticación. Tras validar la SQLi contra una instancia de prueba en vivo extrayendo la dirección de correo electrónico de un administrador, Kues preguntó al modelo si podía escalar el error a un RCE completo.

Aproximadamente cuatro horas después, el modelo respondió afirmativamente con una cadena de escalada funcional. El coste total de computación para todo el descubrimiento, utilizando una suscripción de 200 dólares al mes, fue de aproximadamente 25 dólares en base a un uso prorrateado.

Kues señaló que comprender y documentar la cadena de explotación generada por la IA le llevó considerablemente más tiempo que al modelo en desarrollarla, calificando la técnica de post-explotación como "completamente absurda" en su sofisticación.

Cadena de Explotación wp2shell

El error de desincronización de la API por lotes (CVE-2026-63030)

El fallo raíz reside en el endpoint de lotes de la API REST de WordPress (/wp-json/batch/v1), una función introducida en WordPress 5.6 en 2020 que permite agrupar múltiples solicitudes virtuales de API en una sola llamada.

En un funcionamiento normal, cada solicitud REST individual pasa por un proceso de cuatro pasos: validación de parámetros, sanitización de parámetros, una llamada de retorno (callback) de permisos y, finalmente, la ejecución del endpoint.

El endpoint de lotes rompe este patrón al ejecutar la validación y la ejecución como dos bucles separados en lugar de procesar cada solicitud en serie. Si una solicitud en el lote está mal formada, la matriz de validación registra el error, pero la matriz correspondiente de manejadores resueltos no se actualiza en sincronía, debido a una sentencia continue que omite la inserción en una matriz pero no en la otra.

Esto desincroniza la alineación de los índices entre las dos matrices, de modo que cuando se ejecuta la acción, los parámetros validados de la solicitud N pueden terminar aplicándose al manejador real de la solicitud N+1, saltándose completamente la sanitización de parámetros prevista. Este fallo está clasificado bajo CWE-436 (conflicto de interpretación) y tiene una puntuación base CVSS v3.1 de 7.5 (Alta).

El sumidero de inyección SQL (CVE-2026-60137)

El error de desincronización por sí solo no concede nada sin un sumidero vulnerable que explotar. Ese sumidero es el parámetro author__not_in de WP_Query, la clase central de WordPress para construir consultas a la base de datos. Cuando el parámetro se envía como una matriz, WordPress sanitiza cada valor usando absint(). Pero si se envía como una cadena escalar bruta, el paso de sanitización se omite por completo y el valor se interpola directamente en una cláusula SQL NOT IN bruta.

Normalmente, esta ruta es inalcanzable, ya que el parámetro público author_exclude se valida como una matriz de enteros antes de llegar a author__not_in.

El error de desincronización de la ruta de lotes elude esa validación, permitiendo que una carga útil SQL escalar pase intacta y, debido a que el endpoint subyacente solo admite solicitudes GET (que la API de lotes no permite nativamente), la explotación utiliza una llamada de lotes recursiva y anidada para introducir la solicitud GET a través del mecanismo de desincronización una segunda vez.

Esta vulnerabilidad está clasificada bajo CWE-89 (inyección SQL) y calificada con un 9.1 (Crítica) en la escala CVSS v3.1.

Escalando una SQLi de solo lectura a un RCE completo

La inyección SQL por sí sola es un error de fuga de datos de "solo SELECT" que no puede recuperar directamente credenciales en texto plano descifrables, ya que WordPress aplica hashes a las contraseñas en la base de datos. La ruta de escalada ideada por el modelo de IA explotó una cadena de comportamientos secundarios de WordPress:

• Envenenamiento de caché de posts en memoria: La inyección basada en UNION de la SQLi puede fabricar objetos WP_Post falsos que se almacenan en la caché de memoria durante la duración de una solicitud.
• Abuso de caché de Embed: El shortcode de WordPress almacena los posts locales referenciados como filas oembed_cache en la base de datos sin verificar si el ID del post referenciado existe realmente, permitiendo que un atacante plante filas de base de datos con apariencia legítima.
• Explotación de la conciliación caché/base de datos: Cuando WordPress detecta una discrepancia entre las versiones en memoria y en la caché de la base de datos de un post, prioriza los valores en memoria (controlados por el atacante), haciendo que aparezcan filas fabricadas como tipos de post arbitrarios.
• Secuestro de cambios de personalización (Customize changeset): Un tipo de post customize_changeset almacena borradores de cambios en la configuración del sitio etiquetados con un user_id; al aplicarlo, se asigna temporalmente la identidad de ese usuario a través de wp_set_current_user(), incluyendo privilegios de administrador si el user_id se falsifica como 1.
• Gadget de detección de ciclos: La detección de ciclos de jerarquía de posts padres de WordPress, diseñada para evitar bucles infinitos, puede abusarse para disparar llamadas secundarias a wp_update_post() que exponen campos normalmente protegidos como post_content.
• Reproducción de Hook vía parse_request: Mientras mantiene brevemente el contexto de administrador, el atacante dispara el hook de acción parse_request, que reproduce toda la solicitud de lote original, esta vez con privilegios elevados, permitiendo la creación de una nueva cuenta de administrador persistente.

Con una cuenta de administrador maliciosa en mano, el atacante inicia sesión normalmente y sube un archivo ZIP de un plugin malicioso, logrando la ejecución remota de código completa en el servidor.

Kues afirmó que la cadena de explotación completa fue producida por el modelo de IA en poco más de 10 horas y expresó su confianza en que ningún investigador humano podría haber descubierto y completado la cadena sin ayuda en ese plazo.

Versiones Afectadas y Parcheadas

Rango de Versión de WordPress	CVE-2026-60137 (SQLi)	CVE-2026-63030 (Cadena RCE)	Estado
Antes de 6.8.0	No afectada	No afectada	Seguro
6.8.0 – 6.8.5	Afectada	No afectada (sin error de lote)	Solo SQLi
6.9.0 – 6.9.4	Afectada	Afectada	Cadena RCE completa
7.0.0 – 7.0.1	Afectada	Afectada	Cadena RCE completa
7.1 beta (pre-lanzamiento)	Afectada	Afectada	Cadena RCE completa

Datos compilados de avisos de seguridad de WordPress y reportes del proveedor. La rama 6.8.x solo contiene el componente de inyección SQL y no está expuesta a la cadena completa de RCE no autenticado, porque el error de confusión de rutas por lotes (CVE-2026-63030) solo se introdujo en WordPress 6.9.

Las versiones corregidas son WordPress 6.8.6, 6.9.5 y 7.0.2, junto con 7.1 Beta 2 para la rama de pre-lanzamiento.

Línea de Tiempo de Revelación y Parche

WordPress lanzó versiones de seguridad de emergencia el 17 de julio de 2026, abordando ambas vulnerabilidades simultáneamente. Dada la gravedad, el equipo de seguridad de WordPress.org tomó la rara medida de habilitar actualizaciones automáticas forzadas a través del sistema de auto-actualización de la plataforma para todas las instalaciones compatibles que ejecutaban versiones afectadas, un mecanismo reservado típicamente para situaciones de nivel de crisis.

Se insta a los administradores a verificar manualmente que la actualización forzada se haya completado realmente, ya que la configuración de auto-actualización, los despliegues personalizados o las configuraciones de hosting gestionado pueden impedir que se aplique.

CVE-2026-60137 fue reportada independientemente al equipo de seguridad de WordPress por los investigadores TF1T, dtro y haongo, y fue parcheada en el mismo ciclo de lanzamiento que la cadena RCE descubierta por Kues.

Searchlight Cyber retuvo inicialmente los detalles técnicos completos de la explotación para dar a los propietarios de los sitios una ventana para parchear durante el fin de semana posterior a la revelación, publicando solo un escáner público gratuito y no intrusivo en wp2shell[.]com para que los administradores pudieran comprobar su exposición.

Lanzamiento de PoC Público y Explotación Activa

A pesar del retraso en la revelación del investigador, los exploits de prueba de concepto (PoC) públicos comenzaron a circular en GitHub en aproximadamente 24 horas. Searchlight Cyber señaló que durante el periodo de retención, otros dos grupos, Calif y Hacktron, ya habían reproducido independientemente la cadena de explotación completa antes de que surgieran PoCs adicionales públicamente.

Múltiples proveedores de seguridad confirmaron intentos tempranos de explotación en el mundo real. El CEO de watchTowr, Benjamin Harris, dijo que la firma "ya estaba viendo exploits PoC circulando" con "los primeros signos de explotación en libertad".

El jefe de Inteligencia de Ciberamenazas de Hexastrike, Maurice Fielenback, afirmó que la firma continuaba viendo "intentos y explotaciones exitosas de wp2shell" y que había "gestionado varios incidentes confirmados y sospechosos" tras detectar los intentos iniciales el domingo anterior.

Algunas variantes de exploits publicadas demuestran la extracción de hashes de contraseñas de administrador a través del componente de inyección SQL y el descifrado de credenciales fuera de línea, mientras que otras replican la cadena completa de RCE de pre-autenticación del investigador sin necesidad de descifrar ninguna contraseña.

Cloudflare informó por separado que la ruta de código vulnerable es específicamente alcanzable cuando no se utiliza una caché de objetos persistente en el servidor objetivo, y la empresa desplegó protecciones WAF contra ambos CVE en todos los planes de clientes, incluida la capa gratuita, para dominios proxy.

Guía de Remediación y Mitigación

Actualizar el núcleo de WordPress a una versión parcheada es descrito por todos los proveedores principales como la única solución completa. Los pasos de remediación recomendados incluyen:

• Actualiza inmediatamente a WordPress 7.0.2, 6.9.5 o 6.8.6 según la rama que estés ejecutando, ya sea a través de la pantalla de Actualizaciones del Panel de WordPress o descargando la versión directamente desde WordPress.org.
• Verifica que la actualización automática forzada se haya aplicado realmente en cada sitio gestionado, ya que las auto-actualizaciones desactivadas o los despliegues personalizados pueden bloquear el envío forzado.
• Usa el escáner gratuito wp2shell[.]com, o consulta manualmente el endpoint de lotes, para confirmar tu estado de exposición actual.
• Si el parcheo inmediato no es viable, bloquea tanto /wp-json/batch/v1 como la variante de cadena de consulta ?rest_route=/batch/v1 a nivel de WAF o servidor web; filtrar solo la forma de ruta deja el sitio explotable a través de la ruta de cadena de consulta.
• Instala un plugin o plugin de uso obligatorio (must-use) que rechace las solicitudes de lotes de la API REST anónimas, por ejemplo mediante el hook rest_pre_dispatch, como medida provisional.
• Revisa los logs en busca de solicitudes sospechosas al endpoint de lotes, comprueba si hay nuevas cuentas de administrador inesperadas e inspecciona si hay plugins, temas desconocidos o filas alteradas en las tablas wp_posts y wp_options en cualquier sitio que haya ejecutado una versión afectada.

Los proveedores de seguridad enfatizan que el bloqueo a nivel de WAF y los plugins de restricción de la API REST son estrictamente medidas provisionales temporales que pueden interrumpir la funcionalidad legítima del sitio, y que las actualizaciones de versión del núcleo siguen siendo la única remediación duradera.

La revelación de wp2shell es notable más allá de su gravedad técnica por la forma en que fue encontrada. El relato de Kues señala un cambio en la economía de la investigación de vulnerabilidades: un gasto de 25 dólares en computación de IA descubrió una clase de error que, según el propio marco de Searchlight Cyber, los brokers de exploits han pagado históricamente hasta 500,000 dólares por adquirir.

Kues argumentó que las técnicas de explotación encadenadas por el modelo, incluyendo el abuso de llamadas de lote recursivas, los gadgets de desincronización de caché y la escalada de privilegios por reproducción de hooks, reflejaron un razonamiento creativo que él previamente asumía era exclusivo de investigadores humanos experimentados.

Fuentes:
https://cybersecuritynews.com/critical-wp2shell-rce-vulnerability/