WP2Shell en WordPress es el nombre con el que se conoce a una cadena de dos vulnerabilidades recientes en WordPress Core: CVE-2026-60137 y CVE-2026-63030. Combinadas, pueden permitir que un atacante sin cuenta ni credenciales llegue a comprometer una instalación estándar de WordPress y ejecute código en el servidor.
A diferencia de muchos incidentes de seguridad del ecosistema, este caso no depende de un plugin o tema vulnerable. El problema se encuentra en el núcleo de WordPress y afecta a versiones concretas de las ramas 6.8, 6.9 y 7.0. WordPress publicó las correcciones el 17 de julio de 2026 y, debido a la gravedad, habilitó actualizaciones automáticas forzadas para instalaciones afectadas que las soporten.
Respuesta rápida: WordPress 6.8 debe actualizarse al menos a 6.8.6, WordPress 6.9 a 6.9.5 y WordPress 7.0 a 7.0.2. Si administras un sitio vulnerable, actualiza primero y después verifica usuarios, integridad de archivos y registros de acceso.
Qué es WP2Shell y por qué es diferente
WP2Shell no es un tercer CVE. Es el nombre público de una cadena de ataque formada por dos fallos separados. El primero proporciona una condición de inyección SQL en WP_Query; el segundo provoca una confusión de rutas en el procesamiento por lotes de la REST API. En las ramas afectadas, la interacción entre ambos puede eliminar la necesidad de autenticación y abrir un camino hacia ejecución remota de código.
Esto cambia la prioridad operativa. Un fallo que exige una cuenta válida suele tener un alcance más limitado. En cambio, la cadena WP2Shell puede dirigirse contra una instalación predeterminada expuesta a Internet, sin interacción del administrador y sin depender de extensiones de terceros.
La publicación oficial de WordPress 7.0.2 identifica una vulnerabilidad crítica y otra de severidad alta. También confirma que las correcciones fueron distribuidas en las ramas afectadas y recomienda actualizar inmediatamente.
Cómo funcionan CVE-2026-60137 y CVE-2026-63030
CVE-2026-60137: inyección SQL en WP_Query
CVE-2026-60137 afecta el tratamiento del parámetro author__not_in dentro de WP_Query. La validación y preparación insuficientes de determinados valores pueden facilitar una inyección SQL en versiones vulnerables.
Una inyección SQL puede permitir que un atacante altere consultas destinadas a la base de datos y acceda a información que no debería recibir. El aviso oficial de GitHub para CVE-2026-60137 indica que el fallo afecta a WordPress 6.8.0–6.8.5, 6.9.0–6.9.4 y 7.0.0–7.0.1.
CVE-2026-63030: confusión de rutas en la REST API
CVE-2026-63030 se relaciona con el endpoint de solicitudes por lotes de la REST API. Una discrepancia entre la ruta validada y la ruta finalmente procesada puede provocar que una subsolicitud llegue a un callback diferente del esperado y evada restricciones diseñadas para impedir su ejecución en un lote.
Por sí sola, esta debilidad altera los límites de confianza del enrutamiento. Cuando se combina con CVE-2026-60137, la cadena puede llegar a ejecución remota de código sin autenticación. El aviso oficial de CVE-2026-63030 clasifica el problema como crítico y confirma que afecta a WordPress 6.9.0–6.9.4 y 7.0.0–7.0.1.
Versiones de WordPress afectadas y corregidas
| Rama de WordPress | Riesgo | Versiones vulnerables | Versión corregida |
|---|---|---|---|
| 6.8 | CVE-2026-60137; no está incluida en la cadena RCE completa según el aviso oficial | 6.8.0 a 6.8.5 | 6.8.6 o superior |
| 6.9 | Ambos CVE y cadena WP2Shell con RCE | 6.9.0 a 6.9.4 | 6.9.5 o superior |
| 7.0 | Ambos CVE y cadena WP2Shell con RCE | 7.0.0 a 7.0.1 | 7.0.2 o superior |
| 7.1 beta | La primera beta estaba afectada | 7.1 beta 1 | 7.1 beta 2 |
| Anteriores a 6.8 | No afectadas por estos dos CVE según WordPress | No aplica | Migrar igualmente a una versión mantenida |
Que una versión anterior a 6.8 no sea vulnerable a WP2Shell no significa que sea segura. Puede contener otros fallos conocidos y carecer de soporte activo. La opción correcta no es permanecer en una rama obsoleta para evitar este CVE, sino migrar a una versión actual y parcheada.
¿WP2Shell ya está siendo explotado?
La divulgación avanzó rápidamente. VulnCheck informó que comenzaron a surgir reportes de actividad en Internet y que, para el 19 de julio, ya había verificado más de dos docenas de implementaciones de prueba de concepto. La existencia de PoC públicos reduce considerablemente el conocimiento necesario para explorar instalaciones sin parchear.
Una solicitud al endpoint relacionado no demuestra por sí sola que el sitio fue comprometido: los escáneres automáticos también generan tráfico de reconocimiento. Sin embargo, encontrar solicitudes sospechosas en un sitio que permaneció vulnerable debe activar una revisión de integridad y no limitarse a instalar la actualización.
Qué podría hacer un atacante después de explotar WP2Shell
El impacto final depende de la configuración del servidor y de los permisos del usuario con el que se ejecuta PHP. Aun así, una cadena que termina en RCE puede permitir acciones graves:
Consultar o extraer información de la base de datos de WordPress.
Crear o modificar cuentas con privilegios administrativos.
Instalar una webshell o archivos PHP maliciosos.
Modificar temas, plugins, contenido o redirecciones del sitio.
Robar secretos almacenados en
wp-config.phpo en variables del entorno.Usar el sitio para distribuir malware, spam o páginas de phishing.
Mantener persistencia mediante tareas programadas, plugins falsos o usuarios ocultos.
El aislamiento del hosting importa: un sitio debe ejecutarse con su propio usuario y límites de archivos, procesos y base de datos. Un compromiso de WordPress no debería transformarse automáticamente en acceso a las demás cuentas del servidor.
Cómo actualizar WordPress y corregir WP2Shell
1. Confirma la versión instalada
Desde el panel de WordPress puedes revisar la versión en Escritorio > Actualizaciones. Si administras el sitio mediante WP-CLI:
wp core version2. Crea un respaldo verificable
Genera una copia de la base de datos y de los archivos antes del cambio, especialmente en sitios con WooCommerce, membresías o integraciones críticas. El respaldo no debe retrasar el parche: la exposición es remota y existen detalles públicos de la vulnerabilidad.
3. Instala la actualización de seguridad
En instalaciones compatibles con la última versión estable:
wp core update
wp core versionSi mantienes temporalmente una rama concreta por compatibilidad, instala al menos la versión corregida correspondiente: 6.8.6, 6.9.5 o 7.0.2. Después comprueba el funcionamiento del frontend, el panel, formularios, pagos y tareas programadas.
4. Verifica los checksums del núcleo
wp core verify-checksumsEste comando compara archivos del núcleo con las versiones oficiales. Un resultado correcto es una buena señal, pero no revisa todo wp-content, las cargas ni la base de datos; por eso no reemplaza una auditoría completa cuando existen indicios de compromiso.
Cómo revisar si un WordPress pudo ser comprometido
Revisa usuarios administradores
wp user list --role=administratorBusca cuentas desconocidas, cambios recientes de correo o administradores creados durante la ventana de exposición. No elimines una cuenta sin conservar primero evidencia si el sitio forma parte de una investigación.
Busca PHP dentro de uploads
find wp-content/uploads -type f -name '*.php' -printEn la mayoría de instalaciones, la carpeta de cargas no necesita ejecutar PHP. La presencia de un archivo PHP no confirma automáticamente malware, pero merece revisión inmediata.
Localiza archivos modificados recientemente
find . -type f -name '*.php' -mtime -7 -printCompara los resultados con despliegues, actualizaciones y cambios legítimos. Examina también plugins de nombre extraño, archivos con código ofuscado, tareas cron inesperadas y modificaciones de wp-config.php o .htaccess.
Busca tráfico hacia el endpoint batch
grep -R "/wp-json/batch/v1" /var/log/nginx/ /var/log/apache2/ 2>/dev/nullLa ruta puede aparecer por solicitudes legítimas o escaneos. Correlaciona IP, hora, código HTTP, volumen, solicitudes posteriores y cambios en archivos antes de concluir que hubo explotación.
Mitigaciones temporales si no puedes actualizar inmediatamente
La solución principal es instalar el parche. Como contención temporal, un WAF puede bloquear o restringir solicitudes anónimas al endpoint /wp-json/batch/v1. Esta medida puede romper plugins o integraciones que dependan del procesamiento por lotes de la REST API, por lo que debe probarse y retirarse después de actualizar.
No confíes únicamente en ocultar la versión de WordPress, cambiar la URL de acceso o instalar un plugin de seguridad. Esas acciones pueden reducir ruido, pero no corrigen el código vulnerable. Del mismo modo, que WordPress haya activado actualizaciones forzadas no garantiza que tu sitio se actualizara: permisos de archivos, constantes de configuración o políticas del proveedor pueden bloquear el proceso.
Qué hacer si encuentras indicios de explotación
Aísla el sitio o limita el acceso mientras conservas logs y una copia forense.
Actualiza WordPress a una versión corregida desde una fuente oficial.
Reinstala el núcleo y las extensiones legítimas desde paquetes confiables.
Elimina usuarios y mecanismos de persistencia no autorizados.
Cambia contraseñas administrativas, de base de datos, SFTP y panel de hosting.
Rota claves API y secretos accesibles desde la aplicación.
Renueva las salts de WordPress para invalidar sesiones activas.
Revisa otros sitios de la misma cuenta si comparten usuario, permisos o credenciales.
Monitorea modificaciones, inicios de sesión y tráfico después de la limpieza.
Restaurar un backup puede ser útil, pero sólo si conoces una fecha anterior al compromiso y corriges la vulnerabilidad antes de volver a exponer el sitio. Restaurar una copia vulnerable sin parchear simplemente reinicia el reloj del atacante.
Preguntas frecuentes sobre WP2Shell WordPress
¿WP2Shell afecta a todos los sitios WordPress?
No. Afecta versiones específicas de WordPress Core. Las ramas 6.9.0–6.9.4 y 7.0.0–7.0.1 están afectadas por la cadena completa; 6.8.0–6.8.5 está afectada por CVE-2026-60137.
¿Se necesita un plugin vulnerable?
No. Este incidente afecta al núcleo de WordPress. Plugins y temas pueden aumentar el impacto posterior, pero no son un requisito para la cadena descrita.
¿El atacante necesita una cuenta?
La cadena completa en las versiones afectadas puede explotarse sin autenticación. Esa es una de las razones por las que debe tratarse como una actualización urgente.
¿Qué versión debo instalar?
Instala la versión estable más reciente que soporte tu sitio. Como mínimo, usa WordPress 6.8.6, 6.9.5 o 7.0.2 según tu rama.
¿Wordfence o Cloudflare sustituyen la actualización?
No. Un WAF puede bloquear intentos conocidos y ganar tiempo, pero el parche elimina la causa. Las reglas de seguridad deben ser una capa adicional, no el reemplazo de una actualización disponible.
¿Una versión anterior a WordPress 6.8 está segura?
No está afectada por estos dos CVE según el aviso oficial, pero puede estar expuesta a otras vulnerabilidades y carecer de soporte. Debe migrarse a una rama vigente.
Checklist de respuesta para CVE-2026-63030 y CVE-2026-60137
Identificar todas las instalaciones y su versión real.
Actualizar a 6.8.6, 6.9.5, 7.0.2 o una versión posterior.
Confirmar la actualización; no asumir que el proceso automático terminó.
Ejecutar
wp core verify-checksums.Revisar administradores y archivos PHP recientes.
Buscar solicitudes a
/wp-json/batch/v1en logs históricos.Rotar credenciales si existe evidencia o no puede descartarse un compromiso.
Verificar backups y mantener monitoreo de cambios.
Aplicar aislamiento por cuenta y mínimo privilegio en el hosting.
Conclusión
WP2Shell merece una respuesta prioritaria porque combina dos fallos en WordPress Core, puede alcanzar ejecución remota de código sin autenticación en versiones afectadas y ya cuenta con investigación y pruebas de concepto públicas. La acción correcta es directa: inventariar, actualizar, verificar e investigar cualquier señal extraña.
Si administras varios sitios, automatizar el inventario y las actualizaciones reduce la ventana entre la publicación de un parche y su instalación. En un entorno de hosting WordPress administrado, el aislamiento, los respaldos y el monitoreo ayudan a contener el impacto cuando aparece una vulnerabilidad de esta magnitud. También puedes consultar nuestro análisis de CVE-2026-4020 en Gravity SMTP para entender la diferencia entre un fallo de plugin y una vulnerabilidad del núcleo.
