CVE-2026-68490 no CalDAV/CardDAV do cPanel expõe contatos e calendários entre contas

cPanel & WHM Risco Alto

CVE-2026-68490 no CalDAV/CardDAV do cPanel expõe contatos e calendários entre contas

Uma falha de permissões no CalDAV/CardDAV permite que usuário local leia contatos e eventos de outras contas cPanel. A atualização corrige novos armazenamentos e repara permissões existentes.

Revisado em 22/09/2026 Leitura técnica
CVE-2026-68490
SeveridadeAlto
Versões afetadascPanel/WHM v120 ou posterior antes dos builds 11.134.0.57, 11.136.0.41, 11.138.0.8 e WP2 11.138.1.11 aplicáveis à respectiva linha
Versões corrigidas11.134.0.57+, 11.136.0.41+, 11.138.0.8+ ou WP2 11.138.1.11+; o update também repara permissões existentes
Status WebinHostCorreção e reparo de permissões disponíveis

A CVE-2026-68490 é uma falha de permissões no armazenamento CalDAV/CardDAV do cPanel. Um usuário local do mesmo servidor pode ler eventos de calendário e contatos pertencentes a outras contas. O cPanel esclarece que a vulnerabilidade não permite modificar esses dados e não concede root, mas expõe informações privadas entre clientes.

O que aconteceu

Calendários podem conter compromissos, links de reunião, participantes, horários e descrições internas; catálogos CardDAV armazenam nomes, e-mails, telefones e outras informações pessoais. Permissões incorretas em dados criados ou mantidos pelo serviço permitiam que um usuário local ultrapassasse o isolamento esperado e lesse registros de outro titular.

A atualização tem duas funções importantes: corrige as permissões usadas na criação de novos armazenamentos de calendário e endereços e repara as permissões das contas já existentes. Por isso, apenas alterar uma configuração para futuros usuários ou reinstalar um cliente DAV não resolve os dados antigos. O fornecedor não divulga caminhos nem técnica de acesso; não execute buscas invasivas em diretórios de clientes para testar.

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
cPanel/WHM v120 a v133afetado; ramo legado sem build mínimo listadomigrar para linha suportada e corrigida
cPanel/WHM 11.134anterior a 11.134.0.5711.134.0.57+
cPanel/WHM 11.136anterior a 11.136.0.4111.136.0.41+
cPanel/WHM 11.138anterior a 11.138.0.811.138.0.8+
cPanel WP2 11.138.1anterior a 11.138.1.1111.138.1.11+

O atacante precisa ser usuário local no mesmo host. Em hospedagem, isso inclui contas com shell permitido e pode incluir processos de aplicações comprometidas conforme as permissões efetivas. O impacto permanece leitura, não alteração nem root, dentro do escopo divulgado. Desativar novos calendários não repara automaticamente armazenamentos existentes.

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

Alto em hospedagem multi-tenant, sem CVSS público confirmado. O impacto é de confidencialidade entre clientes e pode envolver dados pessoais e comerciais. O boletim exclui modificação e escalação root, portanto esta CVE não deve ser confundida com a CVE-2026-87899. A prioridade aumenta em hosts com muitas contas, shell, revendedores ou calendários corporativos.

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

Confirme o build completo e a conclusão do upcp. Faça inventário do serviço e dos diretórios DAV sem ler conteúdo de clientes. Não aplique chmod -R ou chown -R genérico: permissões improvisadas podem quebrar sincronização ou ampliar ainda mais o acesso. O atualizador é responsável pelo reparo suportado.

/usr/local/cpanel/cpanel -V
/usr/local/cpanel/bin/whmapi1 servicestatus service=cpdavd 2>/dev/null
find /home -xdev -maxdepth 5 -type d \( -iname '*caldav*' -o -iname '*carddav*' \) -printf '%m %u:%g %p\n' 2>/dev/null | head -100
find /usr/local/cpanel/logs -maxdepth 1 -iname '*dav*' -ls 2>/dev/null

Build abaixo do mínimo da linha está vulnerável. A listagem de permissões é somente inventário e não deve ser publicada em chamados sem proteção. Diretório aparentemente restritivo isolado não prova correção, pois ACLs, grupos, arquivos internos e a lógica do serviço também influenciam o acesso.

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 o cPanel pelo fluxo oficial até o build mínimo ou posterior. O boletim informa que essa atualização corrige permissões futuras e repara dados existentes, portanto não substitua o procedimento por comandos manuais. Em ramo v120–v133, migre para uma linha suportada. Restrição temporária de shell pode reduzir exposição, mas não constitui correção garantida.

/usr/local/cpanel/scripts/upcp --force
/usr/local/cpanel/cpanel -V
/usr/local/cpanel/scripts/check_cpanel_rpms --fix
/usr/local/cpanel/scripts/restartsrv_cpdavd --check 2>/dev/null

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 sincronização CalDAV/CardDAV, criação e edição autorizada de contatos e eventos, webmail e autenticação. Confirme que clientes legítimos continuam acessando somente seus próprios dados. Revise logs de acesso local, comandos, processos e cópias recentes de arquivos DAV. Se houver evidência de leitura indevida, preserve logs, identifique titulares afetados e siga o plano de resposta e privacidade aplicável.

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 planos gerenciados, a WebinHost atualiza o cPanel, deixa o reparo de permissões ser executado pelo mecanismo suportado e valida sincronização sem expor conteúdo de clientes. CloudLinux/CageFS reduz acesso entre contas e Imunify360 ajuda contra o comprometimento inicial; como o advisory confirma uma falha própria de permissões, somente essas camadas não bastam sem o build corrigido.

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.