Alerta de seguridad en WordPress: parches de emergencia corrigen una grave ejecución remota de código en el núcleo

WordPress publicó parches de emergencia el 17 de julio de 2026 para cerrar una vulnerabilidad de ejecución remota de código que, según el descubrimiento, puede activarse con una petición HTTP anónima contra una instalación por defecto sin plugins. Los parches aparecen en las versiones 6.9.5 y 7.0.2, y la corrección también está presente en 7.1 beta2; las ramas afectadas fueron 6.9.0–6.9.4 y 7.0.0–7.0.1. Porque el fallo está en el núcleo, un sitio recién instalado estaba teóricamente en riesgo.

El hallazgo fue reportado por Adam Kues de Assetnote a través del programa HackerOne de WordPress y publicado bajo el seudónimo wp2shell; la firma decidió no desvelar los detalles técnicos completos y, en su lugar, puso a disposición un comprobador público en wp2shell.com para que administradores verifiquen sus instancias. WordPress describe el problema como una combinación de confusión en la ruta por lotes del API REST y una inyección SQL que puede desembocar en RCE; los ficheros tocados por la corrección incluyen /wp-includes/rest-api/class-wp-rest-server.php, /wp-includes/class-wp-query.php y /wp-includes/rest-api.php.

Hay dos puntos prácticos que los responsables de sitios deben asumir inmediatamente: no confíen en que todos los sitios recibieron el parche automáticamente, y no espere que los escáneres basados en CVE lo detecten todavía. WordPress activó una actualización forzada a través de su sistema de auto-updates para intentar acelerar la protección, pero la compañía no ha aclarado si esa pulsación alcanza instalaciones que tienen las actualizaciones automáticas desactivadas. Además, como no había CVE público ni puntuación CVSS publicada al cierre del parche, muchas herramientas y catálogos (por ejemplo el catálogo KEV de CISA) no podrán señalar el riesgo hasta que exista esa referencia; puede consultar el catálogo de versiones de WordPress en la página de descargas y archivos y el proceso de divulgación de CISA en Known Exploited Vulnerabilities.

Si administra uno o varios sitios WordPress, vea la versión que realmente está ejecutando y aplique la actualización a 6.9.5, 7.0.2 o superior. Verificar la versión puede hacerse desde el panel de administración, consultando el meta generator en el HTML público (si no ha sido eliminado), o desde línea de comandos con WP‑CLI: ejecutar wp core version y actualizar con wp core update si tiene acceso. No asuma que la actualización forzada ya llegó a todos sus servidores.

Mientras no pueda actualizar, existen mitigaciones provisionales que evitan que llamadas anónimas lleguen al endpoint vulnerable, aunque todas tienen coste funcional. Una alternativa es bloquear en el WAF tanto la ruta JSON estándar /wp-json/batch/v1 como la variante por query string rest_route=/batch/v1; Assetnote subraya que ambas deben bloquearse porque bloquear solo la primera deja un vector abierto. Otra opción es deshabilitar el API REST para accesos anónimos o desplegar un pequeño plugin que rechace llamadas anónimas al endpoint /batch/v1 usando el hook rest_pre_dispatch. Tenga en cuenta que estas medidas pueden romper integraciones legítimas que dependan del API.

La falta de una prueba de explotación pública por ahora no debe inducir a la calma. El ecosistema WordPress tiene un histórico de campañas masivas que explotan fallos divulgados y parcheados días u horas antes; si el código del parche está en un repositorio público, los atacantes con conocimiento suficiente pueden comparar versiones y construir exploits rápidamente. Por eso es crítico aplicar parches y monitorizar actividad anómala antes de que las escaneos y los exploits aparezcan en la wild.

Acciones concretas recomendadas: actualice cuanto antes a las versiones corregidas; si no puede actualizar de inmediato, bloquee las rutas indicadas en la frontera (WAF o reglas de servidor) y considere deshabilitar el API REST para usuarios anónimos hasta que esté protegido. Revise logs web y de WAF buscando peticiones a /wp-json/batch/v1 o conteniendo rest_route=/batch/v1, inspeccione ficheros modificados recientemente y compruebe la presencia de cuentas administrativas o ficheros PHP sospechosos en wp-content. Haga copias de seguridad completas antes de cualquier intervención, y, si sospecha compromiso, mantenga la instancia desconectada mientras investiga.

Finalmente, recuerde que el alcance real del problema no es el número total de instalaciones de WordPress sino las que ejecutan versiones afectadas publicadas desde diciembre de 2025 (6.9 en adelante). Si su sitio está en 6.8 o anterior no tiene este fallo en particular, pero otras correcciones están pendientes en esas ramas; por ejemplo la 6.8.6 aborda otra inyección SQL distinta. Mantener una política de actualización regular, segmentación de privilegios y monitorización de anomalías reduce drásticamente la ventana de exposición frente a estos errores de cero día.