Vulnerabilidad crítica en ACF Extended: escalada de privilegios sin login y cómo comprobar si te afecta

Advanced Custom Fields: Extended (ACF Extended) es un plugin muy popular que amplía Advanced Custom Fields con más campos y un gestor de formularios. Precisamente esa parte de formularios es la que ha estado en el foco por una vulnerabilidad crítica de Privilege Escalation (escalada de privilegios) que, en determinados escenarios, permite a un atacante sin autenticación asignarse el rol de administrador.

El aviso se ha publicado tras un reporte responsable y ya existe versión corregida. Aun así, merece la pena entender el matiz importante: no todas las instalaciones quedan expuestas por defecto, pero si tienes formularios de creación/actualización de usuario con el campo de rol mapeado, el impacto puede ser total.

Qué se ha descubierto exactamente (CVE-2025-14533)

Según el análisis publicado por Wordfence, el plugin ACF Extended es vulnerable en versiones hasta 0.9.2.1 (incluida) a una escalada de privilegios sin autenticación, catalogada como crítica (CVSS 9.8) y registrada como CVE-2025-14533.

El problema aparece en el flujo de formularios cuando se usa una acción de tipo “Create user” (insert_user) o “Update user” y se permite que un valor de formulario acabe construyendo los argumentos que llegan a wp_insert_user().

Cuándo te afecta de verdad: la condición que lo vuelve explotable

Este punto es clave: la explotación no depende solo de tener el plugin instalado. El escenario crítico ocurre cuando el sitio ha montado un formulario de ACF Extended para alta/gestión de usuarios y, además, ha mapeado el campo role (rol) a un campo del formulario/field group.

Wordfence menciona explícitamente que la vulnerabilidad solo puede explotarse si role está mapeado al custom field. Es decir, si no has expuesto el rol en el formulario (o no lo has mapeado), no estarías en el caso crítico descrito.

Qué falló en el diseño: restricciones en el campo vs. restricciones en el formulario

ACF Extended permite definir un grupo de campos para datos de usuario (email, username, password y también role). Ese campo de rol tiene una opción para restringir roles permitidos (por ejemplo, una configuración tipo “Allow User Role”). Lo esperable es que el formulario aplique esas mismas restricciones.

El problema, según el informe, es que en la versión vulnerable el manejo de la acción insert_user no restringía los roles con los que un usuario podía registrarse, de modo que un atacante podía suministrar un rol elevado (por ejemplo administrator) y el sistema lo aceptaba, incluso aunque la interfaz sugiriese restricciones.

Detalles técnicos a alto nivel (sin perderse en el código)

En la implementación analizada por Wordfence, el módulo que gestiona acciones de formularios construye un array $args recorriendo los valores guardados/mapeados y lo pasa a wp_insert_user($args) cuando la acción es insert_user. La debilidad está en que, en versiones afectadas, no se aplica un control efectivo sobre el valor de role cuando llega desde el formulario.

// Esquema simplificado del flujo descrito por Wordfence
$args = [];

foreach ($save as $user_field => $value) {
    // Se construyen argumentos de usuario a partir de campos mapeados
    if (in_array($user_field, $this->fields) && !acf_is_empty($value)) {
        $args[$user_field] = $value;
    }
}

// Acción: inserción de usuario
$user_id = wp_insert_user($args);

// Si $args['role'] puede ser controlado por el atacante y no se valida,
// el atacante puede intentar establecer 'administrator'.

// Esquema simplificado del flujo descrito por Wordfence
$args = [];

foreach ($save as $user_field => $value) {
    // Se construyen argumentos de usuario a partir de campos mapeados
    if (in_array($user_field, $this->fields) && !acf_is_empty($value)) {
        $args[$user_field] = $value;
    }
}

// Acción: inserción de usuario
$user_id = wp_insert_user($args);

// Si $args['role'] puede ser controlado por el atacante y no se valida,
// el atacante puede intentar establecer 'administrator'.

Versiones afectadas y versión corregida

• Afectadas: ACF Extended <= 0.9.2.1
• Corregida: 0.9.2.2 (parche publicada por el vendor según el aviso)

Mitigación y pasos recomendados para sites en producción

Si administras WordPress en entornos reales (agencias, SaaS, multisite o mantenimiento recurrente), aquí lo pragmático es actuar en dos capas: actualizar y revisar configuración.

1. Actualiza ACF Extended a 0.9.2.2 o superior cuanto antes.
2. Audita tus formularios de ACF Extended: busca acciones tipo Create user / Update user y revisa si hay un campo de rol (role) mapeado.
3. Si el formulario existe por necesidad (por ejemplo, onboarding interno), evita exponer roles; si necesitas asignar roles, hazlo del lado servidor con lógica explícita (whitelist) y nunca desde un input manipulable.
4. Revisa usuarios recientes con rol administrador y su fecha de creación/último acceso, especialmente si tu sitio tenía formularios públicos de registro basados en ACF Extended.
5. Aplica medidas de contención habituales tras un incidente: rotación de contraseñas, revisión de plugins/temas instalados, comprobación de integridad y logs.

Protección con Wordfence: ventana temporal y reglas de firewall

El mismo informe indica que Wordfence desplegó una regla de firewall para bloquear intentos de explotación:

• Usuarios de Wordfence Premium / Care / Response: regla disponible desde el 11 de diciembre de 2025.
• Usuarios de Wordfence Free: la misma protección llegó el 10 de enero de 2026 (30 días después).

Cronología de divulgación (resumen)

• 2025-12-10: recepción del reporte a través del Bug Bounty Program de Wordfence.
• 2025-12-11: validación y confirmación del PoC; envío de detalles al vendor; regla de firewall para usuarios de pago.
• 2025-12-14: el vendor publica la versión parcheada 0.9.2.2.
• 2026-01-10: la regla de firewall llega a usuarios de Wordfence Free.

Qué aprender de este caso (si desarrollas plugins o montas formularios en WordPress)

Aunque aquí hablamos de un plugin concreto, el patrón se repite mucho en WordPress: cuando un formulario termina construyendo objetos sensibles (usuarios, capacidades, roles) hay que aplicar controles en el backend aunque el UI “parezca” restringir opciones.

• Nunca confíes en restricciones de interfaz: valida en servidor con listas blancas (whitelists).
• Si un endpoint o acción crea usuarios, trata role como dato crítico: o lo ignoras, o lo fuerzas a un valor permitido.
• Revisa cualquier integración que termine llamando a funciones core como wp_insert_user() con datos procedentes de usuarios anónimos.

Cierre

La vulnerabilidad CVE-2025-14533 en Advanced Custom Fields: Extended demuestra lo delicado que es exponer flujos de creación/actualización de usuarios desde formularios. Si tienes ACF Extended instalado, la prioridad es actualizar a 0.9.2.2 y comprobar si en tu sitio existe un formulario con acción de usuario y el campo role mapeado. Si esa combinación se da en un formulario accesible públicamente, el riesgo es crítico.