Threat Advisories

Cadena de ejecución remota de código en el núcleo de WordPress «wp2shell» (CVE-2026-63030 y CVE-2026-60137)

Escrito por Integrity360 | 30 jul 2026, 7:12:21

La cadena de exploits «wp2shell» constituye un incidente de seguridad crítico que afecta a la arquitectura fundamental del ecosistema de WordPress. Se trata de una vulnerabilidad de ejecución remota de código (RCE) previa a la autenticación que reside íntegramente en el núcleo de WordPress. Para ejecutarse, no requiere plugins ni temas de terceros, ni acceso autenticado. Una sola solicitud HTTP manipulada dirigida a una instalación predeterminada «de serie» puede dar lugar a que un atacante no autenticado obtenga el control total del sistema.

La gravedad de esta amenaza queda reflejada en su puntuación CVSS de 9,8. La CISA añadió ambos CVE a su catálogo de vulnerabilidades explotadas conocidas (KEV) tras observarse actividad de explotación poco después de su divulgación. Los datos indican que aproximadamente el 60 % de las organizaciones que utilizan WordPress eran inicialmente vulnerables en el momento de la divulgación, y que una parte significativa de ellas exponía estos servidores directamente a Internet.

Una explotación exitosa puede permitir el compromiso total de la base de datos, el acceso persistente al servidor web a través de webshells ofuscadas y la creación no autorizada de cuentas administrativas.

Resumen de la vulnerabilidad

La cadena de explotación wp2shell combina varias vulnerabilidades del núcleo de WordPress para lograr una escalada de privilegios sin autenticación. El ataque aprovecha primero un fallo en el procesamiento de solicitudes por lotes de la API REST para eludir la validación de solicitudes y los controles de autorización. A continuación, este acceso se utiliza para explotar una vulnerabilidad de inyección SQL en el manejo de WP_Query del parámetro «author_exclude».

Mediante la técnica de inyección SQL, un atacante puede manipular objetos de WordPress almacenados en caché y aprovechar el mecanismo de almacenamiento en caché de oEmbed para escribir datos maliciosos en la base de datos. A continuación, el exploit aprovecha la funcionalidad de conjuntos de cambios del Personalizador para heredar temporalmente los permisos de una cuenta de administrador, creando finalmente un usuario administrativo persistente.

En resumen, el ataque se desarrolla en cuatro fases:

  1. Elusión de la validación de la API REST mediante la desincronización de solicitudes por lotes.
  2. Inyección SQL mediante una sanitización inadecuada de los parámetros.
  3. Contaminación de la caché de objetos y manipulación de la base de datos mediante el comportamiento de reescritura de oEmbed.
  4. Elevación de privilegios y persistencia mediante la creación de una cuenta de administrador.

Si se encadenan, estas vulnerabilidades pueden permitir que un atacante no autenticado obtenga el control administrativo total de una instalación vulnerable de WordPress.

 

En este exploit se utilizan las siguientes vulnerabilidades del núcleo de WordPress:

  • CVE-2026-63030 (confusión de rutas por lotes en la API REST): Un error lógico en WP_REST_Server::serve_batch_request_v1() por el que un fallo en la gestión de los objetosWP_Error provoca una desincronización entre los arrays internos de gestión de solicitudes, lo que permite que las solicitudes no validadas hereden los permisos de los controladores benignos.
  • CVE-2026-60137 (inyección SQL en WP_Query): Un fallo de manipulación de tipos en el motor WP_Query. Cuando determinados parámetros reciben una cadena sin procesar en lugar del array esperado, se elude la sanitización de enteros, lo que da lugar a la interpolación de cadenas sin procesar en las cláusulasWHERE de SQL .

Versiones afectadas frente a versiones corregidas

Rama

Versiones afectadas

Versiones corregidas

Perfil de impacto

WordPress 7.0.x

7.0.0 – 7.0.1

7.0.2

Cadena completa de RCE

WordPress 6.9.x

6.9.0 – 6.9.4

6.9.5

Cadena completa de RCE

WordPress 6.8.x

6.8.0 – 6.8.5

6.8.6

Solo inyección SQL

WordPress 7.1 (Beta)

7.1 Beta 1

7.1 Beta 2

Cadena completa de RCE

Evaluación estratégica: Riesgos de WordPress

Históricamente, la seguridad de WordPress se ha centrado en el «perímetro de los plugins». Este ataque demuestra que pueden surgir riesgos de seguridad importantes desde el núcleo de WordPress y no solo a través de extensiones de terceros. Las organizaciones deben asegurarse de que las instancias de WordPress se incorporen a programas formales de gestión de vulnerabilidades y parches.

Desde una perspectiva defensiva, WordPress debe considerarse un objetivo de gran valor. Su amplia implantación en entornos conectados a Internet lo convierte en una plataforma atractiva para los autores de amenazas, lo que aumenta la probabilidad de que se investiguen vulnerabilidades, se realicen análisis automatizados y se produzcan intentos de explotación.

