A OVSwrap (CVE-2026-64531) é uma falha aritmética no módulo de kernel Open vSwitch. A soma do tamanho de ações aninhadas pode dar a volta no limite inteiro, provocar escrita fora dos limites e permitir que usuário local não privilegiado obtenha root. Há prova de conceito pública e o CloudLinux disponibilizou livepatches para linhas afetadas.
O que aconteceu
Open vSwitch implementa switching virtual em kernel e user space. Ao validar uma sequência especialmente construída de ações de rede aninhadas, o cálculo de comprimento podia sofrer integer wrap. O verificador então aceitava uma área menor do que a realmente processada, abrindo corrupção de memória controlável.
A falha importa principalmente em hypervisors, plataformas de virtualização, redes SDN e hosts onde o módulo está instalado ou pode ser carregado. A nomenclatura “usuário local” inclui processos dentro de serviços e containers que consigam alcançar as interfaces necessárias. Um servidor sem Open vSwitch não apresenta essa rota.
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 linha | Afetado / exposto | Corrigido / protegido |
|---|---|---|
| CloudLinux 9 | kernels el9_7+ vulneráveis com módulo disponível | KernelCare main feed ou kernel vendor corrigido |
| CloudLinux 10 | kernels el10_1+ vulneráveis com módulo disponível | KernelCare main feed ou kernel vendor corrigido |
| CloudLinux for Ubuntu 22.04 | antes de 5.15.0-190.200 | 5.15.0-190.200+ ou KernelCare |
| Linhas el9_6/el10_0 anteriores | código indicado como não afetado no advisory | manter atualização normal |
Ver o pacote user space openvswitch não é a única verificação: a vulnerabilidade está no módulo openvswitch.ko. Mesmo descarregado, autoload permitido pode tornar o caminho alcançável. Em hosts que dependem de OVS, bloquear o módulo interrompe rede virtual e não deve ser feito sem plano.
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 — CVSS 3.1 7,8. A cadeia exige acesso local, mas termina em root e há exploit funcional. Em host multi-tenant, uma aplicação já comprometida pode usar a falha para ultrapassar a conta. Em hypervisor, perda da rede virtual durante uma mitigação mal planejada também é um risco operacional relevante.
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 versão do kernel, arquivo do módulo, estado carregado, dependentes e cobertura KernelCare. Faça inventário das bridges antes de qualquer bloqueio.
uname -r
modinfo openvswitch 2>/dev/null | head -15
lsmod | grep '^openvswitch'
ovs-vsctl show 2>/dev/null
kcarectl --patch-info 2>/dev/null | grep CVE-2026-64531Kernel afetado mais módulo disponível e sem patch confirmado exige ação. O módulo não aparecer no lsmod reduz atividade naquele momento, mas não impede autoload. Saída de ovs-vsctl com bridges mostra dependência operacional e contraindica descarregamento improvisado.
Como corrigir ou mitigar
Aplique o livepatch KernelCare e confirme a CVE ou instale o kernel corrigido da linha. Em máquina que não utiliza Open vSwitch, uma mitigação é definir install openvswitch /bin/false em modprobe.d e então avaliar descarregamento/reboot. Em host com bridges OVS, mantenha rede estável e priorize patch.
dnf update 'kernel*'
kcarectl --update
kcarectl --patch-info | grep CVE-2026-64531
printf 'install openvswitch /bin/false
' | tee /etc/modprobe.d/ovswrap.confAntes 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
Valide kernel/livepatch, bridges, VLANs, containers e conectividade entre guests. Revise logs de kernel para oops, falhas de validação e processos anormais. Procure módulos persistentes, alterações de rede, credenciais e arquivos privilegiados. Remova a mitigação somente após confirmar correção e necessidade do OVS.
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 servidores gerenciados, a WebinHost identifica dependência real do Open vSwitch antes de qualquer bloqueio, aplica KernelCare quando coberto e programa kernel/reboot quando necessário. Monitoramento detecta perda de rede, enquanto Imunify360 e isolamento reduzem o acesso inicial por sites; a validação por CVE no livepatch continua obrigatória.
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.
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.
Assistente IA WGS