wp2shell: RCE sin autenticación en el core de WordPress

wp2shell es una cadena de dos vulnerabilidades en el core de WordPress (CVE-2026-63030 y CVE-2026-60137) que, encadenadas, permiten a un atacante anónimo ejecutar código de forma remota (RCE) sobre una instalación estándar, sin autenticación, sin plugins y sin ninguna precondición especial. Afecta a las ramas 6.9.x y 7.0.x, se parcheó el 18 de julio de 2026 y en cuestión de horas aparecieron pruebas de concepto públicas. WordPress da servicio a una porción enorme de la web (se citan más de 500 millones de sitios en total), así que el potencial de explotación masiva es alto: cualquier instancia accesible y sin actualizar en una versión afectada es un objetivo.

Esta advisory de Secra resume qué es wp2shell, cómo funciona la cadena a alto nivel, las versiones afectadas y corregidas, la cronología de divulgación, cómo detectar exposición y compromiso, y las medidas de mitigación prioritarias. No incluye código de explotación funcional: el objetivo es defensivo.

Lo esencial sobre wp2shell

• Cadena de dos CVE del core de WordPress: CVE-2026-63030 (confusión de rutas en la REST API batch) y CVE-2026-60137 (inyección SQL en author__not_in de WP_Query).
• Encadenadas dan ejecución remota de código (RCE) sin autenticación sobre una instalación WordPress estándar, sin plugins.
• Versiones afectadas por la cadena completa: 6.9.0 a 6.9.4 y 7.0.0 a 7.0.1. La inyección SQL por sí sola alcanza también a 6.8.x.
• Corregidas en 6.9.5, 7.0.2 y, para el componente de inyección, en 6.8.6.
• Existen PoC públicos y se han reportado primeras señales de explotación real. Prioridad de parcheo inmediata.
• Mitigación urgente si no puedes parchear ya: bloquear /wp-json/batch/v1 y ?rest_route=/batch/v1 en el WAF y restringir la REST API a usuarios autenticados.

Qué es wp2shell

wp2shell (de "WordPress to shell") es el nombre con el que se ha divulgado una cadena de explotación descubierta en el propio núcleo de WordPress, no en un plugin ni en un tema de terceros. Ese matiz es lo que la hace excepcional: las vulnerabilidades graves de WordPress se concentran habitualmente en el ecosistema de plugins, mientras que el core recibe un escrutinio intenso. Una cadena de RCE pre-autenticación en el core, aplicable a instalaciones limpias, es un evento poco frecuente y de máximo interés tanto para defensores como para atacantes.

La cadena la reportó Adam Kues, del equipo de investigación de Assetnote (parte de Searchlight Cyber), para el componente de confusión de rutas, mientras que la inyección SQL fue reportada por los investigadores TF1T, dtro y haongo. En la divulgación inicial los investigadores retuvieron deliberadamente los detalles técnicos profundos para dar margen de parcheo a los defensores. El desglose técnico completo y las primeras pruebas de concepto se hicieron públicos después de que los parches estuvieran disponibles.

Las dos vulnerabilidades de la cadena

wp2shell no es un único fallo, sino la combinación de dos debilidades independientes que por separado tienen un impacto limitado y juntas escalan a ejecución de código.

CVE-2026-63030: confusión de rutas en la REST API batch

El endpoint /wp-json/batch/v1 (también accesible como ?rest_route=/batch/v1) permite agrupar varias subpeticiones a la REST API en una sola llamada HTTP. Conviene aclarar un punto que se ha malinterpretado: el endpoint batch existe en WordPress desde la versión 5.6 (2020). Lo nuevo en la rama 6.9 no es el endpoint, sino un error en cómo procesa el lote.

En esencia, un error en una de las subpeticiones descuadra en uno los arrays internos que WordPress usa para emparejar cada petición con su manejador. El resultado es que una subpetición acaba ejecutándose bajo el manejador de otra. Esa confusión permite eludir la lista de permitidos del endpoint y alcanzar, sin autenticación, manejadores y parámetros que en condiciones normales estarían fuera del alcance de un usuario anónimo. Es el vector de acceso que abre la puerta.

CVE-2026-60137: inyección SQL en author__not_in

La segunda pieza reside en el parámetro author__not_in de la clase WP_Query, presente desde WordPress 6.8. El código espera un array de identificadores. Si en su lugar se le entrega una cadena de texto, la comprobación de tipo que asume un array se omite y el valor sin sanear termina insertándose directamente en la consulta SQL. Es una inyección SQL de manual provocada por una validación de tipos incompleta.

