Proxmox sob ataque: zeroday real, hype de mercado ou negligência técnica?

Ontem, enquanto eu recuperava um node Proxmox com mon.andromeda fora do quorum e osd.0 crashando em loop, meu celular não parava de vibrar. O grupo Proxmox VE Brasil estava em polvorosa: servidores sendo criptografados, ransomware em massa, e o alerta circulando como se fosse o fim do mundo para quem roda Proxmox.

A pergunta que ficou: é realmente um 0day ou é a velha história de servidor mal gerenciado com IP público?

O dia em que o grupo explodiu

Era 31 de agosto. Eu estava com dois terminais abertos — um SSH no veil, outro no andromeda — tentando entender por que o mon.andromeda havia abandonado o quorum do cluster Ceph há uma semana inteira sem que ninguém percebesse. Binário corrompido, monDB inacessível, osd.0 em loop de segfault, dmesg cheio de segfaults em pvedaemon e pveproxy — o tipo de manhã que você não deseja nem para o seu concorrente.

No meio da sessão de debug, o celular não parava de vibrar.

O grupo de virtualização havia entrado em polvorosa. O Tácio Andrade — referência respeitada da comunidade brasileira de Proxmox — havia postado um alerta direto no grupo de Facebook: servidores sendo criptografados, ransomware em massa, casos confirmados em PVE 7, 8.0.3, 8.2 e 8.4.

Meu primeiro pensamento foi o clássico: “lá vem aquela história de servidor com IP público e sem firewall”. Mas resolvi ler com atenção antes de julgar.

Bem que fiz.

O que de fato aconteceu — a investigação que a comunidade fez em tempo real

A thread aberta no fórum oficial do Proxmox em 31 de agosto começou como mais um relato de servidor comprometido. Terminou como uma investigação forense colaborativa em tempo real, com mais de 90 respostas em menos de 24 horas — e conclusões técnicas que mudaram completamente a leitura inicial do caso.

O relato inicial

Um usuário identificado como pve7bug descreveu uma instalação de PVE 7 com mais de quatro anos de uso, atualizada até o fim do suporte (EOL), apenas o usuário root com senha de 30+ caracteres gerada aleatoriamente. Criptografada. Todos os logs apagados pelos atacantes. Ele encontrou relatos similares em fóruns chineses do dia anterior — padrão de onda coordenada, não ataque oportunista isolado.

A thread explodiu. A comunidade se dividiu: parte culpava negligência pura, parte sentia que havia algo maior acontecendo. O debate foi intenso — e produtivo.

A virada: análise forense na página 4

Foi na página 4 da thread que o cenário mudou completamente.

Um membro identificado como Znuff confirmou três instâncias de PVE 7.4.20 comprometidas e documentou o comportamento do atacante com um nível de detalhe que raramente se vê em relatos públicos:

• Payload instalado em /var/lib/systemd/PVE-1 — um cryptominer XMR conectado a gulf.moneroocean.stream:20004, com wallet Monero rastreável
• Logs de sistema redirecionados para /dev/null: auth.log, btmp, lastlog, wtmp — todos apagados de forma cirúrgica
• Journals do systemd limpos
• Arquivo dpkg/status destruído intencionalmente — quebra o apt e dificulta qualquer tentativa de remediação via pacotes
• Biblioteca libhide.so instalada para ocultar processos, portas e arquivos do sistema operacional — evasão sofisticada

O detalhe mais revelador de tudo: o atacante abriu um root shell diretamente via a função “Shell” da interface web do Proxmox — sem autenticação prévia visível em nenhum log. Apenas as portas 22 e 8006 estavam expostas na internet. Não havia rastro de brute force, não havia tentativa de login registrada — ele simplesmente entrou.

“This is 100% an auth bypass on 8006. I confirmed this by timestamps — all files found were created after the Shell function was used.” — Znuff, fórum Proxmox (página 4)

