Una nueva vulnerabilidad en el núcleo de WordPress, wp2shell, permite a atacantes no autenticados ejecutar código
El Hallazgo:
Adam Kues, de Assetnote, la división de gestión de la superficie de ataque de Searchlight Cyber, descubrió el error de enrutamiento por lotes y lo reportó a través del programa HackerOne de WordPress. El informe, publicado bajo el nombre de wp2shell, afirma que el ataque «no tiene condiciones previas y puede ser explotado por un usuario anónimo».
Una solicitud HTTP anónima puede ejecutar código en un sitio de WordPress. El fallo reside en el núcleo, por lo que una instalación básica sin plugins es vulnerable. Todos los sitios con versiones 6.9 y 7.0 estaban afectados hasta el viernes, cuando WordPress lanzó las versiones 6.9.5 y 7.0.2 y habilitó las actualizaciones forzadas mediante su sistema de actualización automática.
wp2shell consta de dos vulnerabilidades, no de una, y ambas cuentan ahora con identificadores CVE (Common Vulnerabilities and Exposures). CVE-2026-63030 se refiere a la confusión en el enrutamiento por lotes de la API REST; CVE-2026-60137 es una vulnerabilidad de inyección SQL en el núcleo de WordPress. Encadenadas, permiten que una solicitud anónima se ejecute directamente.
Searchlight aún mantiene su propio informe técnico y remite a los propietarios a una herramienta de verificación en wp2shell.com. La reticencia ya no importa: el parche es público y otros investigadores lo han consultado. Los dos errores no afectan a las mismas versiones, y esa es la clave para saber quién está expuesto a qué. La inyección se remonta a la versión 6.8. La confusión en el enrutamiento por lotes, la parte que convierte una inyección limitada en una ejecución remota de código no autenticada, solo existe a partir de la versión 6.9. Entonces los rangos se dividen:
- 8.0 a 6.8.5: Solo inyección SQL, corregido en 6.8.6.
- 9.0 a 6.9.4: cadena RCE completa, corregida en 6.9.5
- 0.0 a 7.0.1: cadena RCE completa, corregida en 7.0.2
Actualice la version de su WordPress por encima del 7.0.2
La versión 7.1 beta2 incluye ambas correcciones. Un sitio 6.8 no es vulnerable a la ejecución remota de código a través de esta cadena, razón por la cual la versión 6.8.6 corrige únicamente la inyección. WordPress no ha aclarado si la actualización forzada llega a los sitios que desactivaron las actualizaciones automáticas. Comprueba la configuración que tienes instalada en lugar de dar por sentado que la actualización se ha instalado. Según las estimaciones de Searchlight, más de 500 millones de sitios web utilizan WordPress. Esta cifra corresponde a la base total de instalaciones, no a los sitios expuestos: la vulnerabilidad de ejecución remota de código (RCE) solo existe a partir de la versión 6.9, lanzada el 2 de diciembre de 2025. Por lo tanto, todos los sitios expuestos a la ruta de ejecución de código utilizan una versión con menos de ocho meses de antigüedad, y ningún aviso especifica cuántos son. La cadena tiene dos pequeños errores. La inyección reside en el parámetro author__not_in de WP_Query: si se le pasa una cadena en lugar de un array, se omite la comprobación que espera un array, lo que provoca que se inserte el valor sin procesar en la consulta. Acceder a ese parámetro sin iniciar sesión es tarea del endpoint de procesamiento por lotes. La ruta /wp-json/batch/v1 de WordPress ejecuta varias subpeticiones en una sola llamada y las rastrea en dos matrices paralelas; un error en una subpetición desincroniza las matrices, por lo que una solicitud se ejecuta bajo el controlador de una solicitud diferente. Anidada, esa confusión elude la lista de permisos del endpoint y permite que la entrada del atacante se introduzca en la consulta vulnerable sin autenticación. El endpoint de procesamiento por lotes se implementó en la versión 5.6 en 2020; la confusión que lo explota es nueva en la versión 6.9. Vale la pena analizar detenidamente las puntuaciones. El propio aviso de WordPress califica la cadena RCE como Crítica. Su registro CVE le otorga una puntuación de 7,5, solo Alta, y las métricas de impacto solo consideran el acceso a los datos, no la pérdida de integridad o disponibilidad que cabría esperar de la ejecución de código. La inyección depende de puntuaciones superiores a 9,1, Crítica. El error que todos consideran una vulnerabilidad crítica de ejecución remota de código (RCE) es, en realidad, el menos grave de los dos, ya que la puntuación premia el acceso directo de la inyección a la base de datos y trata la confusión de rutas como un fallo de análisis sintáctico. Se debe hacer un seguimiento de ambas vulnerabilidades, no de la etiqueta que se les asigna.
Una condición limita el alcance de la vulnerabilidad. La ruta de ejecución del código solo funciona cuando el sitio no utiliza una caché de objetos persistente, según Cloudflare , que publicó las reglas del WAF junto con la divulgación. Una instalación predeterminada no tiene dicha caché, por lo que la vulnerabilidad persiste. Un sitio que utilice WordPress con Redis o Memcached como caché de objetos persistente puede desviarse de este camino en particular, pero eso es un efecto secundario, no una solución, y no cubre la inyección SQL. Con los identificadores CVE asignados, los escáneres finalmente pueden detectarlo: Rapid7 indica que las comprobaciones autenticadas para InsightVM y Nexpose estarán disponibles el 20 de julio. No figura en el catálogo KEV de CISA, que incluye las vulnerabilidades de explotación confirmadas, y hasta el 18 de julio no se había reportado ninguna. Sin embargo, esta tranquilidad es menor de lo que parece.
Si no Puede Actualizar:
Si no puedes actualizar hoy Todas las medidas de mitigación que ofrece Searchlight se reducen a impedir que las llamadas anónimas lleguen al punto final de procesamiento por lotes. Todas son soluciones temporales hasta que actualices, y todas pueden interrumpir integraciones legítimas: En un WAF, bloquee tanto /wp-json/batch/v1 como rest_route=/batch/v1. Ambos deben eliminarse, ya que una regla que solo cubra la ruta /wp-json deja abierta la ruta de la cadena de consulta. Cloudflare afirma que su WAF administrado ahora bloquea la cadena para los sitios que se encuentran detrás de él. Deshabilitar la API REST de WP , lo que elimina por completo el acceso REST no autenticado. Searchlight publica un pequeño complemento que se instala fácilmente y que rechaza las solicitudes anónimas /batch/v1 en rest_pre_dispatch.