Veeam 12.3.2 P4: por que uma conta só de leitura ameaça seus backups
Por Equipe Técnica HD Doctor
Resposta direta
Se a empresa usa o Veeam Backup & Replication 12 na build 12.3.2.4854 ou anterior, atualize para o 12.3.2 P4 (build 12.3.2.4934). A falha crítica corrigida permite que uma conta com o papel Backup Viewer, feito apenas para consultar jobs, execute código no servidor de backup. A versão 13 não é afetada e não há exploração relatada. Até atualizar, revise quem tem esse papel e mantenha ao menos uma cópia que o servidor Veeam não consiga apagar.
O que a Veeam corrigiu no KB4934
Em 06/10/2026, a Veeam publicou o KB4934, que corrige três falhas no Veeam Backup & Replication 12. A mais grave, CVE-2025-64393 (crítica, CVSS v4.0 9.4), permite que um usuário de baixo privilégio com o papel Backup Viewer execute código remotamente no servidor de backup, por desserialização insegura de dados recebidos pelo Mount Service. São afetadas a build 12.3.2.4854 (12.3.2 P3) e as anteriores da versão 12; a correção é o 12.3.2 P4, build 12.3.2.4934. Segundo o KB, nenhuma build da versão 13 é afetada. Fonte: https://www.veeam.com/kb4934. O mesmo boletim corrige a CVE-2026-93026 (média, CVSS v4.0 6.1), em que um usuário autenticado com o papel Backup Viewer pode alterar ou apagar a chave mestra do Enterprise Manager e ler ou sobrescrever credenciais guardadas para atualização do antivírus, e a CVE-2025-64392 (média, CVSS v4.0 4.8), um XSS refletido no Enterprise Manager que executa script no navegador de um usuário autenticado que abrir um link malicioso. As três foram relatadas à Veeam pela plataforma HackerOne. Em 09/10/2026, a Agência de Cibersegurança de Singapura (CSA) publicou alerta sobre a falha crítica e recomendou atualizar imediatamente. Fonte: https://www.csa.gov.sg/alerts-and-advisories/alerts/al-2026-138/. Nem o KB nem o alerta de Singapura relatam exploração em ataques, e até a data deste artigo não localizamos relato público de exploração. A própria Veeam alerta que atacantes costumam fazer engenharia reversa das correções depois de publicadas. Como o boletim saiu há um mês, quem ainda está em build afetada deve tratar a atualização como prioridade, sem esperar notícia de ataque. O KB também lembra que a versão 12 chega ao fim do suporte em 28/02/2027. Pela documentação da Veeam, o Backup Viewer tem acesso somente leitura ao console: vê a lista de jobs e os detalhes das sessões. Fonte: https://helpcenter.veeam.com/docs/backup/vsphere/configuring_users.html?ver=120. Por parecer inofensivo, é o papel que costuma ser dado a quem só acompanha relatórios, como um gestor, um auditor ou um prestador. Com a falha, essa conta vira caminho para executar código no servidor que guarda credenciais de acesso aos sistemas protegidos e comanda jobs e repositórios. Ransomware moderno tenta apagar ou cifrar os backups antes de atacar a produção, e um servidor Veeam tomado facilita exatamente isso. Se o papel foi atribuído a um grupo amplo do domínio, qualquer conta comprometida desse grupo passa a servir ao atacante. Esse é um cenário de risco para orientar a revisão, não um incidente relatado. Atualizar fecha a falha, mas não mostra se alguém já usou esse acesso nem substitui uma cópia fora do alcance do servidor Veeam, como um repositório hardened ou imutável ou uma mídia offline. Se arquivos de backup ou volumes do repositório ficarem ilegíveis e nenhuma cópia válida resolver, preserve o material: a HD Doctor pode avaliar a recuperação a partir dos dados e mídias afetados, sem garantia antecipada de resultado. A correção do produto e o suporte à atualização ficam com a Veeam e com a equipe responsável pelo ambiente.
Quatro decisões que deixam os backups expostos
- 1.Tratar o Backup Viewer como papel inofensivo. Enquanto o servidor estiver em build afetada, cada conta ou grupo com esse papel é um caminho até o servidor de backup. Não atribua o papel a grupos amplos do domínio nem a contas compartilhadas.
- 2.Adiar a atualização à espera de notícia de ataque. A ausência de exploração relatada não protege o servidor. A Veeam alerta que correções publicadas costumam passar por engenharia reversa; agende a janela de manutenção agora.
- 3.Administrar o Veeam com credenciais do domínio de produção. Se a mesma conta administra estações, servidores e o console de backup, um único roubo de senha alcança tudo. Mantenha contas dedicadas para o Veeam e para os repositórios.
- 4.Deixar todas as cópias ao alcance do próprio servidor Veeam. Se o servidor de backup consegue apagar todas as cópias, quem tomar o servidor também consegue. Mantenha ao menos uma cópia imutável ou offline, fora desse alcance.
Cinco passos para fechar a falha e proteger as cópias
Roteiro para a equipe de TI e o prestador que administra o backup. Não tente reproduzir a falha nem execute códigos de teste encontrados na internet para confirmar a exposição.
- 1
Confirme a versão e a build instalada
Verifique a build do Veeam Backup & Replication em cada servidor de backup, inclusive em filiais e em ambientes administrados por prestador. Build 12.3.2.4854 ou anterior da versão 12 está afetada; 12.3.2.4934 está corrigida; a versão 13 não é afetada, segundo o KB4934.
- 2
Aplique o 12.3.2 P4 em uma janela planejada
Baixe a atualização pelo link do KB4934 no site da Veeam, nunca por link recebido em mensagem. Antes, registre o estado dos jobs e a última cópia válida; depois, confira se os jobs voltaram a rodar e se o Enterprise Manager, quando usado, também foi atualizado conforme as instruções do fabricante.
- 3
Revise quem tem o papel Backup Viewer
No console, abra Users and Roles pelo menu principal e liste usuários e grupos com cada papel. Remova atribuições sem uso, troque grupos amplos por contas nominais e registre o responsável por cada acesso que continuar.
- 4
Separe as credenciais do backup do domínio de produção
Use contas dedicadas para administrar o Veeam e os repositórios, que não sejam usadas no dia a dia nem em estações comuns. Revise as credenciais guardadas no servidor de backup e, se houver suspeita de acesso indevido, troque-as com a equipe de segurança.
- 5
Garanta uma cópia fora do alcance e teste a restauração
Confirme que ao menos uma cópia está em repositório hardened, armazenamento com Object Lock ou mídia offline, e que o servidor Veeam não consegue apagá-la. Restaure uma amostra em ambiente separado e confira conteúdo e data com o responsável pelos dados.
Perguntas sobre a falha do Veeam e a proteção dos backups
Minha empresa já usa o Veeam 13. Preciso fazer algo?
Segundo o KB4934, nenhuma build da versão 13 é afetada por essas três falhas. Ainda assim, vale aproveitar a revisão: confira quem tem o papel Backup Viewer e se existe uma cópia que o servidor de backup não consiga apagar.
A falha já está sendo explorada em ataques?
Nem a Veeam nem o alerta de Singapura relatam exploração, e não localizamos relato público até a data deste artigo. Isso pode mudar: a Veeam alerta que atacantes costumam estudar as correções publicadas. Atualize sem esperar a primeira notícia de ataque.
Se ninguém tem o papel Backup Viewer, estou protegido?
As duas falhas mais graves, como a Veeam as descreve, partem de uma conta autenticada com esse papel. Mas a lista de papéis pode estar desatualizada, e um grupo do domínio pode incluir membros que ninguém lembra. A correção indicada pelo fabricante é atualizar para o 12.3.2 P4.
Até quando a versão 12 tem suporte?
O KB4934 lembra que a versão 12 chega ao fim do suporte em 28/02/2027. O P4 resolve essas falhas agora, mas convém planejar a migração para a versão 13 com antecedência, incluindo um teste de restauração depois da mudança.
Quando faz sentido pedir recuperação profissional de dados?
Quando arquivos de backup ou volumes do repositório estiverem ilegíveis, o RAID do repositório tiver falhado ou a perda estiver confirmada sem cópia válida. Preserve as mídias e registre o que já foi tentado. Se a suspeita se limita a acesso indevido ao servidor Veeam, a prioridade inicial é a equipe de segurança e infraestrutura.
Os backups ficaram inacessíveis?
Preserve as mídias e informe a versão do Veeam, os sintomas, as datas e as tentativas já feitas.