EasyApache 4 v25.81 corrige CVEs do OpenSSL 1.1.1 no cPanel CentOS 7

cPanel & WHM Risco Médio

EasyApache 4 v25.81 corrige CVEs do OpenSSL 1.1.1 no cPanel CentOS 7

O EasyApache 4 v25.81 atualiza ea-openssl11 para 1.1.1w-9 no CentOS 7 com ELS e corrige CVE-2026-63072 e CVE-2026-54874, relacionadas a corrupção de memória e negação de serviço.

Revisado em 10/09/2026 Leitura técnica
CVE-2026-63072CVE-2026-54874
SeveridadeMédio
Versões afetadascPanel em CentOS 7 com ea-openssl11 anterior a 1.1.1w-9 e cobertura TuxCare ELS
Versões corrigidasea-openssl11-1.1.1w-9 ou posterior pelo EasyApache 4 v25.81
Status WebinHostPacote corretivo disponível no repositório EasyApache 4

O EasyApache 4 v25.81 trouxe ao CentOS 7 os backports ELS para duas falhas do OpenSSL 1.1.1: CVE-2026-63072, estouro de buffer no processamento CMS, e CVE-2026-54874, consumo excessivo de memória em DTLS. Para o pacote ea-openssl11, o build corrigido pelo cPanel é 1.1.1w-9.

O que aconteceu

Na CVE-2026-63072, um objeto CMS malformado pode provocar uma escrita de oito bytes fora do heap durante o desembrulhamento de chave. O efeito mais provável é encerramento do processo, embora corrupção de memória exija atenção. Na CVE-2026-54874, mensagens DTLS de época futura podem ser acumuladas e causar amplificação significativa de memória por conexão, abrindo uma rota de negação de serviço.

O número base 1.1.1w permanece no pacote do cPanel porque a correção foi retroportada. Portanto, procurar somente por “1.1.1zi” — versão upstream que contém as correções — produz falso positivo. Em CentOS 7, deve-se comparar o release RPM completo 1.1.1w-9 e confirmar a origem EasyApache/TuxCare.

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
ea-openssl11 no CentOS 7 ELSanterior a 1.1.1w-91.1.1w-9+
OpenSSL upstream 1.1.1anterior a 1.1.1zi1.1.1zi+
Outras linhas cPanel suportadasavaliar pacote próprio do sistemainstalar advisory da distribuição

A primeira falha exige que uma aplicação processe conteúdo CMS não confiável no caminho afetado. A segunda exige DTLS alcançável e mensagens preparadas. Um servidor web TLS comum pode não expor esses fluxos diretamente, mas extensões, agentes, VPNs e aplicações vinculadas à biblioteca devem ser inventariados.

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

Médio. O OpenSSL classifica a CVE-2026-63072 como Moderate e a CVE-2026-54874 como Low. O cenário predominante é indisponibilidade do processo, não extração automática de chave. Em infraestrutura compartilhada, reinícios repetidos e pressão de memória ainda podem afetar vários sites.

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

Consulte o RPM fornecido pelo EasyApache e identifique processos que mantêm a biblioteca antiga aberta. Não substitua o binário do sistema por uma compilação manual, pois isso rompe dependências e o ciclo de atualização do painel.

rpm -q ea-openssl11
rpm -qi ea-openssl11 | grep -E '^(Name|Version|Release|From repo)'
/usr/local/cpanel/scripts/check_cpanel_rpms --list-only
lsof 2>/dev/null | grep -E 'libssl|libcrypto' | head -40

No escopo publicado pelo cPanel, release inferior a 1.1.1w-9 está pendente. Um RPM corrigido pode coexistir temporariamente com processos que carregaram a biblioteca anterior; reinicie os serviços afetados de forma controlada ou programe reboot quando a lista não puder ser determinada com segurança.

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 os pacotes EasyApache/cPanel pelos repositórios oficiais e valide o release. O CentOS 7 está fora do suporte padrão; a correção pressupõe cobertura ELS. Planeje migração para AlmaLinux ou CloudLinux suportado, pois ELS reduz risco imediato, mas não devolve suporte integral ao sistema legado.

yum clean all
/usr/local/cpanel/scripts/update-packages
yum update ea-openssl11
rpm -q ea-openssl11

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

Reinicie de modo controlado os processos que carregam libssl/libcrypto e teste HTTPS, painel, e-mail e integrações. Acompanhe OOM, crashes e mensagens CMS/DTLS anormais. Confirme que nenhum repositório de terceiro fez downgrade e registre a cobertura ELS do host.

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

A WebinHost aplica o release EasyApache corrigido, identifica serviços com bibliotecas antigas em memória e valida sites e painel após restart. Também recomenda e executa, quando contratada, a migração de CentOS 7 para uma plataforma suportada. Imunify360 e firewall reduzem tráfego hostil; KernelCare cuida do kernel, não substitui o pacote OpenSSL de user space.

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.