A vulnerabilidade identificada — e o CVE que ninguém sabia que existia

Na sequência, outro membro cruzou os dados e localizou a causa raiz:

“Found it. It is a complete compromise of the web interface. No pre-requisites, just a vulnerable proxmox version. There was a bug patched in pve-access-control (potentially by accident) in 2023. I will submit it to MITRE so a CVE can be issued.”

O componente afetado: libpve-access-control em versões anteriores à 8.0.4. Um auth bypass na interface web — corrigido em 2023, provavelmente sem que a equipe do Proxmox soubesse exatamente o que estava corrigindo. O CVE foi formalmente registrado como PSA-2026-00041-1.

O mecanismo é desconcertantemente simples: o atacante forja um ticket de login via requisição POST direto na API da porta 8006. A senha é completamente ignorada. Com o ticket forjado em mãos, ele acessa o ambiente como root e a partir daí tem controle total — VMs, containers, backups, shell do host.

Para verificar se um sistema está afetado:

V=$(dpkg-query -W -f='${Version}' libpve-access-control 2>/dev/null)
echo "libpve-access-control: ${V:-not installed}"
dpkg --compare-versions "$V" lt 8.0.4 \
  && echo ">>> AFETADO" \
  || echo ">>> não afetado"

Correção:

• PVE 8.x: apt update && apt upgrade — libpve-access-control >= 8.0.4 já cobre. Após atualizar, reinicie o pveproxy para garantir que a nova lib seja carregada: systemctl restart pveproxy
• PVE 7.x: não há correção disponível (EOL). Ação imediata e sem negociação: remover a porta 8006 da internet.

Mitigação imediata — antes mesmo de atualizar:

Esse bypass específico não funciona se o usuário root tiver 2FA configurado. É a mitigação mais rápida disponível enquanto a atualização não é aplicada:

Proxmox UI → Datacenter → Permissions → Two Factor → Add TOTP for root

Importante: 2FA não substitui atualização e não substitui tirar a porta da internet. É um band-aid de emergência, não uma solução definitiva.

A sequência documentada do ataque

Uma vez dentro, o atacante seguia um roteiro sistemático — não era ataque manual, era automação:

1. Encontra a porta 8006 exposta
2. Forja ticket de login via POST na API (senha ignorada)
3. Obtém shell root via interface web
4. Desliga as defesas do SO Linux subjacente
5. Apaga o próprio rastro — logs, histórico, ponto de entrada

Não era um ataque direcionado a uma empresa específica. Era um ataque direcionado a um tipo de plataforma — o atacante sabia exatamente onde estavam os diretórios, quais processos matar, quais logs apagar. Automação desenvolvida com conhecimento profundo do Proxmox.

Dois grupos, um exploit, objetivos diferentes

A investigação confirmou que o mesmo vetor estava sendo explorado por grupos distintos com objetivos opostos:

• Grupo ransomware: criptografia de arquivos, extensão .decrypt, contato [email protected] — sem solução pública de decriptação até o momento
• Grupo cryptominer: instalação silenciosa de XMR miner com libhide.so para evasão máxima, sem destruir dados — minerando Monero em cima da infraestrutura alheia, silenciosamente

Mesma porta. Mesmo exploit. Um quer seu dinheiro, o outro quer sua CPU.

Então era um zeroday — ou não?

Sim e não. E a nuance importa mais do que o rótulo.

A vulnerabilidade em libpve-access-control é real e foi confirmada por análise técnica independente. Mas ela foi corrigida em 2023, por acidente, sem CVE atribuído, sem que a maioria dos administradores soubesse que estava protegida. Qualquer instalação de PVE 8 atualizada estava imune há mais de dois anos sem saber por quê.

O que não muda a equação: PVE 7 estava em EOL. Sem suporte, sem patches, sem saída que não fosse migrar ou desexpor. E a exposição direta da porta 8006 era o pré-requisito inegociável para o exploit funcionar.

