Cómo puede funcionar esto

En qué se diferencia este PoC de los exploits públicos de wp2shell

Todos los PoC weaponizan los mismos dos bugs: la confusión de rutas del batch REST (CVE-2026-63030) y la inyección SQL author__not_in (CVE-2026-60137), con la misma forma de batch doblemente anidado. Lo que difiere entre ellos es la ruta de RCE elegida, las precondiciones del entorno y los valores de seguridad por defecto. Este documento establece, de forma concreta, dónde se sitúa la implementación de este repositorio en ese panorama.

La versión corta

1. Funciona detrás de una caché de objetos persistente. Los PoC públicos basados en UNION usan la forma de inyección con base poblada: la implementación de cadena completa que comparte este linaje da falsos negativos allí, y el unificador de un solo archivo enumera "sin caché de objetos persistente" como precondición explícita. La forma de base eliminada de este repo mantiene vivo el canal UNION - y por tanto todo el puente de RCE pre-autenticación - exactamente en esos hosts (la configuración habitual de WordPress gestionado). Ver §1.
2. Seguro para ejecutar contra producción por defecto. check no envía payload SQL a menos que se le pida; todo el tráfico puede llevar una etiqueta de atribución; todo lo que el comando shell escribe en el objetivo se elimina automáticamente después. Ver §3.

Tabla comparativa

[1] Solo timing/a ciegas como canal de lectura; la primitiva UNION de post falso existe dentro del puente pero no se expone como oráculo de extracción. [2] El sondeo de disponibilidad ingenuo (0) UNION SELECT …) se descarta silenciosamente durante la hidratación de la caché de objetos, available() devuelve false y todo el puente pre-autenticación se aborta - ver §1. [3] El propio README del proyecto enumera "sin caché de objetos persistente (Redis/Memcached)" entre las Precondiciones. [4] Variante pública disponible en Sploitus (enlace abajo): lectura a ciegas más un dropper INTO OUTFILE como paso de RCE, usando un carrier de categorías per_page=-1. [5] La ruta RCE por OUTFILE no depende del renderizado de post falso, por lo que las cachés de objetos no la bloquean - lo hacen el privilegio FILE de MySQL y un directorio compartido escribible. El hosting gestionado casi nunca concede FILE al usuario de la BD de WordPress, y secure_file_priv suele estar establecido.

1. El problema de la caché de objetos (el verdadero diferenciador)

La primitiva UNION de post falso depende de cómo WP_Query devuelve las filas:

• Modo fila completa - el SQL devuelve filas wp_posts completas; una fila inyectada por UNION se convierte directamente en un WP_Post. La falsificación se renderiza.
• Modo dividido (solo IDs) - el SQL devuelve solo IDs, y cada ID se hidrata después a través de la caché de objetos persistente / base de datos. El ID de la fila falsificada no existe, por lo que la hidratación la descarta silenciosamente. Sin error, sin post falsificado.

En hosts con caché de objetos persistente, un conjunto de resultados base poblado empuja a WP_Query al modo dividido. El sondeo estándar usado por los PoC públicos -

0) UNION SELECT <forged row> -- -

• deja el conjunto base poblado (post_author NOT IN (0) coincide con todas las filas), por lo que detrás de una caché de objetos la fila falsificada se evapora: el sondeo de disponibilidad da falso negativo, available() devuelve false y todo el puente pre-autenticación se reporta "muerto" en un host que de hecho es totalmente explotable. El unificador público documenta el mismo límite enumerando "sin caché de objetos persistente" como precondición estricta.

Este repo vacía el conjunto base en su lugar:

1) AND 1=0 UNION ALL SELECT <forged row> -- -

Con cero filas base, la fila falsificada es la única fila; la consulta permanece en modo fila completa; nunca se ejecuta una búsqueda de hidratación. Una palabra clave inyectada (AND 1=0) es toda la diferencia entre "canal UNION muerto" y "RCE pre-autenticación completo" en hosts con caché de objetos - que son la mayoría de los entornos de producción de WordPress gestionado. El diagnóstico, la matriz de sondeos (per_page × forma de inyección).

