Una cadena de vulnerabilidades del núcleo de WordPress permite la ejecución remota de código sin autenticación

Investigadores de seguridad han divulgado un par de vulnerabilidades del núcleo de WordPress que pueden encadenarse para ejecutar código sin autenticación. Los problemas afectan a las instalaciones del núcleo, por lo que los sitios que no ejecutan complementos de terceros también pueden estar en riesgo.

Las vulnerabilidades están identificadas como CVE-2026-63030 y CVE-2026-60137. La primera implica una confusión en la ruta de procesamiento por lotes de la API REST de WordPress, mientras que la segunda es una inyección SQL que afecta al parámetro author__not_in utilizado por WP_Query. En conjunto, los fallos permiten a un atacante enviar una solicitud anónima que llega a la consulta de base de datos vulnerable y puede conducir a la ejecución remota de código.

Versiones afectadas

• WordPress 6.8.0 a 6.8.5: afectadas por la inyección SQL; corregida en la versión 6.8.6.
• WordPress 6.9.0 a 6.9.4: afectadas por la cadena de ataque completa; corregida en la versión 6.9.5.
• WordPress 7.0.0 y 7.0.1: afectadas por la cadena completa; corregida en la versión 7.0.2.
• WordPress 7.1 beta 2 incluye ambas correcciones.

El investigador Adam Kues, de Assetnote, informó sobre el problema de la API REST a través del programa HackerOne de WordPress. Otros investigadores informaron por separado sobre la inyección SQL. Desde entonces se han publicado detalles técnicos y una prueba de concepto funcional, lo que aumenta la probabilidad de que los atacantes intenten reproducir el exploit.

WordPress califica la vulnerabilidad encadenada como crítica, aunque su puntuación CVE asociada es de 7,5. La inyección SQL por sí sola ha recibido una clasificación de gravedad crítica. Hasta el 18 de julio no se había informado de ninguna explotación confirmada, y en ese momento el problema no figuraba en el catálogo de vulnerabilidades explotadas conocidas de CISA.

Acciones recomendadas

Los administradores deben comprobar la versión instalada y actualizar a una versión corregida lo antes posible, en lugar de depender de las actualizaciones automáticas. Según los informes, la vía de ejecución de código requiere la ausencia de una caché de objetos persistente, pero Redis o Memcached no deben considerarse un sustituto de la aplicación de parches.

Hasta aplicar las actualizaciones, las organizaciones pueden considerar bloquear el acceso anónimo a /wp-json/batch/v1 y a la ruta equivalente rest_route=/batch/v1 mediante un firewall de aplicaciones web. Deshabilitar el acceso no autenticado a la API REST o utilizar temporalmente un filtro para rechazar las solicitudes por lotes anónimas son opciones adicionales, aunque estas medidas pueden interrumpir integraciones legítimas y no eliminan la inyección SQL subyacente.