Entre 31 de agosto e 1º de setembro de 2026, administradores relataram em fóruns da Proxmox que servidores PVE 7 — instalações com mais de 4 anos, atualizadas até o EOL, com apenas o usuário root — foram criptografados e mantidos para resgate. A Proxmox publicou o aviso PSA-2026-00043-1 no dia 1º de setembro. Não veio de teste interno: veio de relatos independentes de vítimas.
A escala ficou clara no relatório de incidente da Netfront: entre 22h58 de 1º de setembro e o fim do dia seguinte, pelo menos 33 endereços externos distintos obtiveram shell root num cluster de 22 nós. Cinco desses endereços alcançaram todos os 22 nós. Os atacantes instalaram um rootkit eBPF que escondia processos e arquivos de ls, ps, top, strace e gdb, mineravam Monero via XMRig, e executavam comandos dentro das VMs dos clientes através do qemu-guest-agent. A Netfront reconstruiu a plataforma e a devolveu ao serviço em 7 de setembro; naquela noite, foi reinvadida por credenciais que sobreviveram à rebuild. A auditoria completa levou até 9 de setembro.
A CrowdSec registrou 133 endereços IP únicos enviando tentativas de exploração a partir de 4 de setembro de 2026, com 1.210 sinais em três dias. A Halcyon identificou uma variante Linux do ransomware Pay2Key — ligada a atores iranianos — construída especificamente para destruir ambientes Proxmox: desliga VMs, deleta backups (burlando as proteções internas do Proxmox) e criptografa o que resta. O ransomware Onyx também foi associado a ataques contra Proxmox, com discos QCOW2 criptografados in-place e renomeados para .onyx.
A causa: CVE-2023-54391
A vulnerabilidade é um bypass de autenticação pré-autenticação no pacote libpve-access-control. O endpoint de login POST /api2/json/access/ticket tem um parâmetro tfa-challenge usado no fluxo de dois fatores. Em versões vulneráveis, a mera presença desse parâmetro — qualquer valor, mesmo tfa-challenge=1 — faz o servidor pular a verificação de senha. Para uma conta sem 2FA, o servidor emite um ticket válido completo, incluindo para root@pam, que é o root do host.
POST /api2/json/access/ticket HTTP/1.1
Host: <pve-host>:8006
username=root@pam&password=x&tfa-challenge=1
Uma única requisição. Sem credenciais. Sem interação. Um ticket de root completo.
A CVSS é 9.8 (v3.1) / 9.3 (v4.0). O CVE-2023-54391 foi registrado no NVD em 1º de setembro de 2026.
A anomalia: corrigido em 2023, descoberto em 2026
O bug foi corrigido em julho de 2023 na libpve-access-control 8.0.4, como parte de uma refatoração de rotina do fluxo de TFA. O changelog descreve a mudança como "bug fix funcional", não como correção de segurança. O código vulnerável era tratado como bug de lógica, não como falha de autenticação. Não houve CVE, não houve advisory, não houve backport para o ramo PVE 7.
Só em 2026, quando as vítimas começaram a aparecer, a história mudou. Nathan Golez, um dos relatores independentes, reconstruiu a causa raiz a partir da correção e publicou a análise. A Proxmox então publicou o PSA-2026-00043-1 e o CVE. A janela de exposição foi de três anos e meio: do fix em julho de 2023 ao disclosure em setembro de 2026.
Quem foi afetado
| Versão | Status |
|---|---|
| Proxmox VE 7.0 – 7.4 | Afetado. EOL desde julho de 2024. Sem patch de segurança. |
| Proxmox VE 8.0 (inicial) | Afetado, brevemente, antes do fix em 8.0.4. |
| Proxmox VE 8.0.4+ e 9.x | Não afetado. |
A chave é o pacote libpve-access-control: versões 7.0-7 até (não incluindo) 8.0.4 estão expostas. Quem está em 8.0.4 ou superior já tem a correção desde julho de 2023.
O que os atacantes faziam
Com root@pam, o atacante tem acesso total ao hypervisor: todas as VMs, todos os containers, todos os discos, e via /etc/pve o filesystem de cluster compartilhado entre nós. A Netfront documentou:
- Rootkit eBPF: escondia processos/arquivos de ferramentas de sistema, bloqueava
kill,ptrace, interceptavaopenat/read/getdentspara fabricar saídas falsas, e reescrevia endereços de Monero em trânsito. - XMRig: minerador de Monero disfarçado de
/root/supervisor. - Acesso a VMs de clientes: via
qemu-guest-agent, o root do host executa comandos dentro de qualquer VM que tenha o agente instalado, sem necessidade de credencial de guest. - Anti-forense:
chattrremovido, timestamps alterados, wrappers detopepsfiltrando a própria presença. - Persistência: tokens de API criados (39 de um único endereço na Netfront), crontabs,
/etc/rc.local.
O que poderia ter evitado
Não expor a porta 8006 para a internet. O
pveproxyescuta em0.0.0.0:8006por padrão. O bypass é pré-autenticação: basta chegar no endpoint. Um firewall entre a internet e a porta 8006 elimina o vetor. A Netfront tinha a porta exposta porque os clientes usavam para gerenciar as próprias VMs — uma escolha de design que se tornou um risco.Ativar 2FA nos usuários administrativos. O bypass é especificamente para contas sem segundo fator. Uma conta com 2FA configurada toma o caminho de validação de challenge que funciona. A Proxmox VE 7 suporta TOTP e WebAuthn nativamente. Na prática, a maioria dos ambientes não ativa 2FA no
root@pam, o que torna essa mitigação ineficaz para o caso mais comum.Não rodar software EOL. O PVE 7 atingiu fim de vida em julho de 2024. Sem patch de segurança, sem backport. A lição central do incidente: o bug era de 2023, mas só virou problema em 2026 porque instalações continuaram rodando um ramo que já não recebia atualizações.
Firewall e segmentação de rede. Isolar a interface de gerenciamento em uma VLAN dedicada, com acesso via VPN ou proxy reverso, impede que um escaneador genérico encontre o endpoint.
Backups imutáveis e fora do alcance do host. A Netfront tinha backups "pull" — o sistema de backup buscava as cópias, o host não tinha credencial de destino nem caminho de escrita. Três zonas em prédios diferentes. Mesmo com comprometimento total de uma zona, duas cópias intactas existiam fora do alcance. Isso é o que impede a destruição de backups (o que o Pay2Key faz).
Monitorar logs de acesso. O
pveproxyregistra todas as requisições em/var/log/pveproxy/access.log. QualquerPOST /api2/json/access/ticketde um endereço que não é o seu padrão administrativo é um alerta. A Netfront só tinha logs de 26 de agosto em diante — o suficiente para ver que não havia atividade direcionada antes do aviso, mas a rotação de logs padrão de três anos é insuficiente.Verificar e manter atualizado o pacote
libpve-access-control.dpkg-query -W -f '${Version}\n' libpve-access-control— abaixo de 8.0.4, está exposto.
Quem usava versões vulneráveis
- Netfront: cluster de 22 nós em PVE 7.4, porta 8006 exposta, comprometido em 1–2 de setembro.
- Administradores no fórum da Proxmox: PVE 7 com 4+ anos, atualizado até o EOL, apenas usuário
root, criptografado em 29–30 de agosto. - Vítimas de Onyx Ransomware: discos QCOW2 criptografados in-place, chaves X25519 em
/root/WORK_SELF_PUBLIC.pem. - Vítimas de Pay2Key Linux: VMs desligadas, backups deletados, dados criptografados.
- 133 endereços IP observados pela CrowdSec tentando exploração ativa desde 4 de setembro.
- 34.219 instâncias Proxmox VE identificadas por fingerprint na internet (ZoomEye), contra 4,043,230 hosts escutando na porta 8006 (a maioria não é Proxmox).
A lição
O incidente Proxmox de setembro de 2026 não é uma história de bug desconhecido. É uma história de três anos de exposição silenciosa em software que ninguém mais atualizava. O fix existia desde julho de 2023. O CVE foi emitido em setembro de 2026. As vítimas não foram atingidas por uma falha que a Proxmox não sabia — foram atingidas por uma falha que a Proxmox sabia, corrigiu, e que as instalações EOL nunca receberam.
A defesa é simples e barata: não rode EOL, não exponha 8006 na internet, ative 2FA, e faça backup imutável fora do alcance do host. O incidente mostrou que quando essas quatro coisas faltam, um único request HTTP basta.
Fontes e referências
Encontrou uma informação que precisa de correção? Fale com a redação.