Falha crítica no ACF Extended permite escalada de privilégios: o que verificar e como mitigar já

Quem usa o Advanced Custom Fields: Extended (ACF Extended), um addon para o ACF que inclui form manager (gestor de formulários) e outras funcionalidades, precisa de olhar para isto com prioridade. Foi reportada uma vulnerabilidade crítica de escalada de privilégios que, em determinadas configurações, permite a um atacante não autenticado criar/atualizar um utilizador com o papel (role) de administrator.

A boa notícia é que existe correção e o cenário de exploração depende de uma configuração relativamente específica. A má notícia é que, quando a condição está presente, o impacto é total: com uma conta admin, o atacante passa a conseguir instalar plugins/temas, carregar ficheiros maliciosos e alterar conteúdo do site.

Resumo técnico (para decidir rápido se estás em risco)

Plugin afetado: Advanced Custom Fields: Extended (slug acf-extended)
Versões vulneráveis: até 0.9.2.1 (inclusive)
Versão corrigida: 0.9.2.2
CVE: CVE-2025-14533
Severidade: CVSS 9.8 (Critical)
Tipo de falha: escalada de privilégios sem autenticação via ação de formulário de utilizador (Insert User Form Action)

Condição importante para exploração

Segundo a análise publicada, a exploração só é viável quando o campo role (papel do utilizador) está mapeado num formulário de criação/atualização de utilizador do ACF Extended. Se não tens formulários desses, o risco prático reduz bastante — mas atualizar continua a ser o caminho certo.

O que está a acontecer, na prática

A funcionalidade de formulários do ACF Extended permite criar formulários no front-end para ações como “criar utilizador” ou “atualizar utilizador”. Para isso, o site pode ter um field group com campos típicos de registo (email, username, password) e, opcionalmente, um campo para o papel (role).

O problema identificado é que, nas versões vulneráveis, a ação de criação de utilizador não restringe de forma eficaz quais os roles permitidos quando o role é enviado pelo formulário. Na prática, um atacante pode submeter administrator como role e ganhar acesso administrativo — mesmo que, no field group, exista uma opção tipo “Allow User Role” que sugeriria haver limitação.

Porque é que isto é tão grave num site WordPress

Escalada de privilégios para administrador é uma das classes de vulnerabilidade mais destrutivas em WordPress. A partir do momento em que existe uma conta admin controlada por terceiros, o atacante pode:

Instalar plugins/temas (incluindo ZIPs maliciosos com backdoors)
Editar ficheiros e configurações do site
Modificar páginas/posts para injetar spam, links ou redirecionamentos
Criar utilizadores adicionais e manter persistência
Alterar integrações e chaves (dependendo do que está exposto no admin)

Como confirmar se o teu site tem a configuração de risco

O ponto crítico aqui não é “usar ACF Extended” em abstrato — é usar ACF Extended com formulários de utilizador e mapear um campo de role.

No WordPress, confirma se o plugin Advanced Custom Fields: Extended está instalado e qual a versão (idealmente, atualiza já para 0.9.2.2 ou superior).
Revisa os formulários criados via o módulo de formulários do ACF Extended e procura ações do tipo Create user (insert_user) ou Update user.
Dentro desses formulários, verifica se existe um campo mapeado para role (papel). Se existir, considera o site potencialmente explorável nas versões vulneráveis.
Mesmo que o teu field group tenha restrições como “Allow User Role”, não assumes que isso te protege nas versões afetadas — esse é precisamente o desfasamento descrito na análise.

Sinal clássico de comprometimento

Se encontras um utilizador administrador criado recentemente sem explicação (ou alterações inesperadas em roles), trata como incidente de segurança: muda credenciais, revoga sessões, valida integridade do site e procura persistência (novos admins, plugins/temas desconhecidos, ficheiros alterados).

Mitigação: o que fazer agora (ordem recomendada)

Atualiza o ACF Extended para 0.9.2.2 (ou versão mais recente disponível). Esta é a correção direta indicada no advisory.
Se tens formulários de criação/atualização de utilizador: remove temporariamente o mapeamento do campo role ou desativa o formulário até confirmar o patch e o comportamento esperado.
Audita utilizadores administradores: valida lista de admins, datas de criação e atividade recente.
Garante que tens uma camada de firewall/aplicação. Segundo a Wordfence, utilizadores Premium/Care/Response receberam regra de firewall a 11/12/2025 e a versão Free recebeu a mesma proteção a 10/01/2026 (o que não substitui a atualização do plugin).

Um detalhe que interessa a quem desenvolve: onde a falha acontece

Na análise técnica publicada, o fluxo descrito passa por uma função insert_user() (num módulo de ação de formulário para utilizadores) que constrói um array $args a partir de campos submetidos e chama wp_insert_user($args). O ponto crítico é a ausência de uma validação/restrição robusta do role permitido quando o formulário aceita esse campo.

Isto é um lembrete útil para qualquer implementação de registo via front-end: nunca confiar em valores enviados pelo cliente para controlo de privilégios, mesmo quando a UI “parece” restringir opções. A restrição tem de existir no servidor.

Cronologia (para contexto de resposta)

10/12/2025: submissão da falha via Bug Bounty Program da Wordfence
11/12/2025: validação e confirmação do proof of concept; envio de detalhes ao vendor via portal; regra de firewall para Wordfence Premium/Care/Response
14/12/2025: patch lançado (versão 0.9.2.2)
10/01/2026: regra de firewall disponibilizada para Wordfence Free

Checklist final (o mínimo a fazer hoje)

Atualizar Advanced Custom Fields: Extended para 0.9.2.2 ou superior
Confirmar se existe formulário de Create user/Update user com role mapeado
Se existir: desativar/remover role do formulário até validar comportamento pós-update
Auditar utilizadores admin e atividade recente