Uma falha no subsistema vhost do kernel Linux, registrada como CVE-2026-74580 e apelidada de Vghost, permite que um usuário local sem privilégios leia e grave a memória do kernel, vire root e, em configurações específicas, escape de uma máquina virtual para o host. O relatório técnico foi publicado pelo Tencent Zhuque Lab em 12 de outubro de 2026, mas a correção já estava no código principal do Linux desde 3 de agosto.
Quem administra hosts de virtualização, servidores com várias contas de usuário ou runners de CI precisa responder a duas perguntas: o kernel em produção já tem o patch? E quem consegue abrir /dev/vhost-net e /dev/vhost-vsock nessa máquina?
Em resumo. A Vghost afeta kernels Linux da versão 4.11 até a 7.2 e transforma acesso local comum em root. Amazon Linux, Oracle Linux e Ubuntu 22.04 já têm pacotes corrigidos, enquanto Ubuntu 24.04 e 26.04 seguiam como vulneráveis, com correção em andamento, na página da Canonical em 17 de outubro. Até atualizar e reiniciar, restrinja o acesso aos dispositivos vhost ou impeça o carregamento do módulo.
Como um cache esquecido virou passe livre para root
O vhost acelera a troca de dados entre o host e as máquinas virtuais que usam dispositivos virtio. Segundo o relatório técnico do Tencent Zhuque Lab, o componente guarda em cache o mapeamento de memória das filas virtuais. Quando uma fila é reconfigurada pelos comandos VHOST_SET_VRING_ADDR ou VHOST_SET_VRING_NUM, esse cache não era zerado, e o kernel seguia traduzindo endereços novos com a autorização antiga, sem checar se eles ainda estavam dentro da área permitida.
O defeito nasceu da combinação de duas mudanças legítimas. A primeira, de fevereiro de 2017, entrou no Linux 4.11 e criou o cache. A segunda, de outubro de 2020 (Linux 5.9), mudou o momento em que os endereços são validados e deixou o atalho do cache sem verificação. Os pesquisadores contam que a ferramenta Corvus AI localizou o problema em cerca de duas horas.
O ponto que mais preocupa é a confiabilidade do ataque. De acordo com o laboratório, o exploit não depende de condição de corrida, de preparação do heap nem de offsets de estruturas internas do kernel. Ele obtém leitura e escrita arbitrárias na memória e contorna o KASLR.
O escape de máquina virtual é um cenário mais restrito: exige o modo device-IOTLB, um dispositivo virtio atrás de um vIOMMU com iommu_platform ativo e um sistema convidado capaz de acionar o reset de fila. Nessa configuração, segundo o relatório, o convidado consegue sobrescrever memória do processo QEMU no host.
Quais kernels e distribuições foram testados
A faixa afetada vai do Linux 4.11 ao 7.2. A correção upstream é o commit de845981da67, que zera o cache sempre que a fila é reconfigurada. As primeiras versões estáveis com o conserto, segundo o Tencent Zhuque Lab, são 5.10.265, 5.15.216, 6.1.183, 6.6.152, 6.12.104, 6.18.45, 7.1.9 e 7.2.
| Distribuição testada | Kernel usado no teste | Resultado relatado |
|---|---|---|
| Ubuntu 26.04 LTS | 7.0.0-28-generic | Usuário do grupo kvm chega a root (dispositivo com permissão 0660 root:kvm) |
| RHEL 9.8 | 5.14.0-687.5.3.el9_8 | Usuário sem privilégio chega a root |
| Amazon Linux 2023 | 6.1.180-225.360.amzn2023 | Usuário sem privilégio chega a root |
| Azure Linux 3.0 | 6.6.150.1-1.azl3 | Usuário sem privilégio chega a root |
| Oracle Linux 10.2 | 6.12.0-204.92.4.2.el10uek | Usuário sem privilégio chega a root |
Os próprios pesquisadores observam que os kernels de Amazon Linux e Azure Linux usados nos testes eram anteriores às correções estáveis. O resultado mostra que a falha existia nessas distros, não que as versões atuais continuem abertas.
Status do patch em cada distro até 17 de outubro
- Amazon Linux: a página da AWS sobre a CVE-2026-74580 marca todos os pacotes listados como corrigidos, com data de 31 de agosto. No Amazon Linux 2023, os avisos são ALAS2023-2026-2107 (kernel), ALAS2023-2026-2110 (kernel6.12) e ALAS2023-2026-2106 (kernel6.18); no Amazon Linux 2, ALAS2-2026-3881. Há pacotes de livepatch para várias versões 6.1, 6.12 e 6.18.
- Oracle Linux: erratas do kernel UEK para Oracle Linux 8, 9 e 10, publicadas em 4 de setembro (ELSA-2026-500248 e ELSA-2026-500249) e em 7 de outubro (ELSA-2026-500374 e ELSA-2026-500377).
- Ubuntu: na página da Canonical sobre a CVE-2026-74580, o 22.04 LTS aparece corrigido no pacote linux 5.15.0-198.208. O 24.04 e o 26.04 constavam como vulneráveis, com trabalho em andamento. O 20.04 e o 18.04 também aparecem vulneráveis no pacote principal; no 20.04, o kernel HWE 5.15 já tem correção via Ubuntu Pro.
- Red Hat: segundo o TecMundo, a empresa classificou o impacto como importante e liberou atualizações para RHEL 8, 9 e 10. A página pública da Red Hat sobre a falha, consultada em 17 de outubro, trazia a nota e uma mitigação, sem listar pacotes. Quem tem assinatura deve conferir os avisos RHSA no Customer Portal.
- Azure Linux: foi testado pelos pesquisadores, mas nem o relatório nem a cobertura de imprensa trouxeram o status da correção. Vale checar diretamente o canal de segurança da Microsoft.
Por que cada empresa dá uma nota diferente para a mesma falha
Quem compara os avisos encontra números que não batem, e isso confunde na hora de priorizar. A diferença está, principalmente, em considerar ou não que o ataque ultrapassa o próprio sistema (o escape para o host) e em quanto dano à integridade cada empresa enxerga.
| Quem avaliou | Nota CVSS 3.1 | Classificação |
|---|---|---|
| CNA do kernel.org (citada pelo Tencent e pela Canonical) | 8,8 | Alta |
| Red Hat | 8,7 | Não exibida na página pública |
| AWS | 7,8 | Importante |
| Oracle | 7,3 (preliminar) | Impacto moderado |
| Canonical | 8,8 | Prioridade média |
Na prática, a nota importa menos que o seu cenário. Uma prioridade média no Ubuntu reflete o fato de que, ali, o dispositivo só é aberto por quem está no grupo kvm. Em distros que deixam o dispositivo com permissão 0666, qualquer conta local serve de porta de entrada.
O que muda para quem roda Linux em servidor, nuvem ou desktop
Host de virtualização ou servidor com várias contas
É o caso mais urgente. Se pessoas, scripts de clientes ou pipelines de CI rodam código com contas comuns na mesma máquina, a Vghost transforma qualquer uma delas em root. Atualize primeiro esses hosts.
Contêineres que recebem dispositivos vhost
O relatório recomenda não entregar /dev/vhost-net ou /dev/vhost-vsock a contêineres não confiáveis. Revise os manifestos e as opções de dispositivo dos seus orquestradores.
Cliente de VPS ou de nuvem
O kernel do host é responsabilidade do provedor. O que está ao seu alcance é atualizar o kernel da sua própria VM, principalmente se ela tem mais de um usuário, e perguntar ao provedor se a infraestrutura já recebeu o patch.
Notebook ou desktop pessoal
O risco é menor, porque o atacante precisaria já executar código na sua máquina. Mesmo assim, a atualização de kernel deve entrar na próxima janela de manutenção.
Como verificar e corrigir, passo a passo
- Descubra a versão do kernel em uso com uname -r e compare com o aviso da sua distribuição.
- Veja quem pode abrir os dispositivos com ls -l /dev/vhost-net /dev/vhost-vsock. Permissão crw-rw-rw- significa que qualquer usuário local consegue usá-los.
- Liste os membros do grupo dono do dispositivo, em geral com getent group kvm, e remova quem não precisa estar ali.
- Atualize o pacote do kernel pelo gerenciador da distro (apt, dnf ou yum).
- Reinicie a máquina. Sem reboot, o kernel antigo continua carregado; no Amazon Linux 2023, verifique se o livepatch cobre a sua versão.
- Rode uname -r de novo para confirmar que o kernel novo subiu.
Mitigação até o patch: retire o acesso de outros usuários com chmod o-rw /dev/vhost-net /dev/vhost-vsock (a mudança se perde no reboot, então use uma regra do udev para mantê-la). Onde não há máquinas virtuais usando vhost, a Red Hat sugere bloquear o módulo criando /etc/modprobe.d/disable-vhost.conf com a linha install vhost /bin/true e descarregá-lo com modprobe -r vhost_net vhost_vsock vhost_scsi vhost. Isso desliga a aceleração de rede, disco e vsock das VMs e pode impedir que algumas iniciem.
Enquanto rodar um kernel vulnerável, trate a participação no grupo kvm como privilégio de administrador, recomendação feita pelos próprios pesquisadores. Para acompanhar o comportamento dos hosts depois da troca de kernel, vale revisar as ferramentas essenciais para monitorar desempenho de servidores.
Dúvidas que estão aparecendo
A Vghost já está sendo usada em ataques?
Até a publicação dos relatórios, não havia registro de exploração em ataques reais, segundo o TecMundo. Os pesquisadores, porém, publicaram um repositório com prova de conceito, o que costuma encurtar o tempo até aparecerem tentativas.
Atualizar o pacote já resolve?
Não sem reiniciar. O pacote novo fica no disco, mas o kernel vulnerável continua na memória até o reboot, a não ser que um livepatch oficial cubra a sua versão.
Se a correção é de agosto, por que o alerta só veio em outubro?
A equipe de CVEs do kernel anunciou o identificador em 21 de agosto, e as notas de gravidade saíram dias depois. O relatório completo, com o exploit verificado em cinco distros, só foi divulgado em 12 de outubro, quando parte das empresas já tinha pacotes prontos.
Desktop com um único usuário corre risco?
Baixo, porque o ataque exige execução local. Um programa malicioso instalado por engano, porém, poderia usar a falha para ganhar root, então a atualização continua recomendada.
Se você usa Ubuntu 24.04 ou 26.04, aplique a mitigação agora
Para quem roda RHEL, Amazon Linux ou Oracle Linux, o caminho é instalar o kernel corrigido e reiniciar na próxima janela possível. No Ubuntu 22.04, o pacote 5.15.0-198.208 já resolve. Já nas versões 24.04 e 26.04, que ainda aguardavam correção, a saída imediata é restringir os dispositivos vhost e acompanhar a página da Canonical até o pacote aparecer.
O Tencent Zhuque Lab informou ainda que deixou duas janelas menores de dados desatualizados no vhost para patches futuros, sem caráter de segurança, então novas mudanças nesse código devem aparecer nos próximos ciclos do kernel. Para organizar a fila de atualizações do mês, o resumo do Patch Tuesday de outubro com 3 zero-days ajuda a decidir o que vem primeiro nos servidores Windows.
