wp2shell: una RCE de WordPress estándar, encontrada en diez horas por 25 dólares

El 17 de julio de 2026, Searchlight Cyber publicó wp2shell, una cadena de ejecución remota de código previa a la autenticación en el núcleo de WordPress que no necesita ningún plugin, ningún tema ni inicio de sesión. Una solicitud anónima contra una instalación estándar es suficiente: «El ataque no tiene precondiciones y puede ser explotado por un usuario anónimo en una instalación estándar de WordPress sin plugins», afirma el aviso de la empresa. La cadena combina dos fallos —CVE-2026-63030, una falla de confusión de rutas en el endpoint por lotes de la API REST de WordPress que el aviso del proyecto califica como crítica, y CVE-2026-60137, una inyección SQL en author__not_in, un parámetro de WP_Query que califica como moderada. WordPress publicó WordPress 7.0.2 ese mismo día, y los avisos del proyecto enumeran WordPress 6.9.5, WordPress 6.8.6 y WordPress 7.1 beta2 como portadores de las mismas correcciones. Searchlight cita estimaciones de más de 500 millones de sitios WordPress. El investigador detrás de la cadena, Adam Kues, afirma que surgió de una ejecución de GPT-5.6 Sol Ultra basada en un prompt que OpenAI había publicado para un problema de matemáticas: hasta cuatro agentes, al menos seis horas en la búsqueda y unas cuatro más en la escalada, aproximadamente 25 dólares de uso de modelos. El registro se archiva como un hallazgo de investigación —gravedad alta según la propia escala del archivo, confianza de grado A, ningún daño real registrado, fechado en un solo día— y el Orca AI Incident Archive lo recoge con los documentos primarios enlazados debajo.

La divulgación fue coordinada. Searchlight no reveló los detalles técnicos el 17 de julio y dio a los defensores el fin de semana para actualizar; Kues publicó el informe técnico completo el 20 de julio. Para entonces, el exploit encadenado ya había sido reproducido de forma independiente: Searchlight afirma que Calif y Hacktron reconstruyeron la cadena completa antes de que aparecieran otras pruebas de concepto en GitHub. Los dos avisos de seguridad de WordPress identifican las mismas versiones corregidas, y CISA añadió ambos CVE a su catálogo de Vulnerabilidades Explotadas Conocidas el 21 de julio.

Dos bugs, y los arrays que se desincronizan

El punto de entrada es una característica, no un error. WordPress 5.6 introdujo el endpoint por lotes en 2020 para que un cliente pudiera enviar varias solicitudes REST virtuales dentro de una sola solicitud HTTP, por ejemplo, para cambiar el título de un conjunto de entradas a la vez. Se puede acceder al endpoint independientemente de si el solicitante está autenticado, y cada subsolicitud lleva la autenticación que haya proporcionado el solicitante. Una solicitud directa a una ruta REST de WordPress ejecuta una canalización de cuatro pasos: comprobar los parámetros requeridos y válidos, sanearlos, ejecutar la devolución de llamada de permisos y, después, ejecutar la devolución de llamada del endpoint. Los endpoints dependen de esa canalización para sus suposiciones de tipo: que el ID de una entrada sea un entero, que un título sea una cadena.

La API de lotes divide el pipeline en dos, validando cada subsolicitud en un bucle y ejecutándolas en un segundo, y mantiene dos arrays, $matches y $validation, cuyas entradas deben alinearse índice por índice. En class-wp-rest-server.php, tal como lo describe Kues, una subsolicitud que es en sí misma un error de WordPress se agrega a $validation y luego se encuentra con un continue, omitiendo la línea que agrega a $matches. A partir de ese momento, cada coincidencia se desplaza una posición hacia atrás. El bucle de ejecución empareja la subsolicitud en un índice con la validación registrada en ese índice, pero el manejador está asociado a una ruta diferente — por lo que un parámetro se verifica contra las reglas de un endpoint y luego lo ejecuta el código de otro.

