Dos vulnerabilidades críticas en WordPress ya están siendo atacadas de forma masiva
Los atacantes han comenzado a explotar dos vulnerabilidades críticas en WordPress que, combinadas, permiten la ejecución remota de código (RCE) no autenticada y el compromiso total de sitios web vulnerables. Las fallas de seguridad, registradas como CVE-2026-63030 y CVE-2026-60137, han sido denominadas wp2shell.
Según Jake Knott, investigador principal de seguridad en watchTowr, para la madrugada del sábado (UTC) la explotación ya estaba en pleno apogeo, inicialmente utilizando código de exploit público para extraer credenciales hasheadas, y luego logrando ejecución remota de código una vez que se publicaron detalles adicionales. 'Desde nuestro punto de vista, en una base global de clientes, estamos viendo un impacto generalizado de esta vulnerabilidad en organizaciones de todos los tamaños y sectores', afirmó.
Escaneos masivos desde múltiples países
Datos de telemetría capturados por KEVIntel muestran que 13 direcciones IP de Suiza, Alemania, Reino Unido, Indonesia, Lituania, Países Bajos y Singapur están vinculadas a la explotación de CVE-2026-63030. Ryan Dewhurst, fundador y CEO de KEVIntel, indicó que la explotación ha pasado de apuntar a sensores específicos de WordPress a un escaneo generalizado de Internet, con solicitudes que coinciden con exploits de prueba de concepto (PoC) públicos.
Los atacantes utilizaron múltiples técnicas de inyección SQL, incluyendo payloads ciegos, basados en UNION y booleanos. En nuestras propias pruebas, el análisis asistido por IA hizo trivial reproducir la vulnerabilidad y desarrollar un PoC funcional. Esto reduce significativamente la barrera técnica para producir código de exploit una vez que los detalles de la vulnerabilidad están disponibles públicamente.
Dewhurst añadió que la cadena de explotación, descubierta por Searchlight Cyber utilizando OpenAI GPT 5.6 Sol en más de 10 horas, permite esencialmente que atacantes no autenticados obtengan ejecución remota de código en instalaciones predeterminadas de WordPress en cualquier versión lanzada desde diciembre de 2025. Los detalles técnicos se han retenido debido a la gravedad del problema.
El ataque no tiene condiciones previas y puede ser explotado por un usuario anónimo en una instalación estándar de WordPress sin plugins.
Detalles técnicos de las vulnerabilidades
Según Cloudflare, CVE-2026-63030 permite RCE no autenticada solo cuando no se utiliza caché de objetos persistente. Mientras que la vulnerabilidad de inyección SQL (CVE-2026-60137) está presente desde la versión 6.8, la RCE afecta a versiones desde la 6.9. Ben Marr, ingeniero de seguridad en Intruder, explicó: 'Este exploit utiliza una cadena de dos partes para lograr una inyección SQL no autenticada en una instalación estándar con una sola solicitud HTTP. CVE-2026-60137 es el punto de entrada: un error de confusión de rutas en el endpoint por lotes de la API REST que evita la autenticación, permitiendo a un atacante invocar controladores internos sin ninguna comprobación de permisos'.
Marr añadió: 'Esta falla surge de la sanitización incorrecta del parámetro 'author__not_in' dentro de 'WP_Query' cuando se pasan datos no confiables a través de un plugin o tema. Esta vulnerabilidad permite que una entrada manipulada altere una consulta de base de datos, lo que podría llevar a acceso no autorizado o manipulación de datos'.
Impacto y actividades posteriores a la explotación
Datos de Wiz, propiedad de Google, sugieren que el 60% de las organizaciones que usaban WordPress tenían al menos una instancia vulnerable cuando se publicaron estos CVE, y el 25% exponía un servidor vulnerable a Internet. Estas cifras han disminuido a medida que las organizaciones aplican las correcciones.
Wiz ha observado las siguientes actividades posteriores a la explotación: subida de un plugin malicioso, enumeración de usuarios y recolección de nombres de usuario administradores y direcciones de correo, ataques de inclusión local de archivos (LFI) para apuntar a credenciales de base de datos y claves de autenticación, acceso al panel de administración y autenticación exitosa, y subida de un webshell PHP básico que facilita la ejecución remota de código.
También hemos observado actividad de escaneo de alto volumen sin posterior explotación, lo que sugiere campañas de escaneo masivo oportunistas que buscan identificar objetivos vulnerables junto con actividad de escaneo de seguridad legítima. Aún no hemos identificado movimiento lateral o exfiltración de datos, pero continuamos monitoreando e investigando.
Como parte de la actividad, se ha observado un webshell de 150 KB disfrazado como un plugin de seguridad legítimo de WordPress llamado CMSmap. Actúa como una 'plataforma de ataque completa' que soporta gestión de archivos, acceso a bases de datos, escaneo de puertos, inyección de código por lotes y múltiples módulos de escalada de privilegios, incluyendo explotación de UDF de MySQL.
WatchTowr también informó que los atacantes han comenzado a escanear Internet de manera indiscriminada tras la publicación de un exploit público, con sus honeypots registrando 'decenas de miles de intentos de explotación'. Se dice que se han creado más de 100 cuentas de administrador de puerta trasera tras la explotación, permitiendo a los atacantes desplegar plugins falsos de WordPress para obtener ejecución de código o descargar herramientas secundarias para comprometer aún más el sistema. En al menos un caso, se observó a un actor de amenazas intentando repetidamente instalar Overlord RAT, un troyano de acceso remoto basado en Golang.
Recomendaciones para mitigar la amenaza
Se recomienda a los defensores inspeccionar sus instancias de WordPress en busca de nuevas cuentas de administrador, plugins maliciosos u otros archivos sospechosos, independientemente de si han sido parcheadas, para erradicar por completo la amenaza.
WordPress ha soportado actualizaciones automáticas en segundo plano para versiones de seguridad durante varios años, y algunos proveedores de infraestructura recibieron aviso anticipado y pudieron desplegar parches virtuales rápidamente. Estas medidas redujeron la ventana de exposición para sitios que se actualizaron automáticamente o estaban protegidos por las reglas WAF relevantes. Sin embargo, los sitios donde las actualizaciones automáticas estaban deshabilitadas, no eran compatibles o no tuvieron éxito pueden seguir siendo vulnerables. Dada la escala de implementación de WordPress en la web, un número significativo de instalaciones puede no estar parcheado. Los operadores de sitios que permanecieron vulnerables después de la publicación del código de exploit público deben actualizar inmediatamente y revisar sus sistemas en busca de indicadores de compromiso, en lugar de asumir que aplicar el parche es suficiente.
Deja una respuesta