Una vulnerabilidad de gravedad alta afecta a Elementor 4.3.0 y 4.3.1. Si un administrador con la sesión iniciada abre un enlace manipulado, un atacante podría aprovechar sus permisos para crear otra cuenta con acceso total. La versión 4.3.2 corrige el problema.
Más de dos millones de sitios WordPress podrían haber quedado expuestos a una vulnerabilidad detectada en Elementor Website Builder, uno de los complementos de diseño web más utilizados del mundo. El fallo permite que un atacante sin credenciales propias induzca a un usuario autenticado a ejecutar acciones que no había autorizado.
El escenario de mayor impacto se produce cuando quien abre el enlace malicioso es un administrador. En una instalación de WordPress con la configuración habitual, el atacante podría aprovechar esa sesión para crear una segunda cuenta de administrador y obtener el control del sitio.
La empresa de seguridad Patchstack ha documentado el problema, identificado como CVE-2026-62062, y le ha asignado una puntuación de 8,8 sobre 10 en la escala CVSS. La vulnerabilidad afecta únicamente a las versiones 4.3.0 y 4.3.1 de Elementor y quedó corregida con el lanzamiento de la 4.3.2, publicada el 24 de septiembre.
URL sugerida: /elementor-vulnerabilidad-csrf-wordpress-cve-2026-62062
Qué ha ocurrido con Elementor
El fallo es una vulnerabilidad de falsificación de peticiones entre sitios, conocida como cross-site request forgery o CSRF.
Este tipo de ataque busca que una aplicación interprete como legítima una acción que el usuario no ha decidido realizar. Para ello, se aprovecha de una sesión que ya está abierta en el navegador.
En el caso de Elementor, el investigador identificado como Saggre descubrió un problema en un componente incorporado recientemente al editor. Ese error debilitaba una protección de WordPress para determinadas solicitudes y podía afectar no solo a funciones de Elementor, sino también a otras operaciones disponibles en el sitio.
Patchstack recibió el aviso el 22 de septiembre de 2026. Dos días después, Elementor publicó la actualización correctiva. El análisis técnico se hizo público el 25 de septiembre.
Un enlace basta para desencadenar el problema
La particularidad de esta vulnerabilidad es que no requiere que el atacante tenga previamente una cuenta en WordPress.
Según Patchstack, el enlace manipulado puede llegar a la víctima a través de un correo electrónico, un mensaje de chat o un comentario. El riesgo aparece cuando lo abre una persona que mantiene una sesión iniciada en el sitio afectado.
La acción no se ejecuta con permisos inventados por el atacante: utiliza los permisos de la persona que pulsa el enlace. Esa diferencia determina el posible alcance del incidente.
Si el usuario dispone de privilegios limitados, las acciones posibles también estarán restringidas. Si es administrador, el impacto puede ser mucho mayor.
Por ello, la recomendación principal no es confiar únicamente en que el personal identifique enlaces sospechosos, sino actualizar el complemento vulnerable.
Por qué puede acabar con una nueva cuenta de administrador
El error afecta a la forma en que un componente de Elementor comprueba determinadas peticiones dirigidas a la interfaz de programación de WordPress, conocida como API REST.
Esa interfaz permite consultar información y realizar operaciones sobre el sitio. Para las acciones sensibles, WordPress dispone de mecanismos que comprueban la identidad y los permisos del usuario.
El componente vulnerable podía interferir con una de esas comprobaciones. Como consecuencia, una petición provocada desde un enlace podía procesarse utilizando la sesión de la víctima.
Patchstack demostró que, en una instalación habitual, un administrador podía ser inducido a crear otra cuenta con privilegios administrativos.
Una cuenta de ese tipo permitiría al intruso modificar contenido, cambiar configuraciones y gestionar usuarios. Dependiendo de la configuración del sitio, el control obtenido también podría facilitar otras acciones perjudiciales.
El problema alcanza a funciones ajenas a Elementor
La investigación revela un aspecto especialmente importante: el fallo no se limitaba a las funciones del editor visual.
La comprobación defectuosa se aplicaba en una fase previa al procesamiento de las solicitudes. Por ello, podía afectar a operaciones de la API REST del núcleo de WordPress y de otros complementos instalados.
El alcance concreto dependía de las funciones disponibles y de los permisos del usuario cuya sesión se aprovechara.
Esto significa que un complemento destinado al diseño de páginas podía introducir un riesgo para funcionalidades del sitio que, en principio, no tenían relación directa con la edición visual.
La incidencia ilustra por qué la seguridad de WordPress debe evaluarse como un conjunto: una vulnerabilidad en un solo componente puede repercutir en otros.
Más de dos millones de instalaciones potencialmente expuestas
Elementor supera los 10 millones de instalaciones activas en WordPress, pero esa cifra no representa el número de sitios afectados por esta vulnerabilidad.
Según las estadísticas recogidas por Patchstack, las versiones 4.3.0 y 4.3.1 estaban instaladas en más de dos millones de sitios cuando se difundió la alerta.
La diferencia es fundamental.
Las versiones anteriores a la 4.3.0 no incorporaban el componente responsable del fallo y, por tanto, no eran vulnerables a este problema concreto. La versión 4.3.2 ya incluye la corrección.
Tampoco puede deducirse que los más de dos millones de sitios hayan sido atacados o comprometidos. La cifra refleja la exposición potencial, no un recuento de incidentes confirmados.
La actualización 4.3.2 elimina el fallo
Elementor corrigió el problema modificando la manera en que el componente identifica las solicitudes que le corresponden.
La actualización evita que una comprobación demasiado amplia interfiera con las protecciones de otras operaciones de WordPress.
Patchstack recomienda instalar Elementor 4.3.2 o cualquier versión posterior que incluya la corrección.
El registro oficial de cambios de WordPress confirma que la versión 4.3.2 se publicó el 24 de septiembre de 2026 e incorporó mejoras de seguridad en el tratamiento de datos, además de otras correcciones de funcionamiento y compatibilidad.
El problema no exige cambiar de plataforma ni abandonar Elementor: la solución publicada consiste en actualizar el complemento.
Cómo comprobar si una web está afectada
Los administradores pueden verificar la versión instalada desde el panel de WordPress.
En la sección de complementos aparece la versión de Elementor que utiliza el sitio. Si figura la 4.3.0 o la 4.3.1, debe programarse la actualización sin demora.
Antes de actualizar un sitio de producción conviene disponer de una copia de seguridad reciente y, cuando sea posible, comprobar la compatibilidad con otros complementos y con el tema utilizado.
Después de instalar la versión corregida, es recomendable verificar que el editor, los formularios y las funciones esenciales de la web continúan operando con normalidad.
En instalaciones que utilizan Elementor Pro, también conviene revisar la compatibilidad entre las versiones de ambos componentes.
Qué revisar si un administrador pudo abrir un enlace sospechoso
Actualizar cierra la vulnerabilidad conocida, pero no deshace automáticamente una acción que pudiera haberse ejecutado con anterioridad.
Por eso, los responsables de sitios que hayan utilizado las versiones afectadas deberían revisar las cuentas con privilegios administrativos y comprobar que todas corresponden a personas autorizadas.
También resulta aconsejable examinar los registros disponibles en busca de cambios inesperados en usuarios, configuraciones o contenidos.
Si aparecen indicios de acceso no autorizado, será necesario investigar el alcance del incidente, proteger las credenciales y recuperar una configuración fiable.
Estas comprobaciones son medidas preventivas. La publicación de la vulnerabilidad no demuestra, por sí sola, que una web concreta haya sido comprometida.
La formación ayuda, pero no sustituye a los parches
El ataque descrito por Patchstack demuestra que una interacción aparentemente sencilla —abrir un enlace— puede tener consecuencias importantes cuando coincide con una sesión administrativa activa y una aplicación vulnerable.
La formación para reconocer mensajes sospechosos reduce riesgos, pero no es una defensa suficiente frente a todos los ataques CSRF.
En este caso, la prioridad debe ser corregir el fallo de software. Como medidas complementarias, las organizaciones pueden limitar el número de cuentas administradoras, aplicar el principio de mínimo privilegio y mantener un proceso de actualización y revisión de sus complementos.
Patchstack también ha publicado medidas de mitigación para los sitios protegidos por su servicio, aunque estas no sustituyen la instalación de la versión corregida.
Una vulnerabilidad detectada y corregida en pocos días
La secuencia de divulgación fue especialmente rápida.
El investigador Saggre notificó el problema a Patchstack el 22 de septiembre. Elementor publicó la solución el 24 de septiembre y el aviso técnico se hizo público el 25 de septiembre de 2026.
La información consultada no aporta un balance confirmado de ataques reales que hayan aprovechado esta vulnerabilidad. Por tanto, no es posible afirmar que se haya producido una campaña generalizada de toma de control de páginas web.
Lo que sí está demostrado es la posibilidad técnica de aprovechar el fallo en determinadas condiciones y la existencia de una corrección disponible.
Qué significa para empresas, autónomos y tiendas online
El alcance potencial resulta relevante porque Elementor se utiliza en páginas corporativas, medios digitales, negocios de autónomos y comercios electrónicos.
Para esas organizaciones, un acceso administrativo no autorizado puede comprometer la disponibilidad del sitio, su contenido y la confianza de sus visitantes.
El riesgo concreto depende de los permisos obtenidos, las funciones instaladas y las medidas adicionales de seguridad. No todas las webs afectadas presentan necesariamente el mismo escenario.
La conclusión práctica es clara: quienes utilicen Elementor 4.3.0 o 4.3.1 deben actualizar a la versión 4.3.2 o posterior y comprobar que no existan cuentas administrativas desconocidas.
El caso recuerda que una vulnerabilidad en una herramienta de diseño puede convertirse en un problema de seguridad para toda la instalación de WordPress.