Chamar de “0day” sem esse contexto é impreciso. Chamar de “só negligência do usuário” também é — porque havia uma falha real. A verdade está no meio: uma vulnerabilidade legítima, explorável apenas em condições de má configuração que nunca deveriam existir.

PVE 9 atualizado: sem evidência de comprometimento nessa onda.

O padrão brasileiro — e o que os relatos revelaram

Nos grupos técnicos brasileiros, os casos confirmados seguiam um padrão perturbadoramente familiar para quem trabalha com MSP:

• Proxmox desatualizado — versão 7 ou 8, EOL ou sem updates há meses
• Porta 8006 e/ou SSH expostos diretamente na internet, sem nenhuma camada de proteção
• Sem VPN, sem proxy reverso, sem firewall decente na borda — em muitos casos apenas o modem da operadora fazendo as vezes de “firewall”
• PBS desligado, ou presente mas sem imutabilidade de backup configurada

Um dos casos mais graves: um provedor de internet que havia desligado o PBS dias antes do ataque por pressão operacional. Quando o servidor foi comprometido, não havia ponto de recuperação ativo. O backup existia no papel — na prática, não estava lá quando precisou.

Outro caso tinha uma camada de complexidade ainda maior: o provedor vinha sofrendo pressão de grupos criminosos para não fornecer internet sem identificação compulsória dos usuários. O ataque digital foi mais um instrumento de coerção num cenário de extorsão que já era físico antes de ser técnico. A infraestrutura de TI virou refém de um conflito que começou na rua.

Esses não são casos extremos. São o dia a dia de quem presta suporte a pequenos provedores, PMEs e empresas que enxergam infraestrutura como custo — não como ativo.

Aí o mercado entrou em campo

No mesmo dia, fornecedores de software que utilizam Proxmox como base começaram a disparar comunicados preventivos aos seus clientes. O tom geral:

“Diante de alertas recentes relacionados à segurança de ambientes Proxmox VE, recomendamos uma revisão preventiva dos ambientes On-Premises que utilizam essa plataforma.”

O conteúdo era correto: verificar versão, restringir acesso, aplicar updates, validar backups. Boas práticas que deveriam ser rotina, não reação a incidente.

O problema não estava no conteúdo — estava no timing e no tom implícito de urgência que o comunicado carregava, surfando numa onda de pânico antes que a análise técnica estivesse completa. O efeito prático: administradores sem contexto técnico suficiente receberam um alerta de “0day em Proxmox” sem entender exatamente o que fazer ou por que fazer.

A resposta que eu vi de equipes bem gerenciadas foi o oposto do pânico. Um exemplo real, de um ambiente MSP que conheço bem:

“As recomendações apresentadas já fazem parte das práticas de segurança que adotamos. O acesso às interfaces de gerenciamento é restrito à rede interna/administrativa, não havendo exposição direta dessas interfaces à internet. Os acessos externos são realizados por meio de proxy, sem exposição direta da interface real de gerenciamento ao usuário. Existe apenas um cluster ainda na versão 8.4, destinado ao ambiente de armazenamento SATA, que não possui acesso externo liberado. Aplicamos política de senhas em todos os acessos — erro 3x bloqueia a conta, único usuário local é o root, e a senha é restrita.”

Esse é o estado que qualquer ambiente Proxmox gerenciado profissionalmente deveria estar — com ou sem comunicado de fornecedor. Quando a casa já está em ordem, o alerta vira apenas confirmação de que você está no caminho certo.

O elefante na sala: open source como bode expiatório

Tem um padrão que todo MSP reconhece depois de alguns anos de estrada.

O cliente não quer pagar licença de hipervisor comercial. Escolhe Proxmox — escolha legítima, plataforma excelente, comunidade ativa, sem custo de licença. Mas junto com a economia na licença vem, com frequência alarmante, uma economia equivocada em tudo mais: sem suporte contratado, sem ciclo de atualização definido, sem hardening documentado, sem backup offsite testado, sem VPN, sem monitoramento.

