Los atacantes han comenzado a apuntar a dos vulnerabilidades de WordPress Core recientemente parcheadas que pueden encadenarse para ejecutar código sin autenticación. Los exploits públicos de prueba de concepto aparecieron poco después de que WordPress publicara actualizaciones de seguridad de emergencia.
La cadena de ataque, conocida como wp2shell, funciona contra las instalaciones afectadas de WordPress 6.9 y 7.0 sin requerir una cuenta válida, un complemento vulnerable o la interacción del usuario. Un atacante exitoso podría acceder al contenido de la base de datos y hacerse con el control del sitio web afectado.
Los administradores deben actualizar los sitios de WordPress 6.8 a la versión 6.8.6, los sitios de WordPress 6.9 a la 6.9.5 y los sitios de WordPress 7.0 a la 7.0.2. Los usuarios de WordPress 7.1 Beta deben instalar Beta 2 o una versión posterior.
WordPress lanzó una actualización de seguridad de emergencia
WordPress publicó suVersión de seguridad de WordPress 7.0.2el 17 de julio de 2026. La actualización aborda un problema crítico y una vulnerabilidad de alta gravedad.
La cadena de ataque wp2shell combina una falla de inyección SQL con un error de confusión de ruta por lotes de API REST. Las vulnerabilidades tienen identificadores CVE separados porque afectan diferentes partes de WordPress Core.
WordPress habilitó actualizaciones forzadas a través de su sistema de actualización automática para sitios que ejecutan versiones afectadas. Los administradores aún deben verificar cada sitio manualmente porque las actualizaciones automáticas pueden fallar o permanecer deshabilitadas en algunos entornos.
wp2shell combina dos vulnerabilidades de WordPress Core
CVE-2026-60137 es una vulnerabilidad de inyección SQL no autenticada en el parámetro Author__not_in manejado por la clase WP_Query. Afecta a las versiones de WordPress 6.8.0 a 6.8.5, 6.9.0 a 6.9.4 y 7.0.0 a 7.0.1.
CVE-2026-63030 implica confusión de rutas en el punto final por lotes de la API REST de WordPress. Puede permitir que una subrequest llegue a una devolución de llamada no deseada con restricciones de validación y ruta no sincronizadas.
Cuando los atacantes combinan las dos debilidades en WordPress 6.9 o 7.0, pueden pasar de una solicitud anónima a la inyección SQL y la ejecución remota de código. ElInforme Searchlight Cyber wp2shelldice que el ataque funciona contra una instalación estándar sin complementos adicionales.
| Vulnerabilidad | Tipo | Ramas afectadas | Impacto potencial |
|---|---|---|---|
| CVE-2026-60137 | inyección SQL | WordPress 6.8, 6.9 y 7.0 | Acceso no autorizado a la base de datos |
| CVE-2026-63030 | Confusión de ruta por lotes de API REST | WordPress 6.9 y 7.0 | Habilita la cadena RCE no autenticada |
| cadena wp2shell | Explotación combinada | Versiones afectadas de WordPress 6.9 y 7.0 | Ejecución remota de código y toma de control del sitio |
Un caché de objetos persistente cambia la exposición
Searchlight Cyber inicialmente describió el ataque como si no tuviera condiciones previas en una instalación estándar de WordPress. Un análisis posterior añadió una importante condición técnica que afecta la trayectoria del RCE.
De acuerdo aAnálisis de vulnerabilidad de WordPress de Cloudflare, CVE-2026-63030 puede habilitar la ejecución de código no autenticado a través del punto final por lotes de la API REST cuando el sitio no utiliza un caché de objetos persistente.
Muchas instalaciones estándar de WordPress no utilizan un caché de objetos persistente de forma predeterminada. Por lo tanto, los administradores deben actualizar según la versión de WordPress instalada en lugar de intentar determinar la seguridad únicamente mediante la configuración de la caché.
¿Qué versiones de WordPress se ven afectadas?
Las dos vulnerabilidades cubren diferentes rangos de versiones. WordPress 6.8 contiene el error de inyección SQL pero no la confusión de ruta de la API REST necesaria para la cadena completa de wp2shell RCE.
| Versión de WordPress | Estado de inyección SQL | estado de wp2shell RCE | Actualización requerida |
|---|---|---|---|
| Anterior a 6.8.0 | No afectado por estos CVE | No afectado | Pasar a una versión mantenida |
| 6.8.0 a 6.8.5 | Afectado | No afectado por la cadena completa | Actualizar a 6.8.6 o posterior |
| 6.9.0 a 6.9.4 | Afectado | Afectado | Actualizar a 6.9.5 o posterior |
| 7.0.0 a 7.0.1 | Afectado | Afectado | Actualizar a 7.0.2 o posterior |
| WordPress 7.1 Beta 1 | Afectado | Afectado | Actualización a 7.1 Beta 2 o posterior |
El funcionarioAnuncio de lanzamiento de WordPressconfirma que las versiones anteriores a WordPress 6.8 no se ven afectadas por estas dos vulnerabilidades.
Sin embargo, ejecutar una versión anterior no proporciona una alternativa segura a largo plazo. Las ramas de WordPress no compatibles y desactualizadas pueden contener otras vulnerabilidades y ya no recibir un mantenimiento de seguridad completo.
Los exploits públicos aparecieron después de la divulgación
Searchlight Cyber retuvo su método de explotación detallado para dar tiempo a los administradores para actualizar. Sin embargo, WordPress Core es de código abierto, lo que permite a otros investigadores comparar el código parcheado y el vulnerable.
Los proyectos públicos de prueba de concepto aparecieron poco después de la publicación de seguridad. Algunos demostraron acceso a bases de datos, extracción de hash de contraseñas o la ruta más amplia hacia la ejecución de código.
ElEntrada de vulnerabilidad de Patchstackahora clasifica CVE-2026-63030 como conocido por ser explotado. Otras empresas de seguridad también han informado de intentos contra honeypots y actividades de respuesta a incidentes que involucran sitios vulnerables.
Cómo los atacantes podrían usar wp2shell
La ejecución remota de código puede brindarle a un atacante un amplio control sobre la aplicación de WordPress y su cuenta de alojamiento, dependiendo de los permisos asignados al proceso del servidor web.
Un atacante exitoso podría potencialmente:
- Leer o modificar el contenido de la base de datos de WordPress
- Robar hashes de contraseña de administrador
- Crear cuentas de administrador no autorizadas
- Cargue shells web u otros archivos PHP maliciosos
- Redirigir a los visitantes a páginas de phishing o malware
- Inyecte JavaScript malicioso en el contenido publicado
- Acceda a la información del cliente y del pedido de WooCommerce
- Utilice el servidor para atacar otros sistemas
El acceso a WordPress no proporciona automáticamente privilegios de root o de servidor completo. Sin embargo, un sitio comprometido aún puede exponer datos confidenciales, dañar a los visitantes, perjudicar las clasificaciones de búsqueda y proporcionar un punto de apoyo para futuros ataques.
WordPress forzó actualizaciones de seguridad automáticas
WordPress tomó la inusual medida de iniciar actualizaciones forzadas para las versiones afectadas debido a la gravedad y el amplio alcance de las vulnerabilidades.
Los sitios que permiten actualizaciones automáticas en segundo plano deberían comenzar a recibir la versión parcheada adecuada. Los proveedores de hosting también podrán aplicar las actualizaciones a través de sus propias plataformas de gestión.
Los administradores deben verificar la versión instalada en lugar de asumir que la actualización se realizó correctamente. Los permisos del sistema de archivos, las configuraciones de actualización deshabilitadas, las tareas cron fallidas, los sistemas de implementación personalizados o los controles de alojamiento administrado pueden impedir una actualización automática.
Cómo actualizar WordPress manualmente
Los administradores con acceso al panel pueden instalar la versión de seguridad directamente desde WordPress.
- Inicie sesión en el panel de administración de WordPress.
- Abra el Panel y seleccione Actualizaciones.
- Verifique la versión de WordPress actualmente instalada.
- Haga clic en Actualizar ahora si hay una versión parcheada disponible.
- Confirme la nueva versión después de que se complete la actualización.
- Pruebe el sitio web y los complementos esenciales.
- Borre las cachés de aplicaciones, servidores y CDN.
Las organizaciones que administran WordPress a través de Composer, WP-CLI, imágenes de contenedores o canales de implementación automatizados deben actualizar el paquete o imagen relevante y volver a implementar el sitio.
Searchlight Cyber proporciona un verificador público
Searchlight Cyber lanzó una herramienta en línea gratuita que prueba si una instalación de WordPress parece vulnerable. La empresa explica el verificador y las mitigaciones temporales en suaviso de seguridad wp2shell.
El resultado del escáner debe admitir la verificación de la versión, no reemplazarla. Los servidores proxy inversos, los firewalls de aplicaciones web, los sistemas de almacenamiento en caché o los errores de red pueden afectar el resultado.
La verificación más segura sigue siendo confirmar que el sitio ejecuta WordPress 6.8.6, 6.9.5, 7.0.2, 7.1 Beta 2 o una versión segura posterior para su rama.
Protecciones temporales para sitios que no se pueden actualizar
Los administradores que no puedan actualizar inmediatamente pueden bloquear el acceso anónimo a la ruta por lotes vulnerable de la API REST. Estos controles pueden interrumpir integraciones legítimas que dependen de la API REST de WordPress.
- Bloquear /wp-json/batch/v1 en el firewall de la aplicación web
- Bloquear solicitudes usando rest_route=/batch/v1
- Requerir autenticación para la ruta por lotes de la API REST
- Bloquear temporalmente el acceso anónimo a la API REST
- Supervisar las solicitudes rechazadas en busca de repetidos intentos de explotación.
Se deben cubrir ambos formatos de ruta porque WordPress puede recibir solicitudes REST a través de rutas estándar o el parámetro de consulta rest_route.
Estas medidas reducen la exposición pero no reparan el código vulnerable de WordPress. Los administradores deben eliminar las restricciones temporales solo después de aplicar la actualización de seguridad oficial y confirmar que el parche se realizó correctamente.
Cloudflare implementó reglas WAF para ambos CVE
Cloudflare implementó nuevas reglas administradas el 17 de julio para detectar y bloquear el tráfico dirigido a las rutas de inyección SQL y RCE. La compañía dice que las protecciones cubren el tráfico proxy de WordPress en planes gratuitos y de pago.
ElGuía WAF de Cloudflarerecomienda verificar si hay anulaciones de conjuntos de reglas que puedan haber cambiado la acción de Bloquear a Registrar.
La protección WAF agrega una capa importante durante la implementación, pero no puede garantizar que todas las variaciones de exploit fallen. Actualizar WordPress sigue siendo la principal solución.
Cómo investigar un sitio potencialmente comprometido
Los sitios que permanecieron sin parches después de que el código de explotación público estuvo disponible deben recibir una revisión de seguridad, especialmente si los registros muestran solicitudes al punto final del lote afectado.
- Conserve registros web, WAF, autenticación y alojamiento.
- Busque solicitudes de API REST por lotes sospechosas.
- Revise las cuentas de administrador de WordPress creadas recientemente.
- Inspeccione los archivos PHP modificados recientemente y los complementos activos.
- Verifique wp-content/uploads para ver si hay archivos ejecutables inesperados.
- Revise las tareas programadas, los complementos imprescindibles y los archivos de temas.
- Rote las credenciales de WordPress, base de datos, alojamiento, SSH y API.
- Restaurar desde una copia de seguridad limpia verificada cuando se confirme el compromiso.
Cambiar las contraseñas por sí solo no eliminará un shell web, un complemento malicioso, un tema modificado o una cuenta de administrador persistente. Los administradores deben identificar y eliminar todos los mecanismos de persistencia antes de devolver el sitio al servicio.
ElRegistro de Patchstack wp2shellaconseja a los propietarios de sitios que actualicen inmediatamente y enumera WordPress 7.0.2 como la versión parcheada para la rama 7.0.
Los sitios protegidos por complementos de seguridad o WAF externos aún deberían instalar la actualización oficial. Las reglas de firewall pueden reducir el riesgo mientras se implementa una actualización, pero no corrigen las vulnerabilidades principales subyacentes.
Los proveedores de alojamiento y las agencias deben hacer un inventario de todos los sitios de WordPress administrados, incluidos los sistemas de prueba, los dominios de desarrollo, las instalaciones abandonadas y los sitios ocultos detrás de nombres de host no estándar.
Investigadores acreditados por las correcciones de WordPress
WordPress le dio crédito a Adam Kues de Assetnote y Searchlight Cyber por informar sobre la confusión de rutas por lotes de la API REST y la cadena de inyección SQL que condujo a la ejecución remota de código.
El equipo de seguridad de WordPress atribuyó por separado a TF1T, dtro y haongo el informe conjunto del problema de inyección SQL rastreado como CVE-2026-60137.
La aparición de exploits públicos y de intentos de ataque reportados hace que la verificación inmediata de parches sea esencial. Los administradores no deben confiar únicamente en actualizaciones forzadas, un WAF o un escáner de vulnerabilidades cuando pueden confirmar directamente la versión de WordPress instalada.
Preguntas frecuentes
¿Cuál es la vulnerabilidad de WordPress wp2shell?
wp2shell es una cadena de ataque que combina CVE-2026-60137, una falla de inyección SQL, con CVE-2026-63030, una vulnerabilidad de confusión de rutas por lotes de API REST. Juntos, pueden permitir la ejecución remota de código sin autenticación en los sitios afectados de WordPress 6.9 y 7.0.
¿Qué versiones de WordPress reparan wp2shell?
WordPress 6.9.5 y 7.0.2 corrigen la cadena completa de wp2shell RCE. WordPress 6.8.6 corrige la inyección SQL que afecta a la rama 6.8, mientras que WordPress 7.1 Beta 2 contiene ambas correcciones.
¿Wp2shell requiere un complemento de WordPress vulnerable?
No. Las vulnerabilidades existen en WordPress Core y pueden afectar una instalación estándar sin complementos de terceros. El ataque no requiere una cuenta válida de WordPress ni la interacción del usuario.
¿Los atacantes están explotando wp2shell?
Sí. El código de prueba de concepto público está disponible y las empresas de seguridad han informado de intentos de explotación contra sitios de WordPress sin parches. Los administradores deben actualizar y revisar los sitios expuestos en busca de signos de compromiso.