Eso es lo que convierte un parámetro de lista aparentemente normal en una inyección. La ruta de la colección de posts asigna su argumento público author_exclude a author__not_in. Cuando el valor es un array, WordPress ejecuta absint sobre cada elemento y los ordena; cuando el valor es un escalar, se concatena tal cual en el fragmento SQL que se convierte en NOT IN ($author__not_in). Una cadena como 0) OR 1=1 --, por lo tanto, termina en el texto de la consulta. Llamada con normalidad, la ruta lo rechazaría, porque author_exclude debe ser un array de enteros; la llamada por lotes desincronizada es la que deja pasar una cadena.

Quedaban dos obstáculos, y ambos se resolvieron anidando el truco. La API por lotes rechaza las solicitudes GET, y la inyección reside en una ruta GET; y la validación del método de solicitud está implementada a su vez como validación de parámetros, que la misma desincronización puede eludir. La carga útil publicada por Kues envía una subsolicitud externa malformada para desincronizar la comprobación del método, luego un lote interno cuya segunda subsolicitud lleva el author_exclude malicioso contra un controlador que no lo valida, y después la solicitud GET que lo ejecuta. Una inyección basada en UNION devuelve valores arbitrarios de la base de datos dentro de filas con la forma de publicaciones normales.

La ejecución del modelo: un prompt de matemáticas, dirigido a una base de código

Kues no escribió el prompt desde cero. OpenAI había publicado el prompt que utilizó mientras trabajaba en la conjetura de la doble cobertura de ciclos, y Kues escribió que había leído que el modelo había resuelto recientemente esa conjetura y que nadie en la comunidad de seguridad parecía estar hablando del prompt. Su razonamiento era que, si servía para matemáticas difíciles, probablemente también serviría para la investigación en seguridad. Lo adaptó y lo dirigió hacia WordPress.

La configuración era deliberadamente limitada. Clonó la última versión estable de WordPress en un directorio llamado main/ y eliminó su directorio .git, indicándole al modelo que no usara registros de cambios, historial de git ni internet abierto para comparar el código con una versión parcheada — su razón declarada era que, para el descubrimiento de vulnerabilidades novedosas, consultar el historial o la web es un desperdicio de tokens. Se ofreció un directorio vacío third_party/ para que el modelo pudiera clonar dependencias como el código fuente de PHP o MySQL si considerara que la cadena necesitaba errores en las bibliotecas subyacentes a WordPress. La tarea se especificó como RCE previa a la autenticación en una implementación de producción típica sobre MySQL, con hasta cuatro agentes y al menos seis horas. Kues escribió que indica explícitamente el requisito de configuración porque, de lo contrario, los modelos "hacen trampa" — eligiendo opciones de configuración extremadamente improbables, o fabricando condiciones previas que un atacante nunca podría lograr.

Lo que volvió, en la salida en ejecución, fue la afirmación de una inyección SQL de preautenticación. Kues lo dudaba: WordPress es uno de los objetivos más auditados de todos los tiempos, escribió, y no había tenido una vulnerabilidad de preautenticación significativa en esa década. Instaló una instancia estándar de WordPress en un servidor remoto y pidió al modelo que robara el correo electrónico del administrador; en un par de minutos imprimió la dirección que había usado para configurar la instancia. Luego preguntó si la inyección de solo lectura podía escalarse, y unas cuatro horas después el modelo respondió que sí podía —a administrador, sin crackear ninguna contraseña y sin cálculo offline.

Su propio cálculo de costes: el 50 % de una asignación semanal de uso, que estimó en unos 25 dólares prorrateados sobre una suscripción de 200 dólares, por un exploit producido en poco más de diez horas. La parte humana no fue gratuita — Kues pasó el día siguiente desentrañando lo que el modelo había hecho, y escribió que le llevó mucho más tiempo entender el trabajo posterior a la explotación de lo que había llevado generarlo. Su veredicto es inusualmente directo y estrictamente acotado: «No hago afirmaciones generales, pero puedo decir con total confianza que ningún investigador de seguridad podría haber encontrado y completado esta cadena de exploits en 10 horas sin IA».

De un SELECT de solo lectura a administrador

La escalada es la parte del registro que más importa, porque es donde una lectura de base de datos se convirtió en control del servidor. El relato de Kues la presenta como una secuencia de seis movimientos, cada uno usando una función ordinaria de WordPress contra otra.

