Vulnerabilidad crítica en Elementor Pro permite RCE por subida de archivos sin autenticación

Investigadores de seguridad han publicado los detalles de una vulnerabilidad crítica en Elementor Pro —registrada como CVE-2026-32475— que permite a un atacante sin autenticación subir archivos peligrosos y, en escenarios comunes, obtener ejecución remota de código (RCE) en sitios WordPress que usen el plugin vulnerable. El fallo tiene una puntuación CVSS de 9.0/10.0 y afecta a todas las versiones de Elementor Pro anteriores y hasta la 4.2.1; el fabricante liberó un parche en la versión 4.2.2 el 19 de agosto tras el reporte del investigador Tin Pham a través del programa de recompensas de Patchstack.

Qué está confirmado: la vulnerabilidad reside en el campo de subida de archivos del módulo de Formularios de Elementor Pro. La comprobación de extensión del archivo y el movimiento del archivo subido al directorio público se ejecutan en dos bucles separados y tratan entradas de archivo vacías de forma distinta. Un atacante puede enviar dos partes (multipart) con el mismo nombre de campo; esa táctica salta la lista de bloqueo de extensiones y provoca que un archivo PHP termine en wp-content/uploads/elementor/forms/<uniqid>.php, donde <uniqid> es el valor devuelto por PHP uniqid(). El descubridor y Patchstack han verificado que este flujo convierte un control de subida aparentemente restringido en un vector de RCE cuando el servidor interpreta y ejecuta archivos PHP desde ese directorio.

Condiciones necesarias (confirmadas): para explotar el fallo se necesita únicamente que el sitio tenga al menos una página publicada de Elementor que incluya un widget de Formulario con un campo de subida de archivos. El campo suele estar en su configuración por defecto con "Required" desactivado, por lo que es una configuración muy común (formularios de empleo, tickets de soporte, adjuntos, etc.). No se requiere que el atacante tenga cuenta en el sitio.

Cómo funciona técnicamente (reconstrucción del vector): al recibir un formulario multipart/form-data, el código de Elementor valida extensiones de cada parte y después mueve el archivo aceptado a la ruta pública. Si el servidor recibe dos partes con el mismo nombre de campo, una puede ser procesada como "vacía" por el primer bucle (saltando la comprobación de extensión) y la otra puede ser la que finalmente se mueve al destino público sin que se vuelva a aplicar la lista de bloqueo. Ese desfase lógico entre validación y persistencia permite que un archivo con extensión .php (o con payload PHP embebido) acabe en el directorio público y sea ejecutable por el motor PHP del servidor.

Consecuencias reales: la explotación exitosa permite subir un webshell o cualquier script PHP con contenido malicioso que, al ser solicitado por el atacante, ejecutará código en el servidor web con los mismos privilegios que el proceso PHP. En la práctica esto puede derivar en defacement, persistencia con puertas traseras, despliegue de malware (por ejemplo, droppers que diseminen ransomware), uso del sitio como distribución de malware o nodo de comando y control, y exfiltración de datos. Dado el amplio uso de formularios con adjuntos, el vector es aplicable a una gran cantidad de sitios que usan Elementor Pro con formularios expuestos.

Qué no está confirmado (incertidumbres): hasta la publicación no hay datos públicos verificados sobre explotación masiva en estado salvaje (zero-day) antes del parche. Tampoco se ha cuantificado el número exacto de instalaciones vulnerables en producción ni si existen variantes del exploit que requieran distintos entornos. Es razonable estimar que sitios sin actualizaciones automáticas y con formularios públicos son objetivos probables, pero el alcance real de ataques dirigidos sigue siendo incierto.

Medidas inmediatas y priorizadas para administradores: la acción más urgente y recomendable es actualizar Elementor Pro a la versión 4.2.2 o posterior. Si no puede aplicarse la actualización de inmediato, implemente al menos una de estas mitigaciones temporales:

- Desactivar o eliminar temporalmente cualquier Form widget que incluya un File Upload en páginas públicas hasta aplicar el parche.

- Bloquear la ejecución de PHP en el directorio afectado (wp-content/uploads/elementor/forms). En servidores Apache/Nginx se puede impedir que el servidor trate archivos .php allí mediante una directiva de configuración o un .htaccess; esto evita que un .php subido sea interpretado como código aunque exista en disco.

- Inspeccionar y limpiar el directorio de upload: busque archivos .php en wp-content/uploads/elementor/forms y en general en wp-content/uploads. Por ejemplo, desde consola: find wp-content/uploads/elementor/forms -type f -name '*.php' -maxdepth 1 (ajuste según su entorno). Si encuentra archivos PHP que no deberían estar, trátelos como indicio de compromiso: muévalos fuera, cámbieles nombre y analícelos en un entorno seguro, y revise timestamps y logs de acceso.

- Revisar registros y cuentas: compruebe logs de acceso web por peticiones a rutas elementor/forms/*.php y revise la lista de usuarios, sesiones y cambios recientes; si hay actividad sospechosa, considere el bloqueo temporal del sitio y un análisis forense. Cambie claves de administrador y de FTP/SSH si hay indicios de intrusión.

- Añadir reglas WAF / ModSecurity para filtrar subidas multipart sospechosas (por ejemplo, solicitudes con dos partes con el mismo nombre de archivo o con extensiones .php en campos de upload). Aunque no es infalible, un WAF puede mitigar intentos automatizados.

- Escanear el sitio con herramientas especializadas: utilice escáneres de seguridad orientados a WordPress como WPScan o soluciones de endpoint/antimalware (Wordfence, Sucuri, etc.) y herramientas de búsqueda de webshells. Realice también una auditoría de plugins y temas para detectar modificaciones no autorizadas y plugins desconocidos.

Contexto y recomendaciones a medio plazo: este incidente coincide con otras vulnerabilidades recientes en la cadena WordPress que han permitido RCE mediante subidas de archivos maliciosos, por lo que es urgente que administradores adopten políticas robustas de gestión de parches, principio de menor privilegio y segmentación. Bloquear ejecución de scripts en directorios de uploads es una práctica de hardening que reduce el impacto de fallos similares. Para más información técnica sobre la vulnerabilidad pública y la entrada de CVE, consulte la ficha en el NIST/NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-32475, y detalles y contexto del descubrimiento en la plataforma del investigador a través de Patchstack: https://patchstack.com/.

Conclusión: la lógica incorrecta entre validación y persistencia en un componente de formularios convierte un punto de entrada cotidiano en un vector de alto riesgo. Actualizar a Elementor Pro 4.2.2 es la medida inmediata y definitiva; mientras tanto, desactivar campos de subida expuestos, prohibir la ejecución de PHP en uploads y escanear activamente en busca de webshells son pasos concretos que reducen significativamente el riesgo de compromiso.