El pasado 19 de agosto, Elementor lanzó el parche para la vulnerabilidad CVE-2026-32475 en su plugin 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 período, actualizar es lo segundo que debes hacer. Lo primero es averiguar si alguien ya había entrado antes de que parchearas. Con más de 6 millones de instalaciones activas y un proof of concept público en GitHub, la carrera ya estaba perdida para quienes confían en parchear en una semana.
La vulnerabilidad y su explotación
La falla reside en una discrepancia entre dos bucles en el archivo modules/forms/fields/upload.php. El atacante envía el campo de carga de archivos como un arreglo: el primer elemento vacío y el segundo con el payload PHP. La función validation() encuentra 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/ con un nombre generado por uniqid(), conservando la extensión .php del atacante. 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 se 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 carga múltiple de archivos. El PoC asume que no hay CAPTCHA y que el directorio de uploads ejecuta PHP. Puedes pasar una tarde reconstruyendo la configuración exacta de tu formulario en agosto, o diez minutos buscando la webshell. Una de esas acciones resuelve la pregunta.
Cómo detectar una webshell
En un sitio saludable, 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 malicioso para ejecutar comandos. Los cuerpos de los POST no se registran por defecto, pero el GET sí, incluyendo el nombre de archivo aleatorio. 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 webshell se ejecutó. Compromiso confirmado.
Si encuentras 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 compara con el disco.
Qué hacer si encuentras una webshell
No basta con eliminar el archivo. Sigue estos pasos:
- Copia la webshell a un lugar seguro para su análisis.
- Registra las marcas de tiempo y extrae los logs alrededor de su creación.
- Bloquea la URL de la webshell en el servidor web.
- Rota todas las credenciales que la webshell pudo leer: credenciales de la base de datos en
wp-config.php, contraseñas de administrador, claves de API. - Regenera las sales de WordPress para invalidar sesiones activas.
Si la webshell estuvo accesible más de uno o dos días, restaura desde una copia de seguridad anterior al primer POST malicioso. Limpiar un sitio que un atacante ha habitado durante semanas es una apuesta que generalmente se pierde.
Más allá del parche: la ventana de permanencia
Existen dos ventanas: la de vulnerabilidad y la de permanencia. El parche solo cierra la primera. Solo la caza cierra la segunda, y la mayoría de los equipos cierran el ticket con “actualizado”. Por eso, implementa la mitigación que no depende de la velocidad del parche: nunca permitas la ejecución de PHP desde el directorio de uploads. 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 los uploads aún ejecutan PHP y qué te impide desactivar esa capacidad hoy mismo?
Contexto para Latinoamérica
En México y América Latina, una gran cantidad de sitios web corporativos, gubernamentales y de comercio electrónico utilizan WordPress con Elementor Pro por su facilidad de uso. La exposición a esta vulnerabilidad es significativa, especialmente porque muchas organizaciones no cuentan con equipos dedicados de seguridad informática. La recomendación es urgente: verificar si el sitio fue comprometido, aplicar el parche si no se ha hecho, y establecer políticas de monitoreo continuo. La seguridad no termina con la actualización; la detección temprana y la respuesta rápida marcan la diferencia entre un incidente contenido y una brecha devastadora.
Conclusión
El parche de Elementor Pro para CVE-2026-32475 es indispensable, pero no suficiente. La webshell puede permanecer oculta incluso después de actualizar. Revisa tus logs, busca indicadores de compromiso, y si encuentras algo, actúa con contundencia. La ventana de permanencia solo se cierra con una caza proactiva. No cierres el ticket sin antes asegurarte de que tu sitio está limpio.