Primero, envenena la caché de entradas en memoria.WordPress mantiene una caché por solicitud de objetos WP_Post, de modo que la misma entrada a la que se hace referencia varias veces en una sola solicitud cuesta un único viaje de ida y vuelta a la base de datos. La inyección SQL puede fabricar entradas, por lo que el atacante controla exactamente qué se almacena en la caché; pero esas entradas fabricadas no son filas de la base de datos, y la caché muere con la solicitud.

Segundo, convertir publicaciones fabricadas en filas reales. La función de incrustación de WordPress almacena en caché las incrustaciones resueltas en la base de datos como publicaciones de tipo oembed_cache. Incrustar una publicación local mediante una ruta relativa, como en [embed]/?p=S[/embed], hace que WordPress omita la solicitud HTTP y nunca compruebe que la publicación referenciada exista, por lo que se crea una fila. Tres incrustaciones de este tipo con diferentes tokens de cadena de consulta producen tres hashes de caché distintos, y así es como el atacante consigue varias filas con las que trabajar.

Tercero, sortear el único campo que permanece fijo. Cuando las versiones en memoria y en base de datos de una entrada no coinciden, WordPress las concilia mediante una llamada que establece explícitamente post_content a partir de la salida del embed. Todo acerca de la entrada está controlado por el atacante excepto su contenido, que es precisamente el campo que un customize_changeset usa para almacenar el JSON de los cambios pendientes del tema y del sitio.

Cuarto, el gadget de ciclo.Las entradas tienen padres, y WordPress rechaza los ciclos: el filtro wp_insert_post_parent recorre el árbol hacia arriba y, al encontrar un bucle, llama a una actualización que establece post_parent a cero. Esa llamada no sobrescribe post_content, por lo que la versión fabricada en memoria sobrevive a la reconciliación: un conjunto de cambios, con su JSON intacto, respaldado por una fila real.

Quinto, tomar prestada la autoridad del administrador. Un conjunto de cambios cuyo estado indica que está programado para el futuro pero cuya fecha está en el pasado se aplica de inmediato. Cada entrada en su JSON nombra un user_id, y la entrada en la cadena de Kues nombra user_id 1, el administrador, por lo que WordPress adopta temporalmente esa identidad para aplicar el cambio. El primer cambio es una actualización aparentemente inofensiva a nav_menus_created_posts.

Sexto, reproduce la solicitud con esa identidad.Publicar una entrada dispara una acción con nombre dinámico, {status}_{post_type}. Como la entrada está fabricada, ese estado y tipo pueden ser cualquier cosa, incluidos parse y request, lo que produce el hook parse_request y reinicia la canalización de solicitudes desde el principio mientras la identidad de administrador prestada aún se mantiene. La solicitud por lotes original contenía una subsolicitud que creaba un nuevo administrador; falló en la primera pasada como invitado y tiene éxito en la reproducción. A partir de ahí, el atacante inicia sesión con esa nueva cuenta y sube un plugin de puerta trasera desde un archivo ZIP, lo que constituye ejecución de código.

La técnica tiene una condición asociada. The Hacker News, citando a Cloudflare, informó que CVE-2026-63030 permite la ejecución remota de código solo cuando no se utiliza una caché de objetos persistente; la inyección en sí está presente desde WordPress 6.8, mientras que la cadena completa requiere 6.9 o posterior. Una instalación estándar no tiene caché de objetos persistente, por lo que la expresión «sin precondiciones» de Searchlight y la salvedad de Cloudflare describen el mismo caso predeterminado desde perspectivas diferentes.

Lo que establecen los documentos primarios