Cómo se encadenan

Por separado, cada fallo tiene un techo. La confusión de rutas, aislada, da acceso a datos que no debería exponer, pero no ejecución de código. La inyección SQL, aislada, requiere alcanzar un punto de entrada que normalmente exige contexto autenticado. La gracia de wp2shell es que la primera vulnerabilidad entrega a un atacante anónimo el acceso al sumidero vulnerable de la segunda. Una vez que la inyección SQL es explotable sin autenticación, se apalanca para escalar hasta la ejecución de código en el servidor.

El desglose técnico publicado tras los parches detalla esa escalada, más elegante que una inyección clásica. La confusión de rutas, que WordPress procesa en el manejador WP_REST_Server::serve_batch_request_v1(), permite alcanzar la consulta vulnerable sin autenticación. Desde ahí, la inyección SQL no sirve solo para leer datos: envenena objetos WP_Post cacheados mediante la hidratación de objetos. La ruta de escritura de oEmbed persiste esos objetos falsificados en la base de datos y, a través de guardados anidados, un changeset del Customizer y el cargador de la REST API, WordPress termina reevaluando como administrador una petición de creación de usuario que antes había rechazado. El resultado es una cuenta de administrador forjada que instala un plugin y, con él, ejecuta código en el servidor. Según el análisis de Cloudflare, esta vía de ejecución de código funciona cuando el sitio no utiliza una caché de objetos persistente, algo que una instalación estándar de WordPress no tiene, por lo que la exposición por defecto se mantiene.

De ahí el nombre: de una petición a una WordPress accesible, a una shell. Es el mismo patrón que estudiamos en cualquier auditoría de aplicaciones web, donde el impacto real casi nunca proviene de un fallo aislado, sino del encadenamiento de varios.

Severidad y puntuación CVSS

Aquí conviene ser preciso, porque las fuentes no coinciden y el motivo es instructivo. WordPress clasificó la cadena completa como crítica. Sin embargo, en su propio aviso asignó a CVE-2026-63030 un CVSS de 7.5 (alto), razonando que la confusión de rutas por sí sola permite acceso a datos, no la pérdida completa de integridad y disponibilidad que asociamos a la ejecución de código. Los agregadores y fabricantes posteriores (NVD y distintos proveedores de seguridad) puntuaron la cadena de RCE sin autenticación de extremo a extremo como crítica, con valores de hasta 9.8.

La discrepancia no es un error, es una lección sobre cómo leer el CVSS: puntuar un componente aislado no es lo mismo que puntuar la cadena explotable completa. Para priorizar el parcheo, lo relevante no es el número exacto, sino el hecho verificado de que existe una vía de RCE sin autenticación con PoC público. Eso es prioridad máxima con independencia de si se etiqueta 7.5 o 9.8. Es la misma distinción entre severidad reportada y explotabilidad real que explicamos en qué es un exploit.

Versiones afectadas y corregidas

Las versiones anteriores a 6.8 no son vulnerables a la inyección SQL, y las anteriores a 6.9 no son vulnerables a la cadena de RCE, porque el error de confusión de rutas que aporta el acceso sin autenticación solo está presente a partir de la rama 6.9.

Cronología de la divulgación

• 17 de julio de 2026: divulgación coordinada de la vulnerabilidad. Los investigadores retienen los detalles técnicos para dar tiempo a parchear.
• 18 de julio de 2026: WordPress publica las versiones corregidas 6.8.6, 6.9.5 y 7.0.2. Comienza el despliegue de actualizaciones automáticas.
• Horas después de la divulgación: aparecen múltiples PoC públicos en repositorios de GitHub.
• Alrededor del 20 de julio de 2026: se publica el desglose técnico completo y varios equipos (entre ellos watchTowr y Tenable) reportan las primeras señales de explotación en el mundo real durante el fin de semana posterior.

El patrón es el habitual y peligroso: los PoC públicos aparecieron pocas horas después de la divulgación y las primeras señales de explotación real surgieron alrededor del 20 de julio, de modo que la ventana para parchear antes de que haya exploits en circulación se mide en horas, no en semanas. La actualización automática de WordPress protege a muchos sitios, pero deja fuera a los que la tienen desactivada, a los que están en versiones antiguas por incompatibilidad de plugins y a las instancias olvidadas.

Por qué importa especialmente

Tres factores convierten a wp2shell en un riesgo de primer orden:

