CVE-2026-78006 e CVE-2026-78159 no The Events Calendar: duas cadeias críticas de RCE

WordPress Risco Crítico

CVE-2026-78006 e CVE-2026-78159 no The Events Calendar: duas cadeias críticas de RCE

The Events Calendar possui duas cadeias de RCE sem autenticação por comentários e widgets. Versões até 6.17.4 são afetadas; a versão 6.17.4.1 corrige integralmente as falhas.

Revisado em 14/09/2026 Leitura técnica
CVE-2026-78006CVE-2026-78159
SeveridadeCrítico
Versões afetadasThe Events Calendar até 6.17.4 na cadeia de object injection e até 6.17.3 na cadeia de callable, quando comentários estão habilitados e visíveis em eventos
Versões corrigidasThe Events Calendar 6.17.4.1 ou superior recomendado para corrigir integralmente as duas cadeias
Status WebinHostDuas cadeias críticas sem login; atualização imediata necessária

O plugin The Events Calendar, usado em mais de 600 mil sites, recebeu correção para duas cadeias independentes de execução remota: CVE-2026-78006 e CVE-2026-78159. Um visitante sem conta pode inserir bloco malicioso em comentário de evento pendente e acionar a exploração pela própria pré-visualização, sem aprovação do moderador. A versão segura recomendada é 6.17.4.1 ou posterior.

O que aconteceu

O template V2 do plugin captura toda a página de evento, incluindo comentários, e passa o resultado para do_blocks(). Isso expande incorretamente o parser Gutenberg a conteúdo anônimo. Delimitadores de bloco sobrevivem à sanitização de comentários, e a URL com moderation-hash permite ao autor visualizar o comentário ainda pendente e disparar o processamento.

Na CVE-2026-78006, uma verificação insegura de dados serializados pode executar métodos mágicos durante o primeiro unserialize(); um gadget interno termina em chamada de comando do sistema. Na CVE-2026-78159, um array evita a proteção contra objetos, injeta o mapa classes e alcança uma chamada PHP arbitrária. A cadeia demonstrada redefine a senha do usuário ID 1, entra como administrador e envia plugin malicioso.

Uma classificação de vulnerabilidade descreve o pior cenário plausível, não confirma que cada servidor tenha sido explorado. A análise correta separa quatro perguntas: o componente existe, a versão está no intervalo afetado, as pré-condições estão presentes e houve evidência de abuso. Essa distinção evita tanto falsa tranquilidade quanto interrupções desnecessárias.

Versões e ambientes afetados e corrigidos

Produto ou linhaAfetado / expostoCorrigido / protegido
The Events Calendar até 6.17.3afetado pelas duas cadeias quando comentários de evento estão ativos6.17.4.1+ recomendado
The Events Calendar 6.17.4ainda afetado pela CVE-2026-780066.17.4.1+
The Events Calendar 6.17.3.1patch intermediário, não usar como estado final6.17.4.1+
The Events Calendar 6.17.4.1 ou superiorcorrigido integralmente segundo o advisorymanter atualização ativa

A exploração publicada exige comentários habilitados nos posts tribe_events e a opção do plugin para mostrar comentários nas páginas de evento. Não precisa de aprovação, pois o próprio autor recebe uma prévia do comentário pendente. Desabilitar comentários bloqueia a rota conhecida, mas não substitui a atualização do pipeline vulnerável.

Em pacotes de distribuição, o número upstream nem sempre muda quando o mantenedor aplica um backport. Por isso, a comparação deve considerar o release completo do pacote, o advisory do fornecedor e, quando aplicável, o estado do livepatch. Apenas comparar o primeiro número exibido pelo software pode produzir falso positivo.

Nível de risco e impacto

Crítico — CVSS 3.1 9,8 em ambas. As duas cadeias são remotas, de baixa complexidade, sem privilégio e sem interação administrativa. Uma oferece comando de sistema direto; a outra toma uma conta administrativa e chega a RCE por plugin. O impacto inclui dados, ingressos, clientes, pagamentos, reputação e disponibilidade do site.

Em hospedagem, uma conta local ou um site comprometido não deve ser tratado como ator confiável. Código obtido por plugin desatualizado, credencial roubada ou upload malicioso pode satisfazer a condição “acesso local” e transformar uma falha de kernel ou painel em comprometimento de outras contas. Quando o efeito inclui root, escape, execução de PHP ou tomada de administrador, considere também bancos, chaves, tokens, e-mail e backups conectados.

Como verificar se o servidor ou site está vulnerável

Confira versão, opções de comentários e comentários pendentes em eventos. Procure marcação wp:legacy-widget e parâmetros de pré-visualização nos logs, sem abrir URLs ou desserializar o conteúdo suspeito. Revise também o usuário ID 1 e administradores recentes.

