El 19 de agosto de 2026, Elementor lanzó el parche para la vulnerabilidad crítica CVE-2026-32475, que afecta a Elementor Pro en versiones 4.2.1 y anteriores. Ese mismo día, los atacantes comenzaron a explotarla masivamente. En solo cinco días, Wordfence bloqueó más de 190,000 intentos de explotación. Si tu sitio corrió Elementor Pro 4.2.1 o una versión anterior durante esa ventana, actualizar es solo el segundo paso. Lo primero es averiguar si alguien ya plantó una webshell antes de que parcharas.
Elementor Pro tiene más de 6 millones de instalaciones activas y un proof-of-concept (PoC) público en GitHub. La promesa de “parcheamos en una semana” perdió esta carrera antes de empezar. Hoy, 8 de octubre de 2026, la amenaza sigue latente: los sitios que se actualizaron pero no revisaron su sistema pueden albergar backdoors activos.
¿Cómo funciona el exploit de CVE-2026-32475?
La vulnerabilidad reside en dos bucles en el archivo modules/forms/fields/upload.php que no se ponen de acuerdo sobre tu carga de archivos. El atacante envía el campo de carga como un arreglo: el primer elemento vacío y el segundo con un payload PHP. La función validation() se topa con la entrada vacía (error UPLOAD_ERR_NO_FILE) y aborta, sin inspeccionar el segundo archivo. Mientras tanto, process_field() omite la entrada vacía y mueve el archivo .php a wp-content/uploads/elementor/forms/ con un nombre único generado por uniqid(), conservando la extensión .php del atacante.
La entrega es un solo POST a /wp-admin/admin-ajax.php con la acción elementor_pro_forms_send_form. Sin autenticación, sin nonce. Las fuentes difieren en 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 carga múltiple. El PoC asume que no hay CAPTCHA y que el directorio de cargas ejecuta PHP.
¿Tu sitio ya fue comprometido? Señales de una webshell
Puedes pasar una tarde reconstruyendo la configuración exacta de tu formulario de agosto, o diez minutos buscando la shell. Una de esas acciones resuelve la pregunta. En un sitio sano, el primer comando no devuelve nada. Cualquier archivo con eval, base64_decode, shell_exec o una puerta $_REQUEST es una shell.
El exploit es de dos pasos: primero un POST al manejador del formulario, luego un GET al archivo depositado para ejecutar comandos. Los cuerpos POST no se registran por defecto, pero el GET sí, con nombre de archivo aleatorio incluido. El patrón es claro: 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.
Otras señales de alerta:
- Administrador desconocido.
- Evento cron extraño.
- Suma de verificación fallida.
Si detectas alguna, asume compromiso total.
Pasos para verificar y limpiar tu instalación
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.
¿Encontraste una shell? No la borres sin más. Sigue este protocolo:
- Cópiala a un lugar seguro.
- Registra las marcas de tiempo.
- Extrae los logs alrededor de su creación.
- Bloquea su URL en el servidor web.
- Rota todo lo que la shell pudo leer: credenciales de la base de datos en wp-config.php, contraseñas de administrador, claves API.
- Regenera las sales de WordPress para matar sesiones activas.
Si la shell fue accesible por más de uno o dos días, restaura desde un respaldo anterior al primer POST malicioso. Limpiar un sitio en el que un atacante ha vivido semanas es un juego de confianza que normalmente se pierde.
La ventana que el parche no cierra
Existen dos ventanas: la de vulnerabilidad y la de permanencia (dwell time). El parche solo cierra la primera. Solo la caza activa cierra la segunda, y la mayoría de los equipos cierran el ticket en “actualizado”.
Por eso, implementa la mitigación que no depende de la velocidad del parche: nunca ejecutes PHP desde el árbol de uploads. En Apache con mod_php, php_flag engine off en un .htaccess funciona, pero esa directiva no hace nada bajo PHP-FPM, que es lo que corren 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 tienes donde los uploads aún ejecutan PHP, y qué te impide matar esa posibilidad hoy mismo?
Para una cronología completa y pasos de contención más detallados, consulta el análisis extendido en axeploit.com.
