wp2shell

💙 Apoya el Proyecto

Si aprecias mi trabajo, considera apoyar el proyecto mediante USDT (TRC20): TQBA72kakjCZLnJt8fJYcD7dyQCEpzNtVN

Cadena RCE de Pre-Autenticación en WordPress Core

wp2shell es una prueba de concepto de investigación de seguridad que demuestra una cadena de vulnerabilidades de pre-autenticación en WordPress Core que combina:

CVE-2026-63030 — Confusión de rutas del lote de la API REST
CVE-2026-60137 — Inyección SQL en WP_Query

La cadena demuestra cómo estas vulnerabilidades pueden combinarse para pasar de una solicitud no autenticada a la API REST a una inyección SQL, escalada de privilegios, creación de cuentas de administrador y, finalmente, ejecución remota de código autenticada.

[!WARNING]

Solo Investigación de Seguridad Autorizada

Este proyecto está destinado a:

Investigación de vulnerabilidades

Validación defensiva

Pruebas de penetración autorizadas

The PoC is implemented as a Python research tool and uses the Python standard library without requiring third-party Python packages. --- # Vulnerability Chain The project combines two WordPress Core vulnerabilities.```text Unauthenticated Request | v +----------------------+ | CVE-2026-63030 | | REST Batch Route | | Confusion | +----------+-----------+ | v Validation Confusion | v +----------------------+ | CVE-2026-60137 | | WP_Query SQLi | +----------+-----------+ | v Blind SQLi | v Application-State Abuse | v Privilege Escalation | v Administrator Access | v Authenticated RCE ``` The important security property is the interaction between the two vulnerabilities rather than either vulnerability in isolation. --- # CVE-2026-63030 ## Confusión de rutas en el endpoint REST API Batch La primera vulnerabilidad afecta al procesamiento de solicitudes a través del endpoint REST API Batch de WordPress. La implementación del procesamiento por lotes mantiene la información de coincidencia y validación de solicitudes en estructuras paralelas indexadas por la posición de la solicitud. Una sub-solicitud malformada puede hacer que esas estructuras se desincronicen. Esto crea una condición de despacho off-by-one en la que una solicitud posterior puede procesarse utilizando un controlador o contexto de validación asociado a otra solicitud. Conceptualmente:```text Request A | +-- validation entry +-- matching entry | v Malformed request | +-- internal state becomes desynchronized | v Request B | +-- unexpected handler / validation context ``` El PoC realiza comprobaciones de comportamiento para determinar si la confusión de ruta es realmente alcanzable. --- # CVE-2026-60137 ## Inyección SQL en WP_Query La segunda vulnerabilidad afecta a una ruta de procesamiento SQL de `WP_Query`. Una vez establecida la primitiva de confusión de ruta, la entrada controlada por el atacante puede alcanzar la ruta de consulta vulnerable. El PoC demuestra la inyección SQL resultante mediante pruebas diferenciales ciegas. La funcionalidad de investigación incluye: * Confirmación booleana ciega * Corroboración opcional basada en tiempo * Huella digital de la base de datos * Extracción de escalares soportada * Investigación de datos de usuario de WordPress --- # Cómo funciona la cadena ## 1. Confusión de Ruta en REST Batch Una solicitud no autenticada llega al endpoint REST Batch de WordPress. Una sub-solicitud de lote malformada provoca que la coincidencia de solicitudes interna y el estado de validación se desincronicen. Una solicitud posterior puede, en consecuencia, procesarse utilizando un contexto no previsto. --- ## 2. Inyección SQL La primitiva de confusión de ruta proporciona la ruta necesaria para la segunda vulnerabilidad. Un valor controlado por el atacante puede alcanzar la ruta de procesamiento vulnerable de `WP_Query`. Esto crea una primitiva de inyección SQL ciega. --- ## 3. Extracción SQL ciega La inyección SQL puede utilizarse como un canal de extracción ciego booleano. El PoC contiene funcionalidad para investigar información de la base de datos e información de usuario de WordPress soportada. --- ## 4. Manipulación del estado de la aplicación La cadena utiliza resultados controlados por la base de datos para influir en los objetos de la aplicación WordPress y en el procesamiento posterior. Esto proporciona las primitivas necesarias para la etapa de escalada de privilegios. --- ## 5. Escalada de Changeset La cadena utiliza el procesamiento de changesets de WordPress para establecer un contexto de ejecución de administrador. Un objeto `customize_changeset` fabricado puede participar en la secuencia de escalada de privilegios. --- ## 6. Reentrada de Hook La cadena reingresa al procesamiento de solicitudes de WordPress a través del ciclo de vida de solicitudes de la aplicación. Esto permite que el procesamiento posterior de la API ocurra bajo el contexto elevado. --- ## 7. Creación de cuenta de administrador El PoC de investigación implementa una etapa de creación de administrador previa a la autenticación. Esta es la razón clave por la que el Modo 3 es útil para la validación de seguridad: demuestra el impacto de la escalada de privilegios sin continuar hacia la etapa de webshell/RCE. --- ## 8. Ejecución de código autenticada El Modo 4 extiende la cadena de investigación más allá de la creación de administrador hacia la etapa de ejecución de código autenticada. Esta etapa solo debe utilizarse en un laboratorio aislado o en una evaluación explícitamente autorizada. --- # Versiones afectadas ## Cadena completa previa a la autenticación | Versión de WordPress | Estado | | ----------------- | -------------- | | 6.9.0 – 6.9.4 | **Vulnerable** | | 7.0.0 – 7.0.1 | **Vulnerable** | | 6.9.5 | **Corregido** | | 7.0.2+ | **Corregido** | El PoC identifica `6.9.0–6.9.4` y `7.0.0–7.0.1` como las versiones vulnerables documentadas de la cadena completa. ## Inyección SQL El componente de inyección SQL tiene un límite de versión corregida diferente al de la cadena completa. La implementación de la investigación identifica `6.8.6` como la corrección de la inyección SQL. La cadena completa no autenticada depende adicionalmente del comportamiento vulnerable de REST Batch. Verifique siempre las versiones afectadas y corregidas contra el aviso de seguridad oficial correspondiente antes de tomar decisiones de producción. --- # Precondiciones El PoC documenta estas condiciones para la cadena completa: * La API REST de WordPress es accesible * Sin caché de objetos Redis/Memcached * Al menos una entrada publicada Otros componentes del despliegue pueden afectar la reproducibilidad: * Proxies inversos * Firewalls de aplicaciones web * Restricciones de la API REST * Plugins de seguridad * Caché de objetos * Filtrado HTTP * Configuración de hosting Una instalación de WordPress que coincida con el rango de versiones no significa automáticamente que la cadena completa funcione en todos los entornos. --- # Características `wp2shell` proporciona un menú interactivo que contiene las siguientes funciones de investigación:```text [1] Fingerprint + confirm vulnerability (non-destructive) [2] Blind SQL extraction (fingerprint / dump users) [3] Pre-Auth Admin creation [4] Full RCE chain → admin creation + webshell [5] Facilitated sink SQLi (WordPress 6.8.x / custom) [6] Threaded scan over URL list [7] Transport settings (proxy, TLS, timeout, delay) [8] Change target URL [0] Quit ``` --- # Menú interactivo El menú principal está diseñado para admitir ambos: * Probar una única instalación autorizada de WordPress * Probar una lista autorizada de URLs de WordPress El flujo de trabajo puede usarse, por lo tanto, tanto para objetivos de investigación individuales como para conjuntos de datos de evaluación autorizados más grandes. --- # Modo recomendado — Modo 3 ## ¿Por qué el Modo 3? Para la investigación de vulnerabilidades, **el Modo 3 es el modo recomendado cuando el objetivo es demostrar el impacto de seguridad sin implementar una webshell**. El Modo 3 es:```text Pre-Auth Admin Creation ``` El PoC describe esta etapa como:```text Unauthenticated UNION SQLi → new WordPress administrator ``` y lo distingue explícitamente de la etapa completa de webshell/RCE:```text No password cracking. No webshell. Non-destructive admin only. ``` Esto hace que Mode 3 sea particularmente útil cuando quieres demostrar que la cadena de vulnerabilidades alcanza un compromiso a nivel de administrador, evitando a la vez la etapa adicional de ejecución de código. --- # Mode 3 — Pre-Auth Admin Creation Seleccionar Mode 3 abre:```text ──────────────────────────────────────────────────────────── CREATE ADMIN — Pre-Auth Admin RCE Chain ──────────────────────────────────────────────────────────── ⚠ Unauthenticated UNION SQLi → new WordPress administrator. ⚠ No password cracking. No webshell. Non-destructive admin only. ``` A continuación, el PoC solicita varias opciones de entorno y salida. ## SQLite```text → Target uses SQLite? (WP-SQLite plugin) (y/N) [n]: ``` Establezca esto en `y` cuando el objetivo autorizado utilice una configuración de WordPress SQLite compatible con el PoC. Para instalaciones normales de WordPress con MySQL/MariaDB, el valor predeterminado es:```text n ``` --- ## Verificación de Credenciales El PoC puede verificar opcionalmente las credenciales generadas al intentar un inicio de sesión autenticado:```text → Verify the generated credentials by logging in? (Y/n) [y]: ``` El valor predeterminado es:```text y ``` Esto es útil cuando quieres que el resultado incluya la confirmación de que las credenciales de administrador generadas realmente autentican. --- ## Archivo de salida El modo 3 puede guardar los resultados en un archivo local:```text → Output file (blank = skip, e.g. result.txt): ``` Por ejemplo:```text logs.txt ``` Dejar el campo vacío omite la salida de archivo. La opción de salida es útil al realizar investigaciones autorizadas en múltiples objetivos y querer conservar los resultados para un análisis posterior. --- ## Portador de Confusión El PoC proporciona dos variantes de portador:```text → Confusion carrier variant (posts/categories) [posts]: ``` Opciones disponibles:```text posts categories ``` El valor predeterminado es:```text posts ``` La variante `posts` es la ruta principal documentada. --- # Modo 1 — Huella digital y confirmación El modo 1 es:```text [1] Fingerprint + confirm vulnerability (non-destructive) ``` Esta es la forma más segura de comenzar la validación de vulnerabilidades. Se centra en determinar si el objetivo presenta las condiciones de comportamiento asociadas con la cadena de vulnerabilidades. La etapa de comprobación puede incluir: * Huella digital de WordPress * Comprobaciones del endpoint REST Batch * Confirmación de confusión de rutas * Confirmación de inyección SQL * Pruebas diferenciales de ciega booleana * Corroboración opcional basada en tiempo Use el Modo 1 cuando el objetivo principal sea:```text "Is this target potentially vulnerable?" ``` en lugar de demostrar el impacto del administrador. --- # Modo 2 — Extracción SQL a ciegas El Modo 2 es:```text [2] Blind SQL extraction (fingerprint / dump users) ``` Este modo demuestra la primitiva de inyección SQL mediante extracción ciega. La funcionalidad de investigación incluye: * Huella digital de la base de datos * Versión de la base de datos * Usuario de la base de datos * Nombre de la base de datos * Expresiones escalares SQL compatibles * Información de usuarios de WordPress Use este modo únicamente en un entorno autorizado porque demuestra el impacto del acceso a datos en lugar de simplemente detectar la vulnerabilidad. --- # Modo 3 — Creación de administrador sin autenticación El modo 3 es:```text [3] Pre-Auth Admin creation ``` Este modo demuestra el impacto de escalada de privilegios de la cadena. La distinción importante es:```text Mode 3 | +-- Pre-authentication chain +-- Administrator creation +-- Optional login verification +-- No password cracking +-- No webshell ``` Para los investigadores de seguridad que necesitan demostrar el impacto a nivel de administrador de la vulnerabilidad sin implementar un webshell, este es el modo preferido. --- # Modo 4 — Cadena RCE completa El Modo 4 es:```text [4] Full RCE chain → admin creation + webshell ``` Esto extiende la cadena más allá de la creación de administrador hacia la ejecución de código autenticada. Conceptualmente:```text Unauthenticated ↓ Route Confusion ↓ SQL Injection ↓ Privilege Escalation ↓ Administrator Creation ↓ Administrator Authentication ↓ Webshell ↓ Code Execution ``` Este modo debe restringirse a laboratorios aislados y pruebas de penetración explícitamente autorizadas. Para la validación ordinaria de vulnerabilidades, el Modo 3 es preferible porque demuestra el límite del impacto del administrador sin desplegar una webshell. --- # Modo 5 — Facilitated Sink SQLi El Modo 5 es:```text [5] Facilitated sink SQLi (WordPress 6.8.x / custom) ``` Este modo está pensado para la investigación que involucra el sumidero de inyección SQL fuera de la cadena completa de preautenticación. Es útil para investigadores que investigan: * Entornos WordPress 6.8.x * Configuraciones personalizadas * La primitiva de inyección SQL de forma independiente * Reproducción de vulnerabilidades * Validación defensiva --- # Modo 6 — Escaneo de URL con subprocesos El modo 6 es:```text [6] Threaded scan over URL list ``` Este modo está destinado a evaluaciones autorizadas que involucran múltiples objetivos WordPress. En lugar de probar manualmente una URL a la vez, la herramienta puede procesar una lista de URLs usando hilos de trabajo. Conceptualmente:```text urls.txt | +-- URL 1 +-- URL 2 +-- URL 3 +-- URL 4 +-- ... | v Threaded vulnerability checks | v Results ``` La funcionalidad de escaneo puede usar opciones como: * Número de hilos de trabajo (worker threads) * Retardo de confirmación * Prueba de versión opcional * Salida de informe JSON * Variante de portador de confusión (confusion carrier) Utilice esto solo con listas de URL para las cuales tenga autorización explícita. --- # Objetivo único vs Lista de URL `wp2shell` se puede usar de dos maneras generales. ## Objetivo único de WordPress Utilice un solo objetivo cuando investigue una instalación. Casos de uso típicos: * Laboratorio local * Entorno de preparación (staging) * Prueba de penetración aprobada por el cliente * Reproducción de vulnerabilidades * Verificación de CVE El objetivo debe ser una URL base de WordPress. --- ## Lista de URL Para múltiples objetivos autorizados, el Modo 6 puede procesar una lista de URL. Ejemplo de archivo conceptual:```text https://wordpress-lab-01.example https://wordpress-lab-02.example https://wordpress-lab-03.example https://wordpress-lab-04.example ``` El escáner multihilo puede procesar entonces la lista y registrar los resultados. La implementación del escaneo también admite una opción de salida/informe para conservar los hallazgos. --- # Guía de selección de modos | Objetivo | Modo recomendado | | -------------------------------------- | ---------------- | | Comprobar si un objetivo es vulnerable | **Modo 1** | | Demostrar inyección SQL | **Modo 2** | | Demostrar impacto a nivel de administrador | **Modo 3** | | Demostrar una cadena RCE completa | **Modo 4** | | Investigar el sink de SQLi de forma independiente | **Modo 5** | | Probar una lista de URL autorizadas | **Modo 6** | | Configurar proxy/TLS/timeout/delay | **Modo 7** | | Cambiar el objetivo actual | **Modo 8** | ### Flujo de trabajo de investigación recomendado Para la mayoría de las evaluaciones de seguridad:```text Mode 1 ↓ Confirm vulnerability ↓ Mode 3 ↓ Demonstrate administrator impact ``` Solo continúa al Mode 4 cuando la validación completa de ejecución de código se requiera y autorice explícitamente. --- # Mode 7 — Configuración de transporte Mode 7 es:```text [7] Transport settings (proxy, TLS, timeout, delay) ``` Esta sección controla el comportamiento del transporte HTTP utilizado por la herramienta. Los ajustes de investigación admitidos incluyen: * Configuración de proxy * Comportamiento de TLS * Tiempo de espera de solicitud * Retardo de solicitud * Comportamiento de conexión/reintento Estas opciones son útiles al probar instalaciones de WordPress detrás de: * Proxies * Configuraciones TLS * Conexiones lentas * Infraestructura de limitación de tasa * Entornos de laboratorio controlados --- # Modo 8 — Cambiar URL de destino El Modo 8 es:```text [8] Change target URL ``` Esto permite cambiar el objetivo actualmente seleccionado sin reiniciar todo el flujo de trabajo interactivo. Es útil al moverse entre instalaciones de laboratorio autorizadas. --- # Lógica de Detección El PoC utiliza comprobaciones de comportamiento en lugar de depender exclusivamente de una cadena de versión de WordPress. ## Detección de REST Batch La herramienta verifica que el endpoint de REST Batch sea accesible. ## Detección de Confusión de Rutas La herramienta puede utilizar: * Marcadores de respuesta * Comportamiento estructural de la respuesta El enfoque estructural comprueba si una solicitud destinada a una colección REST se procesa como otra colección. ## Detección de Inyección SQL La herramienta puede realizar un diferencial a ciegas de tipo booleano. Además, se puede utilizar un canal basado en tiempo como corroboración. --- # Cadena Técnica La cadena de investigación completa se puede resumir como:```text 1. REST API reachable | v 2. Batch route confusion | v 3. Validation / dispatch confusion | v 4. SQL injection reaches WP_Query | v 5. Blind SQL channel | v 6. Application-state manipulation | v 7. Changeset privilege escalation | v 8. Administrator context | v 9. Administrator account creation | v 10. Authenticated code execution ``` --- # Variantes de Ruta El PoC admite dos variantes de portador de confusión:```text posts categories ``` El valor predeterminado es:```text posts ``` La variante `posts` es el medio principal documentado de extremo a extremo. La variante `categories` proporciona una ruta alternativa de confusión de rutas para investigación. --- # Soporte SQLite El PoC contiene soporte de compatibilidad con SQLite para entornos que utilizan una configuración SQLite de WordPress. El modo 3 expone esta opción como:```text Target uses SQLite? (WP-SQLite plugin) ``` Predeterminado:```text n ``` Uso:```text y ``` cuando el objetivo autorizado utiliza la configuración SQLite compatible. --- # Instalación El PoC utiliza la biblioteca estándar de Python. No se requieren paquetes de Python de terceros. Entorno requerido:```text Python 3.x ``` Clona el repositorio y ejecuta la herramienta de investigación dentro de un entorno aislado o explícitamente autorizado. --- # Estructura del Proyecto Una estructura de repositorio recomendada es:```text wp2shell/ │ ├── wp2shell.py ├── README.md ├── LICENSE └── screenshots/ ``` La implementación principal de la investigación es:```text wp2shell.py ``` --- # Impacto de Seguridad Una cadena de explotación exitosa puede potencialmente resultar en: * Inyección SQL no autenticada * Divulgación de información de la base de datos * Exposición de información de usuarios de WordPress * Escalada de privilegios * Creación de cuentas de administrador * Acceso administrativo completo a WordPress * Ejecución arbitraria de código autenticada * Posible compromiso a nivel del sistema operativo dependiendo del entorno de alojamiento Por lo tanto, la cadena completa tiene un impacto significativamente mayor que el impacto de las vulnerabilidades individuales consideradas de forma independiente. --- # Detección Defensiva Los administradores deben investigar actividades sospechosas que involucren: * Endpoints REST Batch de WordPress * Solicitudes batch anidadas anormales * Rutas de solicitudes batch malformadas * Parámetros de consulta sospechosos * Creación inesperada de cuentas de administrador * Actividad inesperada de `customize_changeset` * Instalaciones inesperadas de plugins * Archivos PHP inesperados * Modificaciones sospechosas de plugins * Comportamiento similar a webshell Revisión:```text Web server logs + WordPress logs + Database audit logs + File integrity monitoring ``` especialmente alrededor del momento de la supuesta explotación. --- # Mitigación La mitigación principal es actualizar WordPress a una versión corregida. Las instalaciones afectadas también deberían: 1. Revisar todas las cuentas de administrador. 2. Eliminar cuentas de administrador no autorizadas. 3. Revisar los plugins instalados o modificados recientemente. 4. Revisar los registros de la API REST de WordPress. 5. Revisar los registros de acceso del servidor web. 6. Buscar archivos PHP inesperados. 7. Comprobar los directorios de plugins en busca de modificaciones no autorizadas. 8. Rotar las credenciales si se sospecha de un compromiso. 9. Revisar la integridad de la base de datos. 10. Eliminar los mecanismos de persistencia. 11. Reinstalar los componentes de WordPress comprometidos desde fuentes de confianza cuando corresponda. --- # Flujo de trabajo de investigación responsable Para una evaluación autorizada normal, la progresión recomendada es:```text START | v ┌─────────────────┐ │ MODE 1 │ │ Detect / Confirm│ └────────┬────────┘ | Vulnerable? / \ No Yes | | STOP v ┌───────────────┐ │ MODE 3 │ │ Admin Impact │ └───────┬───────┘ | Need full RCE? / \ No Yes | | STOP v ┌───────────────┐ │ MODE 4 │ │ Full RCE Lab │ └───────────────┘ ``` Mode 3 es generalmente el punto preferido de demostración de impacto porque establece un compromiso a nivel de administrador sin desplegar la etapa de webshell. --- # Investigación vs Producción Este proyecto está destinado a la investigación de seguridad controlada. No trate la herramienta como un escáner de Internet de propósito general. Para entornos de producción: * Obtenga autorización por escrito. * Defina el alcance del objetivo. * Defina las acciones permitidas. * Prefiera la verificación no destructiva. * Deténgase una vez que se haya recopilado suficiente evidencia. * Conserve los registros y las pruebas. * Siga el proceso de divulgación de vulnerabilidades aplicable. --- # Créditos Investigación / descubrimiento de vulnerabilidades: **Adam Kues** Assetnote / Searchlight Cyber Proyecto: **wp2shell** La implementación de la investigación identifica la cadena de vulnerabilidades como:```text CVE-2026-63030 + CVE-2026-60137 ``` --- # Referencias * CVE-2026-63030 * CVE-2026-60137 * GHSA-ff9f-jf42-662q * GHSA-fpp7-x2x2-2mjf * WordPress Core * WordPress REST API * WordPress `WP_Query` --- # Descargo de responsabilidad Este repositorio contiene investigación de seguridad que demuestra una cadena de vulnerabilidades que afecta a WordPress Core. El software y la documentación se proporcionan para: * Fines educativos * Investigación de seguridad * Verificación de vulnerabilidades * Pruebas defensivas * Pruebas de penetración autorizadas Los autores no son responsables del uso no autorizado o malintencionado de este material. **Solo pruebe sistemas que le pertenezcan o para los que tenga autorización explícita.** --- # Palabras clave```text wp2shell WordPress WordPress Core WordPress Security WordPress Vulnerability WordPress RCE Pre-Auth RCE Pre-Authentication RCE CVE-2026-63030 CVE-2026-60137 REST API REST Batch REST API Batch Route Confusion WP_Query SQL Injection SQLi Blind SQL Injection Privilege Escalation Administrator Creation Remote Code Execution RCE Proof of Concept PoC Security Research Penetration Testing ``` --- ## Temas del repositorio Temas recomendados para el repositorio de GitHub:```text wp2shell wordpress wordpress-core wordpress-security wordpress-vulnerability wordpress-rce cve cve-2026-63030 cve-2026-60137 poc proof-of-concept rce sql-injection sqli blind-sqli rest-api security-research penetration-testing privilege-escalation ``` --- ## Resumen del Proyecto```text wp2shell is a WordPress Core pre-authentication vulnerability-chain PoC combining CVE-2026-63030 (REST API Batch route confusion) and CVE-2026-60137 (WP_Query SQL injection), demonstrating the progression from unauthenticated access to SQL injection, privilege escalation, administrator creation, and authenticated code execution. ``` (no content provided)``` disclaimer: this project is for educational purposes only ```

wp2shell-poc

Más Populares

Tabla de Contenidos

Overview