El 19 de agosto de 2026, Elementor lanzó la actualización que corrige la vulnerabilidad CVE-2026-32475 en Elementor Pro. Ese mismo día, los atacantes comenzaron a explotarla y Wordfence bloqueó más de 190,000 intentos en los primeros cinco días. Si tu sitio ejecutó Elementor Pro 4.2.1 o una versión anterior durante ese periodo, actualizar es solo el segundo paso. Lo primero es averiguar si alguien ya había plantado una webshell antes de que parcharas.
La vulnerabilidad afecta a más de 6 millones de instalaciones activas y existe un proof of concept (PoC) público en GitHub, lo que facilita su explotación masiva. La lección es clara: la promesa de “parcheamos en una semana” perdió esta carrera antes de empezar.
¿Cómo funciona el exploit?
El fallo reside en dos bucles dentro de modules/forms/fields/upload.php que no se ponen de acuerdo sobre cómo manejar la subida de archivos. El atacante envía el campo File Upload como un arreglo: el primer elemento vacío y el segundo con una carga útil PHP. La función validation() se topa con la entrada vacía (UPLOAD_ERR_NO_FILE) y aborta, sin inspeccionar el segundo archivo. Por su parte, process_field() omite la entrada vacía y mueve el archivo .php a wp-content/uploads/elementor/forms/ bajo un nombre generado con uniqid(), conservando la extensión maliciosa.
La entrega se realiza con una sola petición POST a /wp-admin/admin-ajax.php con la acción elementor_pro_forms_send_form. No requiere autenticación ni nonce. Las fuentes discrepan sobre las precondiciones: Wordfence indica que el campo no debe estar marcado como obligatorio; el aviso del proveedor, según BleepingComputer, apunta a la opción de subida múltiple de archivos. El PoC asume que no hay CAPTCHA y que el directorio de subidas ejecuta PHP.
Detecta la webshell antes de cerrar el ticket
En lugar de perder una tarde reconstruyendo la configuración exacta de tu formulario en agosto, invierte diez minutos en buscar la shell. En un sitio sano, el primer comando no devuelve nada. Cualquier archivo que contenga eval, base64_decode, shell_exec o una puerta $_REQUEST es una webshell.
El exploit consta de dos pasos: primero un POST al manejador del formulario, luego un GET al archivo depositado para ejecutar comandos. Los cuerpos de las peticiones POST no se registran por defecto, pero el GET sí, incluyendo el nombre aleatorio del archivo. El patrón es inconfundible: la misma IP hace POST a admin-ajax.php y minutos después GET a un archivo .php bajo el directorio de formularios. Un código 200 en ese GET significa que la shell se ejecutó. Compromiso confirmado.
Si encuentras indicios como un administrador desconocido, un evento cron extraño o una suma de verificación fallida, asume un compromiso total. Elementor Pro es premium, por lo que wp plugin verify-checksums no puede validarlo contra wordpress.org. Descarga una copia limpia desde tu cuenta de Elementor y compárala con la que está en disco.
Contención y recuperación
¿Encontraste una shell? No la borres sin más. Cópiala en un lugar seguro, registra las marcas de tiempo, extrae los logs alrededor de su creación y bloquea su URL en el servidor web. Luego rota todo lo que la shell pudo leer: las credenciales de la base de datos en wp-config.php, las contraseñas de administrador, las claves de API y regenera las sales de WordPress para matar sesiones activas.
Si la shell estuvo accesible más de uno o dos días, restaura desde una copia de seguridad anterior al primer POST malicioso. Limpiar un sitio en el que un atacante ha vivido durante semanas es una apuesta que normalmente se pierde.
La ventana que el parche no cierra
Existen dos ventanas: la de vulnerabilidad y la de permanencia. El parche solo cierra la primera. Solo la caza activa cierra la segunda, y la mayoría de los equipos cierran el ticket con un simple “actualizado”.
Por eso, implementa la mitigación que no depende de la velocidad de parcheo: nunca ejecutes PHP desde el árbol de subidas. En Apache con mod_php, php_flag engine off en un archivo .htaccess funciona, pero esa directiva no hace nada bajo PHP-FPM, que es lo que ejecutan la mayoría de los stacks modernos. En su lugar, deniega los archivos: la opción “Disable Code Execution for Uploads directory” de Wordfence logra el mismo resultado.
Pregunta honesta: ¿cuántos sitios WordPress administras donde el directorio de subidas todavía ejecuta PHP? ¿Qué te impide desactivar esa capacidad hoy mismo?