Funciona. Por meses. Às vezes por anos inteiros.

Até o dia em que não funciona mais.

E aí? A culpa é do Proxmox. É do open source. É da “vulnerabilidade”. O fornecedor manda comunicado. O grupo de WhatsApp entra em pânico. O título vira “0day em Proxmox” e circula em dezenas de grupos sem o contexto que mudaria completamente a leitura.

Não é de hoje que o Proxmox virou alvo. O LockBit 5.0, documentado pela Acronis em fevereiro de 2026, já incluía suporte explícito a ambientes Proxmox — builds dedicados para hipervisores, estratégias específicas para escapar do PBS. Não por uma falha exclusiva da plataforma, mas porque o Proxmox cresceu como alternativa séria aos hipervisores comerciais — e cresceu junto com ele uma massa enorme de instalações sem manutenção ativa, expostas e sem defesa.

Atacantes são pragmáticos. Eles vão onde o retorno é maior com o menor esforço. E uma porta 8006 aberta na internet, rodando uma versão EOL de um hipervisor com root shell acessível via web, é literalmente o menor esforço possível.

Open source não significa sem custo operacional. Significa sem custo de licença. A diferença entre essas duas frases é exatamente o tamanho do prejuízo quando o ransomware chega.

A história que eu preferia não ter para contar

Alguns anos atrás, recebi uma ligação de um cliente em pânico. Servidor Proxmox comprometido. Dados criptografados. Sem backup funcional — o PBS estava configurado mas nunca tinha sido testado, e na hora H não restaurava nada.

O diagnóstico foi rápido: porta 8006 aberta na internet, porta 22 também, versão desatualizada, sem firewall na borda além do modem da operadora. A “segurança” do ambiente era a obscuridade — “quem vai saber que esse servidor existe?”

A resposta é: qualquer scanner automatizado que varra o range de IP da operadora. Que é exatamente o que aconteceu.

A recuperação foi parcial e dolorosa. O que salvou parte dos dados foi uma cópia manual que um funcionário havia feito por conta própria numa semana antes — por puro acaso, não por processo.

Depois disso, o ambiente foi refeito do zero com o modelo certo. Esse cliente ainda está comigo hoje, anos depois, sem nenhum incidente de segurança desde então. A diferença entre antes e depois não foi trocar o Proxmox por outra plataforma — foi tratar infraestrutura com a seriedade que ela merece.

O Proxmox não mudou. A operação mudou.

Como eu faço na prática — o modelo que funciona

Não é teoria. É o que rodo nos ambientes que gerencio, com variações de acordo com o porte e complexidade de cada cliente.

A regra número zero

A interface do Proxmox nunca fica exposta diretamente na internet.

Não existe exceção. Não existe “só por hoje enquanto viajo”. Não existe “mas é só a porta 8006, o resto está bloqueado”. A porta 8006 sem proteção na frente é exatamente o vetor que essa onda de ataques explorou.

O modelo de acesso

Dependendo do ambiente, uso diferentes stacks — mas o princípio é sempre o mesmo: pelo menos uma camada de autenticação e proteção antes de chegar na interface do Proxmox.

Ambientes com exposição à internet:

Internet → Cloudflare Zero Trust (ZT Access) → Tunnel → NPM / Zoraxy / HAProxy → Proxmox
                     ↓
          Política de identidade (e-mail, 2FA)
          Geo-blocking
          Rate limiting

O Cloudflare Zero Trust (ZT Access) autentica o usuário antes mesmo de o tráfego chegar ao servidor. O IP real do servidor nunca aparece no DNS público. O Tunnel elimina a necessidade de abrir qualquer porta no firewall de borda.