Los propios avisos de WordPress son la corroboración más sólida, porque en ellos el proveedor admite la mecánica y entrega la corrección. GHSA-ff9f-jf42-662q, calificado como crítico, describe una debilidad de confusión de rutas por lotes de la API REST en WordPress 6.9 y versiones posteriores que se combina con la inyección para lograr la ejecución de código, y atribuye el crédito a Adam Kues, de Assetnote y Searchlight Cyber. GHSA-fpp7-x2x2-2mjf, calificado como moderado, describe la author__not_in inyección desde WordPress 6.8 y versiones posteriores, y afirma que ambos problemas están corregidos en WordPress 7.0.2, WordPress 6.9.5, WordPress 6.8.6 y WordPress 7.1 beta2. Los registros del NVD para las dos CVE, puntuados por el CNA de WPScan y no por NIST, tienen 9.8 para CVE-2026-63030 con el vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, y 5.9 para CVE-2026-60137 con AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N — un fallo alcanzable desde la red y que no requiere privilegios en el primer caso, y uno que requiere alta complejidad de ataque y que solo produce impacto sobre la confidencialidad en el segundo. El propio campo de severidad del archivo para esta entrada indica «alta», mientras que WordPress etiqueta el fallo por lotes como crítico; son dos escalas separadas aplicadas a una cadena completa y a un único componente, no un desacuerdo sobre los fallos en sí.

Las entradas del catálogo de CISA, tal como se reflejan en los campos de enriquecimiento de NVD, se añadieron el 21 de julio de 2026 con plazos de remediación del 24 de julio para CVE-2026-63030 y del 4 de agosto para CVE-2026-60137. CISA denomina a la primera "WordPress Core Interpretation Conflict Vulnerability" y a la segunda "WordPress Core SQL Injection Vulnerability". Searchlight también publicó un verificador público en wp2shell.com para que los operadores pudieran probar una instancia sin esperar la firma de un escáner.

La reproducción independiente está documentada por la propia Searchlight y, por lo tanto, constituye una afirmación sobre terceros más que un relato de terceros: {{1}}Calif y Hacktron reconstruyeron la cadena completa antes de que aparecieran otras pruebas de concepto en GitHub{{/1}}, según el informe del 20 de julio. {{2}}Lo que es verificable de forma independiente es el efecto{{/2}} — pruebas de concepto, tráfico de explotación y telemetría de proveedores en cuestión de días, que se cubren a continuación.

Lo que se afirma pero no se establece

Dos créditos para una misma inyección no concuerdan en el registro público. El aviso de WordPress para CVE-2026-60137 señala que la falla fue «descubierta y divulgada de forma responsable como equipo por TF1T, dtro y haongo». El relato de Searchlight presenta la misma inyección previa a la autenticación como lo que surgió de su ejecución del modelo, y no menciona a ese equipo; el aviso de WordPress atribuye Kues solo la confusión de la ruta por lotes, y no menciona un modelo. Ninguno de los dos documentos explica la superposición, y nada de lo que este artículo localizó lo resuelve; no se excluye la posibilidad de que los dos fueran hallazgos independientes del mismo error, y tampoco se establece la posibilidad de que uno de los informes sea un redescubrimiento posterior. El registro no lo resuelve, y este artículo tampoco.

La cifra del titular en la publicación de Searchlight del 20 de julio no está respaldada por su propio cuerpo. Dice: «Los intermediarios de exploits pagan $500,000 por una RCE de WordPress. Encontré una con GPT5.6 Sol Ultra y $25». El cuerpo documenta los $25 y las diez horas en términos concretos; no incluye nombres de intermediarios, ni ofertas, ni correspondencia, ni fuente alguna para la cifra de $500,000. No se encontró ningún informe independiente sobre este artículo que corrobore un precio pagado u ofrecido por wp2shell. Lea los $500,000 como el encuadre del titular, no como un precio de mercado establecido.

El alcance propio de la entrada del archivo es más limitado que la historia que la rodea. Registra un hallazgo de investigación correspondiente al día de la divulgación, no señala ningún daño en el mundo real y está fechada en un solo día, 17 de julio de 2026. Eso no significa afirmar que no ocurrió nada después: se informó de tráfico de explotación en cuestión de horas tras el aviso, y CISA catalogó ambas CVE cuatro días después. La marca abarca lo que describe la entrada —el descubrimiento y la divulgación coordinada— y la explotación posterior está documentada por otras partes con base en sus propias pruebas, más abajo.

Explotación después del aviso

