WordPress wp2shell: Cómo dos fallas centrales permiten a los atacantes ejecutar código sin iniciar sesión
Por Necolas Hamwi
18 de julio de 2026 | Blog de Aratech
La versión corta
Una solicitud HTTP anónima ahora puede hacerse cargo de un sitio de WordPress. Sin contraseña, sin complementos, sin configuración incorrecta: solo una instalación básica de WordPress. Dos vulnerabilidades recientemente encadenadas, CVE-2026-63030 y CVE-2026-60137, convierten un sitio estándar de WordPress 6.9 o 7.0 en un objetivo de ejecución remota de código. Las fallas son fundamentales, el exploit es público y ya se están implementando parches mediante actualizaciones automáticas forzadas.
Si ejecuta WordPress para un cliente, una cartera o una herramienta interna, esto es importante.
¿Qué es wp2shell?
El investigador de seguridad Adam Kues (Searchlight Cyber / Assetnote) descubrió y publicó una cadena de dos errores que elude por completo la autenticación. El nombre wp2shell proviene del resultado del ataque: un atacante no autenticado envía una solicitud diseñada y obtiene un shell: ejecución de código completo en el servidor.
La cadena funciona así:
- CVE-2026-60137: una inyección SQL en el núcleo de WordPress permite a un atacante manipular la base de datos mediante una solicitud no autenticada.
- CVE-2026-63030: una vulnerabilidad de confusión de rutas por lotes de API REST permite al atacante encadenar esa inyección SQL en escalada de privilegios y ejecución remota de código.
Individualmente, cada error es grave. En conjunto, son catastróficos porque el ataque requiere cero condiciones previas: ningún usuario autenticado, ningún acceso de administrador, ningún complemento vulnerable.
¿Quién se ve afectado?
Las versiones afectadas son específicas:
Si su sitio ejecuta cualquier versión desde 6.9.0 hasta 6.9.4 o 7.0.0 hasta 7.0.1, era explotable hasta que WordPress envió actualizaciones automáticas forzadas el viernes 17 de julio de 2026.
La buena noticia: WordPress habilitó actualizaciones forzadas a través de su sistema de actualización automática, por lo que muchos sitios ya están parcheados. La mala noticia: cualquier sitio con las actualizaciones automáticas deshabilitadas, o cualquier sitio que no haya sido forzado, sigue siendo vulnerable.
Por qué esto es diferente de otros defectos de WordPress
La mayoría de las vulnerabilidades de WordPress residen en complementos o temas. Un defecto central es más raro y más peligroso porque:
- Cada instalación es un objetivo. Ninguna auditoría de complementos puede detectarlo.
- La superficie de ataque es universal. La API REST está habilitada de forma predeterminada.
- La explotación es trivial. Ya hay una prueba de concepto funcional pública en GitHub.
- La aplicación de parches no es opcional. Esperar el próximo período de mantenimiento es un riesgo.
El mecanismo wp2shell se publicó en su totalidad el 17 de julio y un PoC funcional se puso en marcha el mismo día. Eso significa que el código de explotación ahora está disponible para todos los atacantes, no sólo para el investigador original.
¿Qué deberías hacer ahora mismo?
-
Comprueba tu versión. Inicie sesión en wp-admin y mire la esquina inferior derecha, o ejecute
wp core versiona través de WP-CLI. Si tiene una versión 6.9.x inferior a 6.9.5 o 7.0.x inferior a 7.0.2, está expuesto. -
Actualice inmediatamente. WordPress 6.9.5 y 7.0.2 cierran ambos CVE. Si las actualizaciones automáticas están desactivadas, actualícelas manualmente ahora.
-
Verifique que se haya instalado el parche. Después de la actualización, confirme el número de versión. No asuma que la actualización forzada llegó a su host.
-
Busque indicadores de compromiso. Debido a que esta falla permite el acceso no autenticado, verifique sus registros de acceso para detectar solicitudes inesperadas de API REST a
/wp-json/wp/v2/o/wp-json/wp/v2/usersantes de la fecha del parche. -
Fortalezca su API REST. Si no utiliza la API REST, considere restringirla con una regla de firewall o un complemento de seguridad. Esto no soluciona el defecto, pero reduce la exposición a errores futuros similares.
El panorama general: el software principal no es inherentemente seguro
Las organizaciones suelen tratar a WordPress como "sólo un CMS" y asumen que la seguridad es un problema de complementos. wp2shell demuestra que esa suposición es errónea. El software más confiable en Internet puede incluir un RCE de autenticación previa en el núcleo, y lo único que se interpone entre usted y el compromiso es si su mecanismo de actualización funcionó un viernes por la tarde.
Para las empresas, la lección es la misma que para los sistemas operativos: la cadencia de parches es un control de seguridad. Si su equipo no tiene una política de actualización central de WordPress documentada y probada, este es su recordatorio para crear una.
Acerca del investigador
Adam Kues informó del error de ruta por lotes a través del programa HackerOne de WordPress. La inyección SQL fue informada por separado por los investigadores TF1T, dtro y haongo. Searchlight Cyber, el brazo de gestión de superficies de ataque donde trabaja Kues, publicó el artículo con el nombre wp2shell y aún conserva todos los detalles técnicos mientras dirige a los propietarios del sitio a un verificador en wp2shell.com.
---## TL;DR
- Dos fallas centrales de WordPress se encadenan en la ejecución remota de código no autenticado.
- Afecta a 6.9.0–6.9.4 y 7.0.0–7.0.1.
- La PoC pública está activa. Las actualizaciones automáticas forzadas se enviaron el 17 de julio.
- Si administra sitios de WordPress, actualice a 6.9.5 o 7.0.2 hoy.
Necolas Hamwi es CTO y fundador de aratech. Escribe sobre ciberseguridad, inteligencia artificial y las opciones de infraestructura que dan forma a los negocios digitales modernos.