Vghost: a falha de quase nove anos no kernel Linux que expõe servidores e VPS. O que a sua empresa deve fazer

Uma falha no kernel Linux, o núcleo do sistema operativo que corre na grande maioria dos servidores web, permite a um utilizador sem privilégios tornar-se administrador (root) da máquina. Em certas configurações de virtualização, permite também atacar o servidor físico a partir de dentro de uma máquina virtual. Chama-se Vghost, tem o identificador CVE-2026-74580 e esteve no código durante quase nove anos.

A correção já existe, mas só protege depois de o servidor ser atualizado e reiniciado. Se o site, a loja online ou o software de gestão da sua empresa corre num VPS, num servidor dedicado ou num alojamento com Linux, esta notícia diz-lhe respeito.

O que aconteceu

A falha está no vhost, um componente do kernel que acelera a rede e a comunicação entre o servidor e as máquinas virtuais que nele correm. Segundo o anúncio da equipa de CVE do kernel Linux, o vhost guarda em memória (cache) a localização de certas zonas de dados e não limpa essa cache quando a configuração muda. A partir daí, continua a usar a informação antiga e passa a ler e a escrever memória fora da zona que lhe foi autorizada.

O erro entrou na versão 4.11 do kernel, de 2017. Foi descoberto pelo Tencent Zhuque Lab, que publicou a análise técnica a 12 de outubro de 2026. Segundo a equipa, a sua ferramenta de inteligência artificial Corvus AI encontrou o defeito em duas horas. A correção entrou no kernel a 3 de agosto e o CVE foi anunciado a 21 de agosto, mas os pormenores e a forma de explorar a falha só se tornaram públicos em outubro, com o aviso na lista oss-security de 14 de outubro, que inclui um código de demonstração. A equipa do kernel deu-lhe a nota 8,8 em 10 (CVSS 3.1), o que corresponde a gravidade alta.

Porque é grave

Os investigadores demonstraram dois tipos de ataque:

• Escalada de privilégios no servidor: um utilizador local que consiga abrir os dispositivos /dev/vhost-net ou /dev/vhost-vsock passa a ler e a escrever na memória do kernel e, a partir daí, obtém acesso de root. Segundo a Tencent, o ataque é determinístico: não depende de sorte nem de condições de corrida.
• Fuga de uma máquina virtual: em servidores com QEMU/KVM em que o dispositivo virtual está atrás de um IOMMU virtual (vIOMMU) com a opção iommu_platform ativa, um processo dentro da máquina virtual consegue escrever fora da memória que lhe pertence, no processo QEMU do servidor anfitrião, e desviar a sua execução. O mesmo ataque também pode simplesmente derrubar o QEMU e, com ele, a máquina virtual.

A equipa reproduziu a cadeia completa até root em cinco distribuições: Ubuntu 26.04 LTS, RHEL 9.8, Amazon Linux 2023, Azure Linux 3.0 e Oracle Linux 10.2. No Ubuntu, o dispositivo só estava acessível a membros do grupo kvm. Nas outras quatro, qualquer utilizador comum o podia abrir.

A sua empresa está afetada?

A falha é local: ninguém a explora só por visitar o seu site. O atacante precisa primeiro de conseguir correr código no servidor, por exemplo através de um plugin desatualizado, de uma palavra-passe roubada ou de outra falha, como o recente PHP2Shell. É aí que o Vghost se torna perigoso, porque transforma um acesso limitado num controlo total da máquina.

• VPS e servidores dedicados com Linux: são o caso mais direto. Num VPS não gerido, a atualização do kernel é, em regra, responsabilidade sua ou de quem lhe gere o servidor.
• Servidores com máquinas virtuais ou contentores: quem gere servidores com KVM/QEMU, ou contentores a que são entregues os dispositivos /dev/vhost-*, deve tratar esta falha como prioritária.
• Alojamento partilhado: o servidor é gerido pelo fornecedor, mas é partilhado com outros clientes. Se a conta de um deles for comprometida, uma falha destas pode servir para chegar a root e, daí, aos sites de todos. A correção cabe ao fornecedor; a si cabe perguntar.
• Cloud: o servidor físico e a camada de virtualização são responsabilidade do fornecedor, mas o sistema operativo da sua instância continua a ser seu.

Como verificar a versão do kernel

