Elementor Pro: parche no elimina webshell, revisa tu sitio
El 19 de agosto de 2026, Elementor lanzó la actualización que corrige la vulnerabilidad CVE-2026-32475 en su plugin Elementor Pro. Ese mismo día, los atacantes comenzaron a explotarla. En los primeros cinco días, Wordfence bloqueó más de 190,000 intentos de ataque. 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 entró antes que tú. Con más de 6 millones de instalaciones activas y una prueba de concepto pública en GitHub, la carrera ya estaba perdida para quienes confiaban en parchar en una semana.
La vulnerabilidad en el manejo de archivos
El problema radica 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 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 generado por 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 condiciones previas varían según las fuentes: 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 de múltiples archivos. La prueba de concepto asume que no hay CAPTCHA y que el directorio de cargas ejecuta PHP.
Cómo detectar una webshell
En un sitio sano, el primer comando de búsqueda 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 aleatorio del archivo. 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 lo que hay en disco.
Qué hacer si encuentras una webshell
No basta con borrarla. 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 su URL 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 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 cierra la primera, pero solo la caza activa cierra la segunda. La mayoría de los equipos cierran el ticket en “actualizado”. Por eso, implementa la mitigación que no depende de la velocidad de parcheo: nunca permitas la ejecución de PHP desde el directorio de cargas. 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 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 en los que el directorio de cargas todavía ejecuta PHP? ¿Qué te impide desactivarlo hoy mismo?