wp plugin get the-events-calendar --fields=name,status,version,update,update_version
wp option get default_comment_status
wp comment list --status=hold --post_type=tribe_events --fields=comment_ID,comment_post_ID,comment_author,comment_date
wp db query "SELECT comment_ID, comment_post_ID FROM wp_comments WHERE comment_content LIKE '%wp:legacy-widget%';"
wp user get 1 --fields=ID,user_login,user_email,user_registered

Versão até 6.17.4 com comentários de evento ativos é exposta à cadeia aplicável. Nenhum comentário encontrado agora não exclui exploração anterior, pois o atacante pode apagar rastros após obter RCE. Mudança inesperada no hash de senha não é visível pelo WP-CLI; correlacione logins, sessões, e-mail e horário de atualização do usuário.

Faça somente inventário defensivo. Não execute prova de conceito em produção. Um exploit pode derrubar o host, alterar dados, apagar vestígios ou atingir outros clientes. Se o resultado for ambíguo, preserve as saídas e compare-as com o boletim do fornecedor.

Como corrigir ou mitigar

Atualize diretamente para 6.17.4.1 ou superior. Como contenção imediata, desative comentários nas páginas de evento e modere/bloqueie novas submissões, depois limpe caches. Evite parar na versão 6.17.3.1 ou 6.17.4: são estados intermediários e não representam a correção integral recomendada no alerta.

wp db export backup-pre-events-calendar-rce.sql
wp plugin update the-events-calendar
wp plugin get the-events-calendar --field=version
wp cache flush
wp core verify-checksums

Antes da mudança, confirme backup restaurável, acesso alternativo, espaço em disco e integridade dos repositórios. Depois, valide o serviço e a aplicação em vez de considerar o comando concluído como prova suficiente. Mitigações reduzem exposição durante a janela de manutenção, mas devem ser documentadas e removidas ou reavaliadas após o patch definitivo.

Validação posterior e resposta a incidentes

Teste calendário, eventos individuais, comentários, widgets, tickets, REST API e cache. Examine comentários pendentes/excluídos, URLs com unapproved e moderation-hash, alterações do usuário ID 1, novos administradores, plugins, mu-plugins, cron e PHP recente. Havendo indicador, isole, preserve logs e troque credenciais e salts antes de restaurar.

Atualizar impede novas explorações pela falha conhecida, mas não remove persistência criada antes do patch. Se houver usuário inesperado, arquivo alterado, webshell, cron desconhecido, chave SSH nova, processo anormal ou acesso administrativo sem explicação, isole o ativo, preserve logs e acione resposta a incidentes. Faça rotação de segredos a partir de um equipamento confiável e só restaure o serviço depois de entender o alcance.

Medidas adotadas pela WebinHost

Nos ambientes WordPress gerenciados, a WebinHost aplica a versão integralmente corrigida, audita comentários/blocos suspeitos e contas administrativas e testa calendário e integrações. Imunify360 acrescenta WAF, defesa proativa e detecção de malware, e CageFS limita o processo PHP à conta. Essas camadas reduzem exploração e movimento lateral, mas não substituem The Events Calendar 6.17.4.1+.

Nos serviços em que o gerenciamento da camada de servidor faz parte do contrato, o fluxo da WebinHost inclui acompanhamento dos canais de segurança dos fornecedores, inventário do componente, avaliação de exposição, aplicação controlada da correção disponível e validação posterior. Quando o kernel e a distribuição são compatíveis, o KernelCare reduz a janela de exposição ao aplicar live patches sem aguardar uma reinicialização; quando a correção exige um novo kernel ou o fornecedor não oferece live patch, a equipe planeja a atualização e o reboot conforme o risco e a janela operacional.

O Imunify360 complementa essa resposta com firewall de aplicação, detecção de malware, defesa proativa e inteligência de reputação nos planos elegíveis. Essas camadas ajudam a bloquear ou detectar tentativas, mas não substituem a correção do pacote vulnerável. CloudLinux e CageFS também aumentam o isolamento entre contas, sem transformar uma versão desatualizada em versão segura.

Escopo dos planos gerenciados: a WebinHost prioriza falhas críticas e altas na infraestrutura administrada. Sites, temas, plugins, código e credenciais do cliente continuam exigindo atualização e revisão pelo responsável da aplicação, salvo contratação específica. O status deve ser confirmado por servidor; possuir KernelCare ou Imunify360 não é, isoladamente, prova de que todo CVE foi corrigido.

Tutoriais, downloads e serviços relacionados

Use estes materiais para continuar a verificação com segurança:

Referências oficiais e técnicas

Nota técnica: distribuições Linux e painéis frequentemente aplicam backports. O número exibido por um pacote pode ser diferente da versão upstream e ainda conter a correção. Compare sempre o pacote com o advisory da distribuição ou do painel. Não execute prova de conceito em produção; os comandos deste boletim são de inventário e verificação.

Precisa validar seu ambiente?

Conte com gerenciamento técnico de servidores

A atualização de aplicações do cliente e a administração do servidor têm escopos diferentes. Fale com a equipe para avaliar o ambiente e o plano adequado.