wp2shell laboratorio y detector + PoC de RCE sin autenticación

Un laboratorio autónomo, detector no destructivo y prueba de concepto completa de RCE sin autenticación para wp2shell — la cadena de vulnerabilidades de pre-autenticación en el núcleo de WordPress:

CVE	Componente	Clase	CVSS
CVE-2026-60137	WP_Query::author__not_in	SQL injection (CWE-89)	9.1
CVE-2026-63030	REST /batch/v1 route confusion	interpretation conflict (CWE-436) → chains to RCE	7.5

Afecta: Núcleo de WordPress 6.9.0–6.9.4 y 7.0.0–7.0.1 (el sumidero SQLi solo también afecta a 6.8.0–6.8.5). Corregido en 6.8.6 / 6.9.5 / 7.0.2. Reportado por Adam Kues (Assetnote / Searchlight Cyber); SQLi también acreditado a TF1T, dtro, haongo. Cadena RCE por defecto de stock (oEmbed → changeset → reentrada) por Mustafa Can İPEKÇİ (nukedx).

Actualice primero. WordPress lanzó actualizaciones forzadas automáticas para esto. Este repositorio existe para ayudarle a verificar que su propio sitio está parcheado y a comprender el error, no para atacar a nadie. Consulte SECURITY.md.

---

Qué es realmente

La primitiva siempre verdadera es una inyección SQL sin autenticación, sin plugins, en el núcleo de stock que proporciona lectura completa de la base de datos (hashes de contraseñas de administrador, todo en wp_options/wp_users). Eso solo merece el 9.1 y un parche inmediato.

La RCE es real y funciona en WordPress por defecto de stock — sin privilegio FILE, sin caché de objetos persistente, sin plugins, sin configuraciones incorrectas requeridas. La cadena utiliza la SQLi de solo lectura como una primitiva de falsificación de filas (UNION ALL SELECT inyecta filas falsas de wp_posts), luego aprovecha el propio pipeline de renderizado de contenido de WordPress para convertir esas filas falsificadas en escrituras reales en la base de datos a través del almacenamiento en caché de oEmbed. A partir de ahí, la elevación de changeset y la parse_request reentrante se ejecutan en contexto de administrador, creando una nueva cuenta de administrador — todo desde una única solicitud HTTP sin autenticación.

La cadena completa (sin credenciales, punto de entrada único POST /?rest_route=/batch/v1)

1. Route confusion    — double-nested batch desyncs $matches/$validation so a GET
                        /wp/v2/widgets runs under posts::get_items() (public), reaching
                        WP_Query's author__not_in with attacker-controlled input.

2. Row forgery        — author__not_in is string-concatenated into SQL;
                        "1) AND 1=0 UNION ALL SELECT <23 cols> -- -" injects fake
                        WP_Post rows. per_page=-1 bypasses split_the_query (WP_Query
                        treats -1 as "no limit" → empty $limits → split=false →
                        full SELECT wp_posts.* → UNION columns match).

3. oEmbed write       — forged posts carry [embed]<self-url>[/embed]; rendering via
                        context=view makes WordPress cache real oembed_cache posts in
                        the DB (turns read-only SQLi into writes with predictable IDs).

4. Elevation+re-entry — a forged customize_changeset (user_id = real admin) plus a
                        forged post_type=request row with parent loops drives an
                        in-process re-entrant parse_request in admin context.

5. Admin creation     — POST /wp/v2/users in the same batch passes
                        current_user_can('create_users') → new administrator.

6. RCE                — login → plugin webshell upload → command execution → cleanup.

Gadgets de carga (por qué se sostiene la cadena)

La novedad es la composición, no un solo error — los gadgets individuales son comportamientos legítimos de WordPress. Nombrarlos (según el informe de Adam Kues) hace que el gráfico de filas falsificadas en exploit() sea legible y señala qué re-auditar después de que los puntos de entrada fueron parcheados:

• Reconciliación caché/BD — cuando una publicación en caché en memoria no coincide con su fila en la BD, WordPress reconcilia mediante wp_update_post() y prefiere el post_type/post_status en memoria, permitiendo que una fila oembed_cache sea re-tipificada como un post/customize_changeset real.
• Detección de ciclos que preserva post_content — el filtro wp_insert_post_parent recorre la cadena de padres; al detectar un ciclo llama a un segundo wp_update_post() que corrige el padre sin sobrescribir post_content. Ese es el eslabón crítico: permite que el post_content malicioso del changeset falsificado sobreviva. (Por eso las filas falsificadas usan bucles de padre propio/mutuo.)
• Reproducción de hooks mediante parse_request — publicar una publicación dispara do_action("{$status}_{$type}"); una fila falsificada con post_status=parse / post_type=request desencadena parse_request, re-ejecutando el pipeline del lote mientras la identidad de administrador asumida por el changeset (wp_set_current_user) aún se mantiene.

Estos gadgets permanecen presentes en WordPress parcheado — solo se cerraron los dos puntos de entrada (desincronización de lote + omisión escalar de author__not_in). Cualquier nueva primitiva que falsifique la caché de publicaciones en memoria o escriba una fila oembed_cache re-habilitaría la misma cola de toma de control de administrador.

Primitivas de escritura en tiempo de renderizado

Las cuatro primitivas de escritura en tiempo de renderizado confirmadas en vivo contra 7.0.1 — cada una falsificada como una publicación no autenticada, renderizada mediante la confusión de lote, y la escritura resultante en la BD verificada por SQLi ciega:

Primitiva	Marcado de activación	Sumidero	Identificador predicho	Verificado
oembed	[embed]<url>[/embed]	wp_posts row (oembed_cache)	post_name = md5(url+attrs)	ID de publicación creado
rss	wp:rss {feedURL}	wp_options site-transient	_site_transient_feed_<md5(url)>	option_id, 5192 B almacenado en caché
navigation	wp:navigation	wp_posts row (wp_navigation)	post_name = 'navigation' (fixed)	ID creado, slug navigation
calendar	wp:calendar	wp_options	wp_calendar_block_has_published_posts	option_id, valor '1'