Si gestionas webs en WordPress y tienes Elementor Pro o Super Forms instalados, para el café y mira la versión antes de seguir leyendo. No es una alerta genérica de «actualiza cuando puedas». Desde mediados de julio y agosto de 2026 hay una campaña activa que explota dos fallos críticos de subida de archivos sin autenticación, y Wordfence ha bloqueado más de 440.000 intentos entre ambos plugins. Yo lo he visto en clientes que confiaban en el aviso amarillo del panel: «todo bajo control, solo hay que actualizar el fin de semana». El fin de semana ya pasó tres veces.
El problema no es que WordPress sea inseguro por defecto. El problema es que dos plugins premium, muy extendidos en tiendas y landings con formularios de captación, permiten a cualquien subir un archivo PHP y ejecutarlo en el servidor. Sin login. Sin permisos. Solo hace falta que el formulario tenga un campo de subida de ficheros activo, condición que en Elementor Pro se cumple en cuanto tienes una página publicada con un widget Form que lo incluye.
Dos CVE, mismo modus operandi
El primero es CVE-2026-14894 en Super Forms (versiones hasta 6.3.313). CVSS 9.8. Falta validación del tipo de archivo en la subida, así que un atacante puede colgar un .php donde debería ir un PDF. Parche en la 6.3.314.
El segundo es CVE-2026-32475 en Elementor Pro (hasta 4.2.1). Misma familia de fallo: bypass en la validación del widget de formulario con campo File Upload. También CVSS crítico. Parche en la 4.2.2. El registro oficial del NVD lo publicó el 19 de agosto de 2026, y la explotación empezó casi al día siguiente según los datos de Wordfence recogidos por The CyberSec Guru.
Lo que me preocupa no es el vector técnico, que ya lo hemos visto en otros plugins de formularios. Lo que me preocupa es la escala: más de 250.000 intentos contra Super Forms y más de 190.000 contra Elementor Pro solo en lo que llevan contabilizado. Picos de más de 40.000 peticiones en un solo día. Eso no es un script kiddie aburrido; es escaneo industrial.
Lo que el panel no te dice
Entra en cualquier sitio comprometido y lo primero que buscan los equipos de respuesta son webshells en rutas predecibles: /wp-content/uploads/elementor/forms/ y /wp-content/uploads/superforms/. Si encuentras un .php ahí que no reconoces, asume intrusión hasta demostrar lo contrario.
Y aquí viene la parte que nadie quiere oír: actualizar el plugin no revierte una intrusión previa. El parche cierra la puerta; no echa al intruso que ya está dentro. He visto proyectos donde el cliente actualizó Elementor Pro, respiró aliviado, y la shell seguía ejecutándose porque nadie auditó uploads ni revisó usuarios administradores creados en silencio.
Tampoco te salva desactivar el plugin si no revisas lo que ya se subió. Desactivar Super Forms no borra archivos maliciosos. Solo deja de registrar nuevos envíos legítimos, que es lo peor de los dos mundos.
Por qué esto duele más en pymes
Elementor Pro y Super Forms no viven en blogs personales. Viven en webs de servicios, inmobiliarias, clínicas, tiendas WooCommerce con formulario de presupuesto. Sitios donde el dueño no mira logs, donde el mantenimiento es «actualizar cuando WordPress avise» y donde el hosting compartido ejecuta PHP en uploads si la configuración es la de fábrica.
En mi experiencia, tres de cada cuatro pymes con formularios avanzados tienen al menos un campo de subida activo «por si el cliente quiere mandar un currículum o un plano». Nadie recuerda haberlo activado; alguien lo marcó en el editor hace dos años y ahí sigue, convirtiendo una feature de marketing en superficie de ataque.
Los comparadores de plugins te venden estrellas y número de instalaciones. No te venden el ratio de fallos críticos en componentes que procesan input de usuarios anónimos. Y cuando explota, la culpa cae sobre «WordPress» genérico, no sobre la decisión concreta de montar captación con un widget que acepta binarios sin filtrar.
Qué haría yo hoy, en este orden
Primero: versiones. Super Forms ≥ 6.3.314. Elementor Pro ≥ 4.2.2. Si estás en hosting gestionado, no confíes en que lo hayan hecho; entra y compruébalo tú.
Segundo: si no puedes parar para actualizar ahora mismo, desactiva temporalmente los formularios con subida de archivos o el plugin entero en sitios expuestos. Es incómodo, pero menos incómodo que limpiar un RCE.
Tercero: auditoría de wp-content/uploads buscando .php, .phtml, dobles extensiones. Revisa usuarios admin desconocidos, tareas cron raras y cambios recientes en temas hijo.
Cuarto: en el servidor, bloquea la ejecución de PHP dentro de uploads. Nginx, Apache, reglas del WAF… da igual la herramienta; la regla es la misma. Un formulario no debería necesitar que PHP corra en esa carpeta nunca.
Quinto: deja de tratar las actualizaciones de plugins de formularios como mantenimiento cosmético. Son parches de seguridad con la misma urgencia que un certificado SSL caducado. Punto.
Lo irónico es que agosto ya dejó WordPress sangrando por plugins y muchos clientes asumieron que «ya pasó la mala racha». Estas dos vulnerabilidades demuestran lo contrario: la mala racha es el modelo de negocio cuando el 100% del código no lo audita nadie hasta que Patchstack o Wordfence publican el CVE.
WP Engine y otros hosts empiezan a hablar de «AI hosting» y Model Context Protocol para conectar agentes a tus datos. Me parece bien. Pero si tu WordPress clásico sigue permitiendo que un desconocido suba PHP a través de un formulario de contacto, ningún agente de IA te va a salvar; como mucho te ayudará a redactar el email de disculpas a clientes tras el incidente.
Si tienes Elementor Pro con formularios activos y llevas más de 48 horas sin actualizar desde el 19 de agosto, ¿has mirado ya uploads o sigues esperando a que el plugin te ponga la notificación verde?