Jake Knott, investigador principal de seguridad en watchTowr, dijo a The Hacker News que "en las primeras horas de la madrugada del sábado (UTC), la explotación exitosa ya estaba claramente en marcha, utilizando inicialmente código de exploit público para exfiltrar credenciales hash, y la ejecución remota de código llegó después, una vez que se hicieron públicos más detalles". El mismo informe cita telemetría de KEVIntel que vincula 13 direcciones IP únicas, procedentes de Suiza, Alemania, Reino Unido, Indonesia, Lituania, Países Bajos y Singapur, con la explotación de CVE-2026-63030, y cita al fundador de KEVIntel, Ryan Dewhurst, diciendo que las solicitudes coincidían con pruebas de concepto disponibles públicamente y que se utilizaron payloads ciegos, basados en UNION y booleanos.

Los investigadores de Wiz, Shahar Dorfman y Gili Tikochinski, en una publicación del 20 de julio, pusieron cifras a la situación: el 60% de las organizaciones que usaban WordPress tenían al menos una instancia vulnerable en el momento en que se publicaron las CVE, y el 25% exponían a internet un servidor vulnerable, porcentajes que cayeron al 50% y al 10% en un plazo de 24 horas a medida que comenzaron los parcheos. Registraron cargas maliciosas de plugins a través del instalador de administración, enumeración de usuarios contra el endpoint de usuarios, intentos de inclusión local de archivos contra wp-config, y accesos al panel de administración que devolvían HTTP 200 — la firma de un inicio de sesión exitoso y no de una sonda. El malware que encontraron abarcaba desde una puerta trasera PHP mínima de una sola línea hasta un webshell de 150 KB disfrazado como un plugin de seguridad legítimo de WordPress llamado CMSmap, con módulos de gestión de archivos, acceso a bases de datos, escaneo de puertos y escalada de privilegios.

Wiz también registró un límite sobre lo que se puede concluir. El escaneo de alto volumen sin explotación posterior era común, lo que concuerda con el escaneo masivo oportunista y con el escaneo de seguridad legítimo, y la empresa declaró que no había identificado movimiento lateral ni exfiltración de datos. Eso es una afirmación sobre lo que mostró la telemetría de un proveedor, no una conclusión de que no se tomó nada.

¿Qué cambió después, y qué quedó abierto?

Para los operadores, la ruta de respuesta fue corta. Actualizar a WordPress 7.0.2, WordPress 6.9.5 o WordPress 6.8.6 es la solución. Las alternativas de emergencia de Searchlight, para los sitios que no podían actualizarse de inmediato, consistían en bloquear el acceso anónimo a la API batch — ya sea instalando un plugin que bloquee por completo el acceso anónimo a la API REST, o bloqueando /wp-json/batch/v1 y ?rest_route=/batch/v1 en un firewall de aplicaciones web. La empresa advirtió que ambas medidas pueden afectar el uso legítimo del sitio y deben tratarse como medidas temporales hasta que llegue la actualización. El verificador público en wp2shell.com prueba una instancia directamente. Las entradas del catálogo de CISA añadieron un plazo de cumplimiento: remediación antes del 24 de julio para CVE-2026-63030 y antes del 4 de agosto para CVE-2026-60137.

Para la pregunta de investigación, la parte que quedó sin resolver es qué aportó realmente el modelo en relación con su operador. Kues es preciso sobre la división: el modelo produjo la cadena en aproximadamente diez horas, y comprenderla le llevó más tiempo que generarla. Rechaza las afirmaciones generales y dice solo que el resultado de diez horas no podía alcanzarlo un humano sin ayuda. El prompt en sí no es un secreto — deriva de uno que OpenAI publicó, y Searchlight reprodujo su estructura en el informe, incluida la instrucción de ignorar el historial de versiones y el requisito de que el exploit funcione en una configuración de producción típica. Si esa receta es transferible a otras bases de código es exactamente la pregunta que Kues dice que no está respondiendo, y no se ha publicado una segunda ejecución.

Lo que el registro deja sin establecer es, por tanto, limitado pero de gran trascendencia: cuál de las dos partes a las que se atribuye el hallazgo encontró primero la inyección, si algún bróker llegó a pagar alguna vez la cifra del titular y qué, en su caso, extrajeron realmente los webshells que Wiz observó de los sitios en los que se alojaron. Sobre el último punto, la única declaración pública es la de Wiz: que no ha identificado movimiento lateral ni exfiltración de datos —una ausencia de pruebas desde un único punto de observación, presentada como tal.