Para o proxy reverso interno, uso NPM (Nginx Proxy Manager) na maioria dos ambientes menores pela simplicidade de gestão, Zoraxy em alguns cenários específicos, e HAProxy em ambientes que exigem mais controle sobre ACLs e balanceamento. Ambientes corporativos e de clientes MSP:

Internet → Firewall de borda (MikroTik, Fortinet, SonicWall, Palo Alto, ou seja lá o que o cliente tem) → WireGuard VPN → Rede interna → Proxmox

A maioria dos MEUS clientes, que são micro ou pequenas empresas, tem MikroTik nas bordas, o que facilita muito a implementação de WireGuard com políticas granulares. O acesso administrativo ao Proxmox só existe dentro da VPN — ponto final. Para ambientes totalmente virtualizados, uso OPNsense como firewall/VPN dentro do próprio cluster. Se você quer entender como montar esse cenário do zero, escrevi sobre OPNsense em detalhes no blog — vale a leitura antes de montar qualquer ambiente que dependa de isolamento de rede.

📎 Artigo sobre OPNsense para homelab Proxmox

Acesso SSH:

• Porta não padrão (não é segurança real, mas reduz ruído nos logs)
• Autenticação exclusivamente por chave SSH — senha desabilitada
• fail2ban ativo com threshold baixo
• Acesso restrito a IPs conhecidos via firewall — lista curta, revisada periodicamente

Backup que sobrevive ao ransomware

PBS com Protected Backup (imutabilidade nativa) em servidor separado do host Proxmox. Réplica offsite do PBS — porque backup no mesmo datacenter que o servidor não é backup, é cópia de conforto.

O atacante que compromete o host Proxmox não consegue apagar o backup imutável no PBS. E mesmo que comprometa o PBS local, a réplica offsite permanece intacta.

# Verificar status de proteção dos backups no PBS
# Interface PBS → Datastore → Contents → verificar ícone de cadeado nos backups
# Ou via CLI:
proxmox-backup-client list --repository <repo>

Backup que nunca foi testado de restauração não é backup — é esperança. Teste de restauração tem que ser item fixo no contrato de manutenção.

O que fazer agora — checklist sem enrolação

Se você administra Proxmox para clientes, faça esse levantamento hoje:

Conclusão

O Tácio acertou em alertar. A situação era real, os casos eram confirmados, e a comunidade precisava do aviso — especialmente os administradores que talvez não acompanhem o fórum oficial do Proxmox com a frequência que deveriam. O Caio Monteiro do canal Empresa Livre também fez um ótimo trabalho documentando o caso em vídeo e criando um script de auditoria para verificar ambientes afetados — vale muito assistir e compartilhar com quem ainda opera versões antigas.

A vulnerabilidade também era real — um auth bypass legítimo em libpve-access-control, corrigido por acidente em 2023, que ficou sem CVE e sem holofote até que alguém começou a explorar em escala. Isso não é culpa de usuário descuidado.

O que não ajuda é a narrativa de “0day mágico no Proxmox” sem contexto técnico — porque ela desvia o olhar de onde o problema de fato mora. A vulnerabilidade existia, mas só era alcançável em condições que nunca deveriam existir: porta 8006 exposta diretamente na internet, em versão sem suporte, sem nenhuma camada de proteção na frente.

Se a sua porta 8006 nunca esteve exposta diretamente na internet, esse exploit nunca chegou nem perto de você — independente da versão do Proxmox que você roda.

Se esteve — e você está lendo isso agora sem ter tomado nenhuma ação — pare o que estiver fazendo e corrija isso antes de continuar.

O Proxmox não é o problema. A porta aberta é o problema. A cultura de “funciona, não mexe” aplicada a infraestrutura crítica exposta à internet é o problema.

E open source não tem nada a ver com isso — a não ser pela conveniência de ter uma plataforma poderosa disponível para qualquer um instalar, sem que “qualquer um” necessariamente saiba o que está fazendo depois que o instalador termina.

Referências