Pilares estratégicos de la gobernanza

  • Mapeo de la superficie de ataque: Realiza un inventario continuo de todos los activos de WordPress. La mayoría de las brechas de seguridad se producen en instancias de prueba olvidadas y sin parches.
  • Validación continua: No confíes en el estado de «actualización automática». Implementa una comprobación automatizada de versiones para garantizar que los parches estén realmente activos.
  • Confía, pero verifica: aunque WordPress.org permite las actualizaciones forzadas, los administradores deben verificar que se hayan completado en todas las configuraciones de los servidores.
  • Rotación de credenciales y salts: en caso de sospecha de una vulnerabilidad en el núcleo, la rotación de los salts de la base de datos en wp-config.php es una medida de defensa estratégica obligatoria para invalidar las sesiones existentes.

Búsqueda de amenazas e indicadores de compromiso (IoC)

Señales de red

  • Código de estadoHTTP 207 «Multi-Status»: se trata de una señal de alta fiabilidad que indica intentos de explotación exitosos a través de la API por lotes.
  • Detección de elusión de WAF: los atacantes pueden utilizar caracteres de escape %2F en el parámetro ?rest_route= para eludir la comparación simple de cadenas. Los WAF deben configurarse para realizar la decodificación de la URL antes de la comparación.
  • Agentes de usuario: vigilar la presencia de wp2shell, rezwp2shell o cve-2026-63030/1.0.

Artefactos basados en el host

  • Marcadores de archivos: Busca «temp-write-test-» en el directorio «wp-content/», utilizado por los kits de explotación para verificar los permisos de escritura.
  • Plugins maliciosos: Busca directorios que utilicen un sufijo hexadecimal, como «wp-content/plugins/wp2shell_/».
  • Distinción de CMSmap: Los equipos forenses deben distinguir entre la herramienta legítima CMSmap, de 11 KB, y la plataforma ofuscada de 150 KB observada en las campañas actuales.

IOC conocidos

Tipo de IOC

Indicador

Descripción

Dirección IP

34.81.132.62

Intento de explotación

Dirección IP

79.177.131.206

Intento de explotación

Dirección IP

15.157.135.170

Intento de explotación

Dirección IP

94.100.52.128

Intento de explotación

Dirección IP

172.235.128.52

Escaneo masivo

Hash SHA-1

2a1410d8e2a8337ac2171cedea8c0fdc47c647a0

Complemento CMSmap ofuscado

Hash SHA-1

58eca847e9eae9e6b08cc211f1559817b71bc4cc

Webshell de PHP

Hash SHA-1

ebea44890f434d5d67ede22009a3f4bb5cac33f8

Webshell PHP

Hash SHA-1

d9a220c8039f1c4d72cae7ccb8b3a33dec8815be

Webshell PHP

Hash SHA-1

e9756e2338f84746007235e4cab7a70d5b3ca47f

Webshell PHP

Medidas de mitigación y corrección

Las organizaciones deben actualizarinmediatamente el núcleo de WordPress a las versiones 7.0.2, 6.9.5 o 6.8.6. Aunque WordPress.org ha impulsado actualizaciones forzadas, los administradores deben «confiar, pero verificar» estas instalaciones, ya que no se garantiza que la actualización automática se complete en todas las configuraciones de los servidores. Se debe dar prioridad a las instancias de las ramas 6.9.x y 7.0.x, que son vulnerables a la cadena completa de ejecución remota de código (RCE).

Medidas de mitigación temporales

Cuando no sea posible aplicar un parche de forma inmediata, los administradores deben implementar reglas WAF para bloquear el acceso no autenticado a los puntos finales por lotes de la API REST afectados. La decodificación de la URL debe realizarse antes de la coincidencia de reglas para detectar las solicitudes codificadas.

Puntos finales bloqueados:

  • /wp-json/batch/v1
  • ?rest_route=/batch/v1 (incluidas variantes codificadas en URL, como %2Fbatch%2Fv1)

Acciones posteriores al compromiso

Si hay motivos para creer que se ha producido una explotación, se recomiendan las siguientes acciones:

  • Verificar la integridad de los archivos del núcleo: Ejecuta el comando«wp core verify-checksums» para identificar archivos del núcleo de WordPress modificados o no autorizados.
  • Rotar credenciales: restablecer las credenciales de la base de datos y regenerar las sales de autenticación y las claves de seguridad en el archivo `wp-config.php`.
  • Revisar las cuentas de usuario: auditar la tabla `wp_users` en busca de cuentas no autorizadas, en particular aquellas que utilicen la convención de nomenclatura «w2s_».
  • Buscar indicadores de compromiso (IOC): Buscar en los registros del servidor web, los sistemas de archivos y las herramientas de supervisión de seguridad los indicadores de compromiso enumerados en este aviso.

Si le preocupa alguna de las amenazas descritas en este boletín o necesita ayuda para determinar qué medidas debe tomar para protegerse de las amenazas más graves a las que se enfrenta su organización, póngase en contacto con su gestor de cuentas o, si lo prefiere, póngase en contacto con nosotros para averiguar cómo puede proteger su organización.