Nota de alcance: el canal de lectura a ciegas/timing no es sensible a la caché de objetos (contar filas en SQL no implica hidratación de post falso), por lo que la lectura a ciegas de cada PoC funciona en todas partes. Lo que la caché de objetos mata en los otros PoC es específicamente la parte dependiente de UNION: la extracción en banda y el puente SQLi-a-admin.

Una segunda lección relacionada documentada en el caso de estudio: cuando ambos canales funcionan, trate la lectura UNION en banda como autoritativa - el oráculo de timing en producción produjo bit flips bajo jitter en un valor que la lectura en banda resolvió sin ambigüedad.

2. Elección de la ruta de RCE

Existen tres rutas de RCE pre-autenticación en los PoC públicos:

Este repo implementa el puente: no necesita privilegios de base de datos más allá de los que WordPress ya tiene, funciona cuando los niveles de BD y web no comparten nada, y no deja ningún archivo del que dependa la ruta del privilegio FILE. El trade-off es la complejidad - el puente es un grafo de posts envenenados de siete filas - que es exactamente donde el falso negativo de caché de objetos de la §1 solía ocultar la ruta.

3. Valores de seguridad por defecto para uso autorizado

Construido para ejecutarse contra sistemas en producción bajo autorización, no solo laboratorios:

• check no es destructivo por defecto - huella pasiva más un batch de marcadores benigno; no se envía payload SQL a menos que se indique --confirm-sqli. Después de parchear, el trío de marcadores que desaparece sirve además como validación de la corrección.
• Etiquetado de atribución - --user-agent en cada comando para que todo el tráfico del exploit sea identificable en los logs (una regla práctica de engagement que las herramientas públicas no aplican por defecto).
• Limpieza automática - la webshell está bloqueada por token bajo una ruta aleatorizada y se elimina a sí misma; un administrador creado vía el puente se elimina después con su contenido reasignado a la cuenta admin prestada. El fallo de la limpieza se reporta de forma visible, no se silencia.
• Contabilidad de peticiones - cada comando imprime cuántas peticiones ha enviado.

4. Lo que este repo no afirma

• No es una nueva vulnerabilidad. Ambos bugs son los CVE divulgados públicamente; la forma de batch doblemente anidado, el sink author_exclude → author__not_in, la primitiva UNION de WP_Post falso y el concepto del puente customizer son todas técnicas públicas (linaje reconocido abajo).
• No es una nueva primitiva de explotación. El delta respecto al panorama público es: la corrección de caché de objetos con base eliminada con evidencia de producción, los valores por defecto seguros para producción y la documentación de detección - robustez y seguridad operativa, no novedad de técnica.
• Las cadenas IoC son arbitrarias. Los prefijos de login, los slugs de plugins, los marcadores de shell y los valores de User-Agent difieren en cada variante y por ejecución;

Referencias

• Icex0/wp2shell-poc - implementación de cadena completa que comparte el linaje de este repo - https://github.com/Icex0/wp2shell-poc
• sergiointel/wp2shell-poc - primer PoC público; origen de la técnica de creación de admin sin crackeo - https://github.com/sergiointel/wp2shell-poc
• 0xsha/wp2shell - unificador de un solo archivo de seis PoC públicos, con laboratorios Docker y una matriz versión×BD (documenta la precondición de caché de objetos) - https://github.com/0xsha/wp2shell
• Variante OUTFILE (lectura a ciegas + dropper INTO OUTFILE), disponible en Sploitus - https://sploitus.com/exploit?id=7CD079AD-E27B-5C54-A696-60635BFDB241
• Lista curada de PoC públicos y verificadores (para defensores) - https://www.cyberkendra.com/2026/07/wp2shell-guide.html
• GHSA-ff9f-jf42-662q / GHSA-fpp7-x2x2-2mjf; anuncio del lanzamiento de WordPress 7.0.2 - ver referencias en README.md.