No servidor, por SSH, corra uname -r. Segundo a equipa do kernel, as primeiras versões corrigidas em cada série são a 5.10.265, a 5.15.216, a 6.1.183, a 6.6.152, a 6.12.104, a 6.18.45, a 7.1.9 e a 7.2. As distribuições costumam aplicar a correção sem mudar o número de base, por isso um número mais baixo pode já estar corrigido. O mais seguro é confirmar no aviso da sua distribuição:

• Debian: segundo o registo de segurança do Debian, a falha está corrigida no Debian 13 (trixie) a partir do pacote 6.12.105-1 e no Debian 12 (bookworm) a partir do 6.1.187-1.
• Ubuntu: a página da Canonical, atualizada a 22 de outubro, dá o Ubuntu 22.04 LTS como corrigido no kernel 5.15.0-198.208. No 24.04 LTS e no 26.04 LTS a correção ainda estava em preparação, e o 20.04 LTS aparecia como vulnerável.
• Red Hat: a Red Hat acompanha a falha e, como medida provisória, indica desativar o módulo vhost nos sistemas que não precisam dele.
• Amazon Linux e Oracle Linux: ambos já publicaram kernels corrigidos (aviso da Amazon e ELSA-2026-500248 da Oracle). A SUSE também publicou atualizações, segundo a base de dados OSV.

O que fazer esta semana

1. Atualize o kernel e reinicie. Em Debian e Ubuntu, corra sudo apt update && sudo apt full-upgrade. Em RHEL, AlmaLinux, Rocky Linux ou Oracle Linux, corra sudo dnf update kernel. Depois, sudo reboot. Sem reiniciar, o servidor continua a usar o kernel antigo. No fim, volte a correr uname -r para confirmar.
2. Restrinja o acesso aos dispositivos vhost enquanto não puder atualizar. Veja as permissões com ls -l /dev/vhost-*. Os dispositivos /dev/vhost-net, /dev/vhost-vsock, /dev/vhost-scsi e /dev/vhost-vdpa-* não devem estar abertos a todos os utilizadores nem ser entregues a contentores em que não confia. Os investigadores avisam que mudar as permissões não fecha os acessos já abertos nem trava o ataque a partir de uma máquina virtual.
3. Trate o grupo kvm como privilegiado. Com um kernel vulnerável, quem pertence a esse grupo pode chegar a root.
4. Se não usa virtualização no servidor, siga a sugestão da Red Hat e impeça o carregamento do módulo vhost.
5. Se o servidor aloja máquinas virtuais de terceiros, não exponha dispositivos vhost com iommu_platform atrás de um vIOMMU a máquinas em que não confia até ter o kernel corrigido.

O que perguntar ao seu fornecedor de alojamento

• Os servidores onde está o meu site já têm o kernel corrigido para a CVE-2026-74580 e já foram reiniciados?
• No alojamento partilhado, como estão isoladas as contas dos vários clientes?
• No meu VPS, quem trata das atualizações do kernel e com que frequência?
• Os servidores físicos onde corre o meu VPS já estão corrigidos?

Guarde as respostas por escrito. Se a sua empresa estiver abrangida pela NIS2, ou trabalhar para clientes que estejam, é este o tipo de prova que lhe vão pedir.

Uma lição que se repete

O Vghost junta-se a uma série de falhas graves encontradas com a ajuda de inteligência artificial neste outono, como contámos no artigo sobre o outubro negro na segurança. Os defeitos antigos estão a ser descobertos mais depressa, e os servidores que não são atualizados com regularidade ficam expostos durante mais tempo. Além das atualizações, convém ter cópias de segurança testadas e saber o que fazer se o site for pirateado.

Quer saber se o seu servidor está protegido?

A MarcaWeb trata da cibersegurança de sites, lojas online e servidores: atualizações, monitorização e cópias de segurança, com resposta rápida quando sai uma falha destas. Comece pela auditoria gratuita ou fale connosco: escreva para info@marcaweb.pt ou ligue para o +351 920 260 897.

Fontes: anúncio da equipa de CVE do kernel Linux (21-08-2026), Tencent Zhuque Lab (12-10-2026), oss-security (14-10-2026), Debian, Ubuntu, Red Hat, Amazon Linux e Oracle Linux. Consultadas a 26-10-2026.