1. Sin autenticación y sin plugins. No hace falta una cuenta, ni un plugin vulnerable, ni una configuración concreta. Basta una instancia WordPress accesible en una versión afectada. Eso elimina casi todas las barreras habituales de explotación.
2. Escala de WordPress. WordPress es el CMS más extendido del mundo. La superficie de ataque es gigantesca y trivialmente enumerable con herramientas de reconocimiento como Shodan o consultas de Google dorks, que identifican versiones expuestas en minutos.
3. Impacto de RCE. La ejecución de código en el servidor web abre el camino a webshells persistentes, robo de datos, pivote hacia la red interna y despliegue de puertas traseras. Una webshell instalada por esta vía se comporta después como cualquier backdoor: la diferencia está en el origen, no en el resultado.

Es exactamente el tipo de exposición que un programa de gestión de la superficie de ataque (ASM y EASM) está diseñado para descubrir antes que el atacante: inventariar cada instancia WordPress publicada, conocer su versión y priorizar el parcheo de las que estén en rango.

Cómo detectar exposición y compromiso

La detección tiene dos planos: saber si eres vulnerable y saber si ya te han comprometido.

Identificar exposición:

• Inventaría todas las instancias WordPress de la organización, incluidas las de marketing, campañas antiguas, subdominios y las que ningún equipo reclama como propias. El shadow IT es donde viven las instancias sin parchear.
• Comprueba la versión exacta de cada instalación y contrástala con la tabla de versiones afectadas.
• Verifica si la actualización automática está activa y si realmente aplicó el parche. No asumas que sí: confírmalo.

Buscar indicios de compromiso (threat hunting):

• Peticiones anómalas a /wp-json/batch/v1 o a ?rest_route=/batch/v1 en los logs del servidor y del WAF, especialmente lotes malformados o repetitivos desde IPs no habituales.
• Errores SQL inusuales o consultas extrañas en los logs de la base de datos alrededor de las fechas de exposición.
• Usuarios administradores nuevos o inesperados, plugins o mu-plugins que nadie instaló, y ficheros sospechosos en wp-content/uploads (una ubicación clásica de webshells).
• Modificaciones en ficheros del core respecto a la distribución oficial y conexiones salientes anómalas desde el servidor web.

Un punto crítico: parchear no expulsa a un atacante que ya entró. Si una instancia estuvo expuesta durante la ventana de explotación, hay que asumir compromiso potencial e investigar en consecuencia, no limitarse a actualizar.

Mitigaciones prioritarias

Acción uno: parchear ya

La única solución real es actualizar a 6.8.6, 6.9.5 o 7.0.2 según la rama. Es la medida prioritaria y no admite demora. Tras actualizar, confirma que la versión instalada es la corregida y no des por hecho que la automatización lo hizo por ti.

Acción dos: bloquear el endpoint batch en el WAF

Si no puedes parchear de inmediato, bloquea en el WAF o en el borde tanto /wp-json/batch/v1 como ?rest_route=/batch/v1. Es una mitigación temporal, no un sustituto del parche, pero corta el vector de acceso mientras despliegas la actualización. Un WAF bien configurado permite este parcheo virtual en minutos.

Acción tres: restringir la REST API a usuarios autenticados

Limita el acceso anónimo a la REST API, ya sea con un plugin que exija autenticación para la API o con un mu-plugin propio que restrinja específicamente el endpoint batch a peticiones autenticadas. Endurecer la exposición de la REST API es, además, una buena práctica permanente que conviene revisar en cualquier auditoría de APIs.

Acción cuatro: investigar y remediar si hubo exposición

Si la instancia estuvo accesible sin parchear, activa el procedimiento de respuesta: threat hunting retrospectivo, revisión de integridad del core, rotación de credenciales almacenadas y de claves de la base de datos, y contención de cualquier artefacto encontrado. Un simple update no elimina una webshell ya instalada.

Encaje con NIS2, DORA y la gestión de vulnerabilidades

wp2shell es un caso de manual para ilustrar por qué la gestión de vulnerabilidades con SLA de parcheo y los procedimientos de notificación no son burocracia, sino control operativo:

• NIS2, artículo 21: exige medidas de gestión de riesgos que incluyen el tratamiento de vulnerabilidades y su divulgación. Una ventana de parcheo medida en horas es precisamente el escenario para el que existen estos controles.
• NIS2, notificación de incidentes: si una instancia comprometida procesa servicios en alcance, aplican los plazos de notificación (alerta temprana en 24 horas, notificación en 72 horas).
• DORA, para entidades financieras: la gestión del riesgo de terceros ICT y la resiliencia operativa cubren explícitamente el parcheo disciplinado de componentes como un CMS corporativo.
• RGPD: si una explotación exfiltra datos personales, puede constituir una brecha notificable. Documenta la evaluación de riesgo.

La diferencia entre una organización que absorbe wp2shell como un parche rutinario y otra que acaba con una brecha notificable no está en la suerte, sino en tener inventariada la superficie, monitorizada la exposición y disciplinado el parcheo. Es la misma lógica que aplicamos al analizar otros avisos recientes de máxima severidad, como CVE-2026-21858 en n8n o CVE-2026-34926 en Trend Micro Apex One, y que resumimos cada mes en nuestro repaso de vulnerabilidades críticas.

Preguntas frecuentes

¿Estoy afectado si mi WordPress no tiene plugins?

Sí. wp2shell afecta al core de WordPress, no a plugins ni temas. Una instalación limpia y estándar en una versión de las ramas 6.9.x o 7.0.x afectadas es explotable. La ausencia de plugins no protege frente a esta cadena.

¿Me protege la actualización automática de WordPress?

Ayuda mucho, pero no debes darla por segura. Muchos sitios tienen la actualización automática desactivada, están anclados a versiones antiguas por incompatibilidad de plugins o son instancias olvidadas. Confirma manualmente que la versión instalada es 6.8.6, 6.9.5 o 7.0.2.

Si actualizo ahora, ¿estoy seguro aunque haya estado expuesto antes?

Actualizar cierra la vulnerabilidad, pero no elimina a un atacante que ya haya entrado ni las webshells o cuentas que haya creado. Si la instancia estuvo accesible sin parchear durante la ventana de explotación, asume compromiso potencial e investiga antes de darla por segura.

¿Sirve bloquear el endpoint /wp-json/batch/v1 en el WAF?

Sí, como mitigación temporal. Bloquear /wp-json/batch/v1 y ?rest_route=/batch/v1 corta el vector de acceso de la confusión de rutas mientras despliegas el parche. No es un sustituto de actualizar, sino un puente hasta hacerlo.

¿Cuál es la diferencia entre CVE-2026-63030 y CVE-2026-60137?

CVE-2026-63030 es la confusión de rutas en la REST API batch, que da a un atacante anónimo acceso a manejadores restringidos. CVE-2026-60137 es la inyección SQL en author__not_in de WP_Query. La primera aporta el acceso sin autenticación; la segunda, encadenada, permite escalar hasta la ejecución de código.

¿Cómo localizo todas las instancias WordPress de mi organización?

Combina el inventario formal de activos con reconocimiento externo (buscadores de dispositivos como Shodan, consultas de Google dorks, descubrimiento de subdominios) y consultas a los equipos de marketing y producto para identificar instancias no oficiales. Un programa de gestión de la superficie de ataque automatiza este descubrimiento de forma continua.

Recursos relacionados

• Qué es una inyección SQL: el componente CVE-2026-60137 de la cadena, explicado a fondo.
• Qué es un exploit: severidad reportada frente a explotabilidad real con PoC disponible.
• Qué es un CVE: cómo se referencia y prioriza CVE-2026-63030.
• Subida de archivos insegura: de webshell a RCE: el desenlace típico de una ejecución de código en un servidor web.
• Pentesting de aplicaciones web: cómo se descubren y encadenan estas debilidades en una auditoría real.
• Gestión de la superficie de ataque (ASM y EASM): descubrir instancias WordPress expuestas antes que el atacante.
• Investigación y advisories de Secra.

Evaluación de exposición a wp2shell con Secra

Secra mantiene un programa interno de investigación de vulnerabilidades con advisories propios publicados en NVD e INCIBE-CERT (CVE-2025-40652 en CoverManager y CVE-2023-3512 en Setelsa ConacWin CB, entre otros). Esa disciplina de descubrimiento aplicada a tu superficie expuesta es la diferencia entre detectar una exposición a wp2shell antes o después del incidente.

Ayudamos a organizaciones a evaluar su exposición real: inventario y descubrimiento continuo de instancias WordPress publicadas, verificación de versiones y parcheo, revisión de hardening de la REST API, threat hunting retrospectivo y, cuando procede, intervención de respuesta a incidentes (DFIR). Auditoría exprés de instancias WordPress expuestas con primeros hallazgos en menos de 5 días. Escríbenos a través de contacto.