CVE-2026-3426 es una vulnerabilidad de control de acceso en el plugin RTMKit Addons for Elementor para WordPress, publicada el 13 de mayo de 2026, que permite a cualquier usuario con rol Author o superior modificar o resetear configuraciones de widgets a nivel global del sitio, sin validación de permisos. Wordfence la registró bajo el ID interno 632431 con un puntaje CVSS de 4.3.
En 30 segundos
- Plugin afectado: RTMKit Addons for Elementor, versiones 2.0.2 y anteriores
- Falla: las funciones
save_widget()yreset_all_widgets()no verifican si el usuario tiene permisos para ejecutarlas - Quién puede explotarla: cualquier usuario autenticado con rol Author, Editor o Admin
- Impacto: modificación o reseteo de configuraciones de widgets globales del sitio
- Solución: actualizar a la versión 2.0.3 o superior, ya disponible en el repositorio oficial de WordPress
Wordfence es un plugin de seguridad para WordPress desarrollado por Wordfence Inc. que proporciona firewall, detección de malware y escaneo de vulnerabilidades.
¿Qué es CVE-2026-3426? La vulnerabilidad en RTMKit Addons for Elementor
RTMKit Addons for Elementor es un plugin de WordPress que extiende las capacidades del page builder Elementor con widgets adicionales: carruseles, botones, acordeones, tabs y otros elementos visuales que los diseñadores usan para armar páginas sin escribir código. Es el tipo de plugin que usás cuando Elementor solo no alcanza y querés más componentes listos para usar.
El 13 de mayo de 2026, Wordfence publicó en su base de inteligencia de amenazas la vulnerabilidad identificada como CVE-2026-3426. La falla fue encontrada en el plugin desarrollado por RomeTheme y afecta a todas las versiones hasta la 2.0.2 incluida. El parche llegó con la versión 2.0.3, que ya está disponible en el repositorio oficial de wordpress.org.
CVE-2026-3426 es, técnicamente, una vulnerabilidad de autorización inadecuada (Broken Access Control, o IDOR en su variante más conocida). No requiere ninguna interacción del administrador, no explota código JavaScript del navegador, y no depende de errores de configuración del servidor. La falla está en el código PHP del plugin.
Cómo funciona la vulnerabilidad: el problema con los capability checks
En WordPress, cada acción sensible debería verificar si el usuario que la ejecuta tiene el permiso correspondiente. Eso se hace con current_user_can(), la función nativa del core que compara el rol del usuario actual contra la capability requerida. Si un usuario sin permisos intenta ejecutar la acción, WordPress la bloquea.
El plugin RTMKit expone dos funciones que manejan la configuración global de widgets: save_widget() (guarda configuraciones) y reset_all_widgets() (resetea todo a los valores de fábrica). Según el reporte del INCIBE-CERT, ambas funciones están disponibles sin ningún capability check.
Eso significa que cualquier usuario autenticado con suficiente acceso puede llamarlas directamente. Tema relacionado: las mejores herramientas de protección.
¿Cómo se ve esto en la práctica? Si mirás el código fuente del plugin en el repositorio de WordPress (archivo EditorCanvas.php líneas 39 y 44, y WidgetStorage.php líneas 180 y 279), las funciones registran acciones AJAX sin verificar current_user_can() antes de procesar el request. El changeset que arregla esto está documentado en el repositorio oficial bajo la referencia 3474369.
Quién puede explotarla: roles y niveles de acceso
La jerarquía de usuarios en WordPress, de menor a mayor privilegio, es: Subscriber, Contributor, Author, Editor, Administrator. CVE-2026-3426 requiere nivel Author o superior para ser explotada. No es acceso anónimo, o sea que un visitante del sitio no puede hacer nada.
Eso la hace más acotada que muchas vulnerabilidades de alta gravedad, pero no la hace irrelevante.
Ponele que tenés un blog de empresa donde varios empleados publican contenido con rol Author. O un sitio de noticias con redactores externos. O un cliente de agencia al que le diste acceso Author para que suba sus propios artículos. Cualquiera de esas personas, con intención o por accidente, puede llamar a reset_all_widgets() y llevarse puesta la configuración de widgets de todo el sitio.
También entra en juego el escenario de cuenta comprometida: si alguien roba las credenciales de un Author legítimo, tiene vía libre para modificar widgets globales. Ese vector es cada vez más frecuente en 2026, con el auge de los infostealers que roban cookies de sesión de WordPress.
CVSS 4.3: por qué no es crítica pero tampoco la ignorés
El vector CVSS 3.1 asignado es AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N. Esto se conecta con lo que analizamos en cómo detectar si tu sitio fue comprometido.
| Métrica | Valor | Qué significa |
|---|---|---|
| Vector de acceso (AV) | Network | Se explota por red, sin acceso físico |
| Complejidad (AC) | Low | No requiere condiciones especiales |
| Privilegios requeridos (PR) | Low | Solo necesita cuenta autenticada (Author+) |
| Interacción usuario (UI) | None | No necesita que un admin haga click en algo |
| Alcance (S) | Unchanged | La falla no escala a otros sistemas |
| Confidencialidad (C) | None | No expone datos privados |
| Integridad (I) | Low | Puede modificar configuraciones del sitio |
| Disponibilidad (A) | None | No derrumba el sitio |
El puntaje 4.3 la ubica como severidad media-baja. No hay filtración de datos, no hay ejecución de código remoto, y no afecta la disponibilidad del sitio. Eso sí: el impacto de integridad «Low» puede ser engañoso. Un widget modificado que aparece en decenas de páginas del sitio es un problema visible y difícil de rastrear si no tenés logs de auditoría.
Impacto real: qué puede hacer un atacante con esto
Más allá del puntaje, pensá en los escenarios concretos.
Un Author malintencionado puede inyectar HTML en la configuración global de un widget, de modo que ese HTML aparezca en todas las páginas donde ese widget esté usado. Si el widget en cuestión muestra texto, llamadas a la acción, o elementos de UI, la modificación se propaga sola por todo el sitio. Dependiendo de qué tan estrictamente sanitice RTMKit el contenido guardado, eso puede llegar a Stored XSS (aunque ese vector no está confirmado en este CVE específico, es el siguiente nivel de riesgo a evaluar).
reset_all_widgets() es el escenario más agresivo. Un reset global borra configuraciones que el equipo de diseño puede haber tardado días en ajustar. Sin backup reciente, el daño es horas de trabajo perdido.
¿Alguien reportó explotación activa de este CVE en la naturaleza? Todavía no hay evidencia pública documentada al momento de publicar este artículo.
Cómo verificar si tu sitio está afectado
Tres pasos básicos para saber si tenés exposición:
- Verificar si RTMKit está instalado: Dashboard de WordPress, Plugins, buscá «RTMKit» o «RomeTheme for Elementor». El slug del plugin en el repositorio es
rometheme-for-elementor. - Revisar la versión actual: En la lista de plugins, debería mostrarte la versión instalada. Si dice 2.0.2 o anterior, estás expuesto.
- Auditar usuarios con rol Author o superior: Usuarios, lista de usuarios, filtrá por Author y Editor. Si hay cuentas que no reconocés o que ya no deberían tener acceso, es el momento de revisarlas.
Si tenés Wordfence instalado, podés usar el escáner de vulnerabilidades de Wordfence Intelligence para detectar la falla directamente desde el dashboard. Wordfence también tiene reglas de firewall que pueden bloquear intentos de explotación incluso antes de que actualices el plugin. Ya lo cubrimos antes en otras vulnerabilidades críticas de WordPress.
Solución: actualizar a versión 2.0.3 o superior
La corrección está disponible. El parche fue mergeado en el repositorio oficial de WordPress con el changeset 3474369, que agrega los capability checks faltantes en las funciones vulnerables.
El proceso para actualizar:
- Hacé un backup completo del sitio antes de cualquier actualización (WPVivid, UpdraftPlus, o el backup que uses).
- Desde Dashboard > Plugins, buscá RTMKit Addons for Elementor y hacé click en «Actualizar».
- Verificá que la versión instalada sea 2.0.3 o superior una vez completada la actualización.
- Revisá que los widgets sigan renderizando correctamente en el frontend, porque cualquier cambio de estructura de datos puede afectar widgets existentes.
Una práctica que vale la pena activar si no la tenés: las actualizaciones automáticas para plugins. WordPress permite habilitarlas por plugin desde la misma lista. No para todos sirve (los plugins con breaking changes frecuentes son riesgo), pero para plugins de seguridad y complementos de Elementor relativamente estables, es una buena red de contención.
Errores comunes ante este tipo de vulnerabilidades
Subestimar el riesgo porque «requiere login». El error más frecuente. Muchos sitios tienen usuarios Author externos: colaboradores, freelancers, clientes de agencia. Que la falla no sea acceso anónimo no significa que sea imposible de explotar, significa que el vector de ataque es una cuenta comprometida o un insider.
Actualizar sin backup. Las actualizaciones de plugins que modifican estructura de datos de widgets pueden, en casos edge, dejar los widgets existentes con configuraciones incoherentes. Sin backup, no hay rollback posible. Dos minutos de backup previenen horas de troubleshooting.
Asumir que Elementor Pro o el tema protegen contra esto. RTMKit opera a nivel AJAX de WordPress, por debajo de la capa de UI de Elementor. Ningún tema ni el propio Elementor intercepta esas llamadas AJAX del plugin. El fix tiene que estar en RTMKit, y está: es la versión 2.0.3. Lo explicamos a fondo en capas adicionales de protección.
Mejores prácticas para evitar vulnerabilidades similares
CVE-2026-3426 es una más de la categoría Broken Access Control, que según el OWASP Top 10 sigue siendo la vulnerabilidad más frecuente en aplicaciones web. En el ecosistema WordPress 2026, representa una fracción importante de los CVEs reportados en plugins populares.
Lo que podés hacer para reducir la superficie de ataque:
- Principio de mínimo privilegio para usuarios: no le des rol Author a alguien que solo necesita Contributor. Revisá periódicamente qué permisos tienen los usuarios activos.
- Monitoreo de cambios en configuraciones: plugins como Wordfence o WP Activity Log registran modificaciones en opciones del sitio. Si un widget global cambia sin que nadie del equipo de diseño lo tocó, querés saberlo.
- Mantenimiento de plugins activos y auditados: los plugins sin actividad de desarrollo por más de 12 meses son riesgo. RTMKit tiene actualizaciones activas, lo que es una señal positiva.
- Firewall a nivel aplicación: Wordfence (ya mencionado en las instrucciones de instalación de este sitio) puede bloquear explotación de vulnerabilidades conocidas antes del parche. No es sustituto de actualizar, pero es tiempo extra.
Si estás alojando sitios WordPress en un hosting compartido donde no controlás bien el entorno, vale la pena migrar a un entorno con mejor aislamiento. donweb.com tiene planes de WordPress gestionado con actualizaciones automáticas y monitoreo de seguridad incluido, que reducen el tiempo de exposición entre publicación de un CVE y su parche.
En CVE-2026-3426 profundizamos en una vulnerabilidad parecida que afecta los addons de Elementor.
Podés encontrar todos los detalles en nuestro artículo sobre CVE-2026-3426.
Tenemos todo sobre CVE-2026-3426 en otro artículo, con medidas concretas para protegerte.
Preguntas Frecuentes
¿Qué es la vulnerabilidad CVE-2026-3426 en RTMKit?
CVE-2026-3426 es una falla de control de acceso en el plugin RTMKit Addons for Elementor para WordPress, descubierta en mayo de 2026. Las funciones save_widget() y reset_all_widgets() no verifican si el usuario tiene permisos para ejecutarlas, lo que permite a cualquier usuario con rol Author o superior modificar o resetear la configuración global de widgets del sitio sin autorización.
¿Está mi sitio WordPress afectado por esta vulnerabilidad?
Tu sitio está afectado si tenés RTMKit Addons for Elementor instalado en versión 2.0.2 o anterior. Podés verificarlo desde Dashboard > Plugins. Si la versión instalada es 2.0.3 o superior, ya contás con el parche. Si tenés versiones anteriores y hay usuarios con rol Author o Editor, la exposición es activa.
¿Cómo actualizar RTMKit de forma segura?
Primero hacé un backup completo del sitio. Luego, desde el panel de WordPress, actualizá el plugin a la versión 2.0.3 o superior, que ya está disponible en el repositorio oficial de wordpress.org. Después de actualizar, verificá que los widgets del sitio sigan funcionando correctamente en el frontend, especialmente en páginas con widgets globales configurados.
¿Qué son los capability checks en WordPress?
Los capability checks son validaciones que verifican si el usuario actual tiene el permiso (capability) necesario para ejecutar una acción específica. En WordPress, se implementan con current_user_can('nombre_del_permiso'). Si un plugin expone funciones AJAX o REST sin esta verificación, cualquier usuario autenticado puede llamarlas independientemente de su rol, que es exactamente el problema de CVE-2026-3426.
¿Qué impacto tiene esta vulnerabilidad en el SEO o la experiencia del usuario?
Si un atacante modifica widgets globales, el contenido alterado puede aparecer en todas las páginas donde esos widgets están incluidos. Eso puede afectar texto visible, llamadas a la acción, o elementos de navegación en múltiples URLs simultáneamente. Google puede indexar el contenido modificado antes de que lo detectes, lo que genera impacto en SEO y credibilidad del sitio hasta que revertís los cambios.
Conclusión
CVE-2026-3426 no es una vulnerabilidad crítica: no ejecuta código remoto, no filtra datos, y requiere acceso autenticado. Pero un capability check faltante en funciones que afectan la configuración global de widgets es exactamente el tipo de falla que pasa desapercibida hasta que alguien la usa, ya sea con intención o por accidente.
El parche existe, está en la versión 2.0.3, y actualizar toma menos de dos minutos. Si tenés RTMKit instalado en versiones 2.0.2 o anteriores, especialmente en sitios con múltiples autores o colaboradores externos, la actualización es la acción correcta ahora. No hace falta esperar ni evaluar más.
Lo que sí vale revisar después de actualizar es el modelo de permisos de tu sitio: si hay usuarios con rol Author o Editor que ya no están activos, o que no necesitan ese nivel de acceso, es un buen momento para auditarlo. Las vulnerabilidades de access control se explotan casi siempre a través de cuentas existentes, no con magia técnica.