Están entrando en webs de WordPress por un fallo de Elementor Pro
Desde el 19 de agosto de 2026 hay una campaña automatizada contra el maquetador con el que está montada buena parte de las webs de las pymes españolas. Si su web tiene un formulario con adjuntos y Elementor Pro en la 4.2.1 o anterior, alguien ha podido dejar un fichero dentro de su servidor. El arreglo lleva semanas publicado.
Si la web de su empresa va con WordPress, esto le lleva diez minutos y conviene hacerlo hoy, no el lunes.
El 19 de agosto de 2026 se publicaron los detalles de un fallo crítico en Elementor Pro, el maquetador con el que está hecha buena parte de las webs de las pymes españolas. Los ataques empezaron ese mismo día. Es un fallo de los que se aprovechan solos, sin usuario ni contraseña, y lo que consigue quien lo explota es dejar un fichero suyo dentro de su servidor y ejecutarlo cuando le apetezca.
Hay parche, y lleva semanas disponible. Eso es justo lo que hace que esto merezca un aviso.
Qué falla
El fallo es el CVE-2026-32475, publicado por Patchstack el 19 de agosto de 2026 con una puntuación de 9 sobre 10.
Está en los formularios. Cuando usted pone en su web un formulario de Elementor Pro con un campo para adjuntar ficheros, el clásico «mándenos su currículum» o «adjunte el plano y le pasamos presupuesto», el plugin comprueba mal lo que le llega. El atacante manda dos ficheros en vez de uno: el primero vacío y el segundo un fichero PHP. La validación se rinde después del primero, y el PHP acaba guardado en /wp-content/uploads/elementor/forms/. Desde ahí basta con llamarlo por el navegador para que se ejecute en su servidor.
Para ser vulnerable tienen que darse dos cosas a la vez. Una, tener Elementor Pro en la versión 4.2.1 o anterior. Dos, tener publicado un formulario con al menos un campo de adjuntar fichero. La segunda condición es bastante más común de lo que parece.
Por qué no espera al lunes
Wordfence vende un cortafuegos para WordPress, así que ve lo que llega a decenas de miles de sitios a la vez. Bloqueó cerca de 190.000 intentos contra sus clientes en los primeros días, según recogió BleepingComputer el 3 de septiembre de 2026. Al día siguiente, The Hacker News elevaba la cuenta a más de 440.000 intentos, sumando otro plugin de formularios con un problema parecido, Super Forms.
Esas cifras no quieren decir que alguien tenga algo contra su empresa. Quieren decir lo contrario, que es peor: son escaneos automáticos recorriendo dominios y probando uno detrás de otro. A un programa que va por internet en orden le da exactamente igual que usted sea una clínica dental de Dos Hermanas con doscientas visitas al mes.
El detalle que explica por qué nadie actualizó
La versión que corrige el fallo es la 4.2.2, y salió el 6 de agosto de 2026. Trece días antes de que el problema se hiciera público.
Si mira el changelog de Elementor, la entrada de esa versión habla de un arreglo en la barra superior del editor para idiomas distintos del inglés. Del agujero de los formularios, ni una línea. Nadie tenía motivo para correr, porque nada decía que hubiera que correr. El 19 de agosto se publicaron los detalles, las webs sin actualizar seguían igual de abiertas, y los escáneres ya sabían dónde mirar.
La versión más reciente mientras escribimos esto es la 4.2.4, del 31 de agosto de 2026.
Qué se lleva quien entra
Lo que le interesa al que entra es el servidor, más que su web en sí.
Con un fichero PHP ejecutándose dentro se puede colgar una página de phishing bancario de su dominio, y su dominio tiene años y buena reputación, cosa que uno recién comprado no tiene. Se puede mandar correo masivo desde su servidor hasta que acabe en las listas negras, y ese día sus facturas dejan de llegarle a sus clientes. Se puede cambiar un número de cuenta en su página de contacto. Y en un alojamiento compartido, que es lo que tiene casi toda pyme, se puede intentar saltar a las demás webs del mismo servidor.
Hay una parte más incómoda. Por esos formularios le ha llegado a usted gente mandando currículums, copias del DNI, cuestionarios de salud si es una clínica. Son datos personales de terceros. Si alguien se los ha llevado, eso es una brecha de seguridad, con la obligación de notificarla a la Agencia Española de Protección de Datos dentro de las 72 horas siguientes a tener constancia de ella.
Qué hacer, y en este orden
- Entre en el panel de WordPress, vaya a Plugins y mire la versión de Elementor Pro. Si pone 4.2.1 o menos, ha estado expuesto.
- Haga copia de seguridad y actualice. A la 4.2.2 como mínimo, y ya puestos a la 4.2.4.
- Actualice o no, entre en
/wp-content/uploads/elementor/forms/con el gestor de ficheros del alojamiento o por FTP. Ahí no debería haber ni un solo fichero acabado en.php. Si lo hay, dese por comprometido. - Si aparece algo, borrarlo no cierra nada. Cambie las contraseñas de todos los administradores de WordPress, la de la base de datos y la del panel del alojamiento, renueve las claves de sesión del
wp-config.phpy revise si hay usuarios administradores que usted no creó. - Si por esos formularios pasaban datos personales y hay indicios de que entraron, empiece a contar las 72 horas desde ya.
- Si leyendo los puntos anteriores ha pensado «yo esto no sé quién me lo lleva», ahí está el arreglo de fondo, y no es un arreglo técnico.
La misma conversación de siempre
Es lo mismo que contábamos sobre el router de la oficina. Un sistema que funciona, que nadie mira, y que un día aparece en un boletín. Con el agravante de que la web de una pyme suele ser el activo más expuesto que tiene, porque es el único que está en internet las veinticuatro horas por definición, y aun así es del que menos se acuerda nadie.
Si no hay nadie pendiente de su WordPress, active al menos las actualizaciones automáticas de plugins. No es la solución buena, porque un día una actualización romperá algo y no habrá quien lo vea, pero es bastante mejor que dos años sin tocar nada.
Por dónde empezar aunque no contrate nada
Los puntos 1 y 3 de la lista son gratis y valen por sí solos. En diez minutos sabe si tiene un problema o si puede irse tranquilo.
Si prefiere que lo lleve alguien, esto es exactamente gestión de activos y vulnerabilidades: tener apuntado lo que hay y enterarse el día que sale el aviso, no trece días después. Y si al abrir la carpeta le aparece un .php que no esperaba, no borre nada y avísenos. Eso ya es respuesta a incidentes, y lo primero es mirar los registros del servidor mientras todavía están.


