En pocas palabras: aBlocks ≤2.17.0 permite que un Contributor escale a rol Editor explotando el endpoint REST /ablocks/v1/form-builder/registration del Form Builder (CVE-2026-110018, CVSS 8.8). Wordfence lo documentó; afecta 2.000+ instalaciones. La versión 2.18.0 corrige la falla.
Un Contributor de WordPress puede escalar su rol a Editor explotando una falla en el plugin aBlocks ≤2.17.0, según documentó Wordfence. La vulnerabilidad aBlocks WordPress, catalogada como CVE-2026-110018, tiene un CVSS de 8.8.
aBlocks es un plugin de kodezen que combina bloques de Gutenberg, constructor de dashboards de usuario, popups, animaciones y un Form Builder. El fallo vive en el Form Builder: su endpoint REST de registro no valida bien quién puede fijar qué rol, y un Contributor (el nivel más bajo que puede publicar contenido) puede terminar con permisos de Editor. Hay 2.000+ instalaciones activas según WordPress.org.
En este artículo:
- En 30 segundos
- ¿Qué es el plugin aBlocks y para qué se usa en WordPress?
- ¿Cómo funciona la falla de escalación de privilegios CVE-2026-110018?
- ¿Qué rol puede alcanzar un atacante con esta vulnerabilidad?
- ¿Qué versiones de aBlocks están afectadas y cuál es la corregida?
- ¿Por qué esta vulnerabilidad aumenta la urgencia de actualizar?
- ¿Cómo saber si mi WordPress fue afectado y qué hacer para protegerlo?
- Qué está confirmado y qué no
- Errores comunes
- Preguntas Frecuentes
- Conclusión
- Fuentes
En 30 segundos
- CVE-2026-110018 afecta a aBlocks hasta la versión 2.17.0 inclusive, con CVSS 8.8/10 (CWE-269).
- Un Contributor puede escalar a rol Editor explotando el endpoint
/ablocks/v1/form-builder/registration. - El techo de explotación es Editor:
is_safe_registration_role()bloquea roles conmanage_optionsoedit_users, así que no llega a Administrador. - Según West Oakbridge, la versión 2.18.0 sería la corregida, aunque esto no está confirmado en las fuentes primarias.
¿Qué es el plugin aBlocks y para qué se usa en WordPress?
aBlocks es un plugin de WordPress desarrollado por kodezen que agrupa bloques de Gutenberg, constructor de popups, animaciones y un módulo de Form Builder para crear formularios sin código. El componente afectado por la vulnerabilidad es justamente el Form Builder, usado para armar formularios de login y registro de usuarios dentro del sitio.
Si alguna vez armaste un formulario de alta de usuarios con un builder visual, sabés que estos módulos suelen manejar lógica de roles por detrás: qué rol recibe el usuario que se registra, qué validaciones corren antes de guardar el bloque. Ahí es donde aparece el problema.
¿Cómo funciona la falla de escalación de privilegios CVE-2026-110018?
La falla funciona porque el endpoint REST /ablocks/v1/form-builder/registration se registra con permission_callback => __return_true, es decir, sin control de permisos real, y el handler register() toma el valor de roleSlug directo de los atributos del bloque en post_content sin chequear que el bloque sea efectivamente de tipo registro. Cubrimos ese tema en detalle en otra vulnerabilidad crítica detectada en WordPress.
Ahí está el truco: la validación que debería frenar esto, RegistrationFormSanitizer::verify(), solo se aplica al momento de guardar el bloque, según el detalle técnico de Strix.ai. Un atacante con cuenta Contributor guarda un bloque con formType='login' (que no dispara esa validación) pero le mete un roleSlug arbitrario en los atributos. Después, dispara el endpoint de registro con un nonce wp_rest válido y el chequeo de propiedad del post pasa sin problema. El sistema nunca vuelve a preguntar si ese bloque era realmente de tipo registro.
¿Y qué pasa cuando ese request llega al servidor? Exacto: WordPress asigna el rol que pidió el atacante, sin más preguntas.
¿Qué rol puede alcanzar un atacante con esta vulnerabilidad?
Un atacante con cuenta Contributor puede alcanzar el rol de Editor o cualquier otro rol no administrativo, recibiendo además una sesión autenticada en ese nivel mediante WP_User::set_role() y wp_set_auth_cookie(). No hace falta robar credenciales ni esperar aprobación de nadie: el propio endpoint te loguea con el rol nuevo.
Eso sí, hay un límite técnico. La función is_safe_registration_role() rechaza cualquier rol que tenga capacidades como manage_options, edit_users, delete_users, create_users, promote_users o edit_theme_options. En una instalación estándar de WordPress, eso deja a Editor como el techo real de la escalación. Nada de Administrador, al menos no con este vector puntual.
Que el techo sea Editor no significa que sea poca cosa. Con ese rol se puede publicar contenido sin revisión, editar páginas de otros usuarios y, en sitios mal configurados, instalar código vía editor de temas si el hosting lo permite. Esto se conecta con lo que analizamos en la falla que afecta a WordPress desde 2016.
¿Qué versiones de aBlocks están afectadas y cuál es la corregida?
Todas las versiones de aBlocks hasta la 2.17.0 inclusive están afectadas por CVE-2026-110018, según el detalle técnico publicado por Strix.ai. Lo que no está confirmado en esa fuente primaria es el número exacto de la versión corregida.
El sitio West Oakbridge reporta que la 2.18.0 sería la release que soluciona el problema y que al 2026-10-24 es la versión actual en WordPress.org. Tomalo con pinzas hasta que lo verifiques: antes de dar el tema por cerrado, revisá el changelog oficial del plugin dentro de tu propio panel de WordPress.
| Dato | Detalle |
|---|---|
| CVE | CVE-2026-110018 |
| CVSS 3.1 | 8.8/10 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) |
| CWE | CWE-269 (gestión incorrecta de privilegios) |
| Versiones afectadas | hasta 2.17.0 inclusive |
| Versión corregida (reportada, no confirmada en fuente primaria) | 2.18.0 |
| Rol mínimo requerido para atacar | Contributor |
| Rol máximo alcanzable | Editor (no Administrador) |
| Instalaciones activas | 2.000+ (WordPress.org) |
¿Por qué esta vulnerabilidad aumenta la urgencia de actualizar?
El mecanismo de explotación, documentado en detalle técnico, no requiere herramientas sofisticadas: entender la lógica del endpoint y del sanitizador alcanza para replicar el ataque con una cuenta Contributor.
El CVSS 3.1 de 8.8 responde al vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H: atacable sin interacción del usuario, con baja complejidad, requiriendo solo privilegios bajos (Contributor) y con impacto alto en confidencialidad, integridad y disponibilidad. ¿Se está explotando ya en forma masiva? Al 2026-10-24 no hay reportes públicos de explotación activa, pero la combinación de CVSS alto con un vector de ataque de baja complejidad es justo la receta que suele acelerar campañas de scanners automatizados.
¿Cómo saber si mi WordPress fue afectado y qué hacer para protegerlo?
Para saber si tu sitio fue afectado, revisá la sección Usuarios del panel de WordPress buscando cuentas con rol Editor que no debería existir, en particular las que originalmente se crearon como Contributor. Si encontrás una, ahí tenés tu señal de alarma.
- Actualizá aBlocks de inmediato. Verificá en el changelog del plugin si tu versión instalada está por debajo de la release que corrige CVE-2026-110018.
- Auditá roles de usuario. Listá todos los Contributors y Editors del sitio y confirmá que cada uno tenga el nivel que le corresponde.
- Restringí el registro abierto temporalmente. Si tu sitio permite que cualquiera se registre como Contributor, considerá pausarlo hasta confirmar el parche.
- Revisá logs del servidor. Buscá requests hacia
/wp-json/ablocks/v1/form-builder/registrationen los logs de las últimas 4 semanas (desde la divulgación del CVE), sobre todo si vienen de IPs o usuarios que no reconocés.
Un criterio práctico que podés aplicar vos mismo: si administrás varios sitios con WordPress, corré wp plugin list --fields=name,version vía WP-CLI en cada uno y cruzá contra la lista de plugins con CVE publicado en la semana del 20 al 24 de octubre de 2026, no solo aBlocks. El tema de fondo no es un plugin puntual, es la cantidad de superficie de ataque que se acumula cuando no hay rutina de actualización. Para eso, tener hosting con monitoreo activo y actualizaciones gestionadas, como el que ofrece donweb.com, ayuda a que estas ventanas de exposición se cierren más rápido.
Qué está confirmado y qué no
Confirmado por fuentes primarias (Strix.ai): el CVE-2026-110018, su CVSS de 8.8, el mecanismo técnico exacto de la falla (endpoint sin permission_callback real, validación solo al guardar) y el rango de versiones afectadas (hasta 2.17.0). Tema relacionado: el reporte de fallas críticas de junio.
No confirmado en fuentes primarias, reportado por terceros: el número de versión corregida (2.18.0, según West Oakbridge) y la cantidad exacta de instalaciones activas. Verificá ambos datos directamente en la página del plugin en WordPress.org antes de tomar decisiones.
Errores comunes
- Pensar que el ataque requiere acceso de Administrador. No: alcanza con una cuenta Contributor, el nivel más básico que puede crear contenido en WordPress.
- Asumir que actualizar el plugin alcanza sin revisar usuarios existentes. Si el ataque ya ocurrió antes del parche, el usuario sigue teniendo el rol Editor hasta que alguien lo baje manualmente.
- Dejar el registro público abierto «porque nunca pasó nada». Cualquier sitio con registro abierto de Contributors es candidato directo para este vector, sin necesidad de ingeniería social.
- Confundir este CVE con otros de la misma tanda. El 23 y 24 de octubre de 2026 se publicaron 29 CVEs de plugins de WordPress; no mezcles el parche de aBlocks con el de Prime Mover o Speed Optimizer, que son fallas distintas con fixes distintos.
Preguntas Frecuentes
¿Qué es CVE-2026-110018?
CVE-2026-110018 es una vulnerabilidad de escalación de privilegios en el plugin aBlocks para WordPress, con CVSS 8.8/10 y clasificación CWE-269. Permite que un usuario con rol Contributor eleve sus permisos hasta Editor explotando el endpoint REST del Form Builder. Ampliamos el tema en cómo funciona el escaneo interno y externo.
¿Cómo funciona la escalación de privilegios en aBlocks?
Funciona porque el endpoint de registro del Form Builder no valida el tipo de bloque antes de leer el rol solicitado. Un Contributor guarda un bloque marcado como login pero con un rol arbitrario en sus atributos, y dispara el endpoint para que WordPress le asigne ese rol sin más chequeos. Más sobre esto en un caso similar detectado en Next.js.
¿Qué rol puede alcanzar un Contributor explotando esta falla?
El rol máximo alcanzable es Editor. La función is_safe_registration_role() bloquea cualquier rol con capacidades administrativas como manage_options o edit_users, por lo que el acceso a Administrador no es posible mediante este vector específico. Te puede servir nuestra cobertura de los casos recientes de Kirki y Burst Statistics.
¿Qué versión de aBlocks corrige la vulnerabilidad?
Según fuentes secundarias, la versión 2.18.0 sería la que corrige CVE-2026-110018, aunque este dato no aparece confirmado en el registro primario de Strix.ai. Verificá el changelog oficial del plugin en WordPress.org antes de confirmar que tu instalación está protegida.
¿Cómo saber si mi WordPress está hackeado por esta falla?
Revisá la sección Usuarios de tu panel de WordPress buscando cuentas con rol Editor que originalmente eran Contributors o que no reconocés. También conviene revisar los logs del servidor en busca de requests al endpoint /wp-json/ablocks/v1/form-builder/registration.
Conclusión
CVE-2026-110018 es otra muestra de un patrón que se repite en plugins con builders visuales: la validación se aplica en el momento de guardar, pero no en el momento de ejecutar, y esa grieta entre los dos pasos es justo donde se mete el atacante. Con el mecanismo técnico ya documentado públicamente, la ventana para actuar antes de que esto escale es corta.
Si corrés aBlocks en algún sitio, el paso inmediato es claro: actualizá, revisá usuarios con rol Editor que no deberían tenerlo y confirmá el número de versión corregida en el changelog oficial antes de dar el tema por cerrado. No hace falta pánico, pero tampoco demora.