Desarrollo Web
Una de las noticias más impactantes en el ámbito de la ciberseguridad web involucra al motor que impulsa más del 40% de los sitios de internet: WordPress. A diferencia de la gran mayoría de incidentes en este CMS —que suelen originarse en complementos (plugins) de terceros o temas desactualizados—, esta vez la falla reside directamente en el núcleo (core) de WordPress.
Los sitios que ejecuten versiones vulnerables de WordPress y no hayan aplicado las actualizaciones de seguridad pueden verse comprometidos.
Se ha descubierto una cadena de vulnerabilidades críticas en WordPress que permite alcanzar una ejecución remota de código (RCE) cuando se combinan ambos fallos.
¿En qué consiste la amenaza?
El ataque combina dos errores independientes que, al encadenarse de forma magistral, logran eludir todas las barreras de autenticación y sanitización de WordPress:
- Confusión de Rutas (Route Confusion) en la API REST
- Inyección SQL Ciega (Blind SQL Injection) en el motor de consultas de publicaciones
Dato clave: Según el aviso oficial están afectadas: WordPress 6.9, WordPress 6.8 (solo una de las vulnerabilidades) y WordPress 7.1 beta. Las versiones antiguas anteriores a 6.8 no están afectadas por esta cadena concreta.
Desglose Técnico: La Cadena de Explotación (Exploit Chain)
[Atacante Sin Autenticar]
│
▼
1. Desalineación en batch/v1 ──► Evade la validación de peticiones GET
│
▼
2. Inyección SQL en author__notin ──► Salta la sanitización de author__excludes
│
▼
3. Envenenamiento de Caché (oEmbed) ──► Extrae IDs e Inyecta Usuario Admin
│
▼
[Subida de Plugin / Web Shell] ──► ¡Control Total (RCE)!
1. El fallo de enrutamiento en batch/v1 (CVE-1)
En octubre de 2020, WordPress introdujo el endpoint /wp/v2/batch/v1. Su objetivo era optimizar el rendimiento del editor agrupando hasta 25 peticiones REST en una sola llamada de red.
El controlador de este endpoint genera dos arreglos en paralelo: matches (coincidencias) y validation (validación), utilizando un mismo índice. Si una subpetición falla en la función wp_parse_url, anteriormente se añadía el error a validation, pero no a matches. Esto provocaba un desfase de índices (array mismatch), permitiendo despachar una petición bajo un controlador incorrecto y logrando ejecutar peticiones GET a través de un canal reservado exclusivamente para POST.
2. Inyección SQL Ciega en WP_Query
Al lograr desviar la petición mediante la confusión de rutas, el atacante puede interactuar con parámetros internos de consulta como author__notin.
Normalmente, el parámetro author__excludes sanitiza los valores antes de pasarlos a author__notin. Sin embargo, al ingresar mediante la ruta manipulada, la sanitización previa se omite por completo, permitiendo inyectar código SQL directamente en la base de datos de WordPress.
3. La genialidad del Object Cache Poisoning
En una inyección SQL ciega tradicional, el atacante debe recurrir a retardos de tiempo (SLEEP()) para extraer información carácter por carácter, lo cual es lento y ruidoso.
En este exploit, la PoC (Proof of Concept) utiliza la inyección SQL no para leer contraseñas, sino para envenenar la caché interna de oEmbed. Esto le permite:
- Revelar identificadores de publicaciones temporales en caché.
- Alterar conjuntos de cambios del personalizador (customizer).
- Forzar a WordPress a ejecutar una llamada interna con privilegios elevados para crear un nuevo usuario con rol de Administrador.
- Iniciar sesión con la cuenta creada y subir un complemento malicioso que contiene una Web Shell.
El Rol de la Inteligencia Artificial en el Desarrollo del Exploit
Un aspecto que ha encendido las alarmas en la comunidad de seguridad es la velocidad con la que se desarrolló este exploit.
Tras la divulgación inicial de los parches de seguridad, una PoC totalmente funcional apareció en menos de 10 horas. Investigadores de firmas como Tenable señalan que la complejidad para encadenar la confusión de rutas con el envenenamiento de caché en un tiempo tan reducido sugiere el uso de herramientas de IA avanzadas para analizar los diffs del código y armar la cadena de ataque automáticamente.
Además, sobre la explotación activa, el INCIBE añadió posteriormente una actualización indicando que ya se estaban observando intentos de explotación en Internet, por lo que el riesgo es real e inminente.
Versiones Afectadas y Estado de Parches
| Estado | Versiones de WordPress |
|---|---|
| No Afectadas | Versiones anteriores a 6.8 |
| Vulnerables (¡Riesgo Crítico!) | 6.9, 6.8 (solo una de las vulnerabilidades) y 7.1 beta |
| Protegidas (Parcheadas) | Versiones con el parche de seguridad oficial aplicado |
¿Qué debes hacer para proteger tu sitio web?
1. Actualiza inmediatamente
Si administras sitios en WordPress, verifica la versión instalada y aplica inmediatamente los parches de seguridad oficiales correspondientes a tu rama. El parche introduce la alineación de índices en el controlador de peticiones batch y valida estrictamente los tipos de datos en las consultas de autores.
2. ¿Sospechas de un compromiso? Plan de Remediación
Debido a que la ejecución de código otorga acceso al usuario del servidor web (por ejemplo, www-data), y dado que existen múltiples vulnerabilidades de Escalada Local de Privilegios (LPE) en el kernel de Linux recientemente publicadas, es muy probable que un atacante haya obtenido acceso de superusuario (root).
Si confirmas que tu servidor fue vulnerado:
- No intentes solo "limpiar" el sitio: Un atacante con acceso root puede haber dejado puertas traseras (backdoors) a nivel del sistema operativo.
- Reconstruye el entorno: Despliega una nueva instancia/servidor limpio, restaura la base de datos limpia, audita los usuarios administradores y vuelve a desplegar el código parcheado.
