Veeam gravou credenciais em texto puro — duas versões fecham a falha

Em 25 de agosto de 2026, a Veeam revelou que o Backup & Replication 13 podia registrar em texto puro, nos logs da máquina virtual convidada, credenciais do sistema operacional usadas pelo Application Aware Processing. O boletim KB4902 da Veeam classifica a CVE-2026-58070 como de gravidade média, com CVSS 4.0 de 6,8, e informa que a correção começa no VBR 13.0.3 build 13.0.3.63 e no VBR 13.1 build 13.1.0.411.

O aviso do fornecedor, publicado em 25 de agosto, abrange instalações do Veeam Backup & Replication baseadas em Windows e o Veeam Software Appliance. Dois dias depois, o Centro Canadense de Segurança Cibernética reiterou os dois limites de versão e recomendou a aplicação das atualizações necessárias.

Quais instalações estão no intervalo afetado

A classificação depende da build instalada, e não apenas do rótulo “versão 13”. Segundo a Veeam, a build 13.0.2.29 e todas as builds anteriores da família 13 são afetadas; versões mais antigas de outras famílias, como a 12.x, não são afetadas por esta vulnerabilidade específica.

• VBR 13.0.2.29 ou build 13 anterior: está no intervalo vulnerável.
• VBR 13.0.3 build 13.0.3.63 ou posterior: contém a correção indicada para a linha 13.0.
• VBR 13.1 build 13.1.0.411 ou posterior: contém a correção indicada para a linha 13.1.
• VBR 12.x: fica fora do escopo desta CVE, sem que isso dispense a avaliação de outros avisos de segurança.

A formulação dos alertas governamentais é mais ampla que a descrição individual da CVE. O aviso do CERT-FR de 26 de agosto reúne vulnerabilidades do Veeam Backup & Replication e do Veeam ONE, aponta risco à confidencialidade e lista como afetadas as versões 13.x do VBR anteriores à 13.0.3. Para decidir sobre a CVE-2026-58070, porém, prevalecem os limites de build mais precisos publicados pela Veeam.

O segredo aparece na máquina virtual convidada

A exposição descrita não está restrita aos registros do servidor de backup. O dado sensível pode aparecer nos logs da própria máquina virtual convidada processada pelo Application Aware Processing: trata-se da credencial do sistema operacional convidado fornecida ao Veeam para esse processamento.

Os três avisos públicos não indicam um caminho de arquivo universal, o nome exato do log ou seu período de retenção. Também não afirmam que houve exploração ativa. Portanto, não é possível concluir apenas pela presença de uma build afetada que uma senha foi obtida por terceiros; é necessário determinar se o recurso foi usado, quais convidados foram processados e quais registros ainda existem.

A triagem pode começar pelo histórico dos jobs executados enquanto a build vulnerável estava instalada. Para cada job com Application Aware Processing, a equipe deve relacionar as máquinas convidadas alcançadas, a credencial configurada e o intervalo de execução. A busca precisa considerar os logs locais e eventuais cópias já encaminhadas a coletores, pacotes de suporte ou plataformas de monitoramento, evitando reproduzir o próprio segredo em tickets e relatórios de análise.

O patch corrige o produto, não as cópias já criadas

As builds corrigidas tratam a vulnerabilidade no software, mas os boletins não prometem localizar ou apagar automaticamente registros anteriores. Se um log vulnerável tiver sido copiado para outro sistema, a atualização do VBR não altera essa cópia. Por isso, atualização e saneamento dos registros são frentes separadas da mesma resposta.

1. Inventariar as instalações do VBR e registrar a build efetivamente usada em cada servidor.
2. Atualizar instalações afetadas para uma build corrigida compatível com a linha adotada.
3. Identificar os jobs que usaram Application Aware Processing no período vulnerável e as contas associadas.
4. Examinar os registros disponíveis nas máquinas convidadas e mapear exportações conhecidas para outros sistemas.
5. Isolar os arquivos relevantes e restringir sua leitura antes de decidir entre preservação e expurgo.
6. Rotacionar as credenciais potencialmente registradas e atualizar as referências correspondentes no Veeam.

O expurgo não deve ser indiscriminado. Quando houver indício de acesso não autorizado, os logs podem ser evidência para a resposta ao incidente e devem ser preservados de forma protegida conforme as regras da organização. Fora desse cenário, a remoção precisa abranger as cópias identificadas e respeitar requisitos de auditoria, retenção e investigação.

Rotação e restauração completam a verificação

Apagar um arquivo não invalida uma senha que já possa ter sido lida ou copiada. Quando a triagem encontrar o segredo em texto puro — ou não conseguir excluir de maneira confiável essa possibilidade — a medida conservadora é rotacionar a conta usada pelo Application Aware Processing. Se a mesma credencial tiver sido reutilizada em outros pontos, esses acessos também precisam ser revistos.

Após a troca, a credencial armazenada no Veeam deve ser atualizada e validada com um job controlado. Erros de autenticação nessa etapa normalmente apontam para referências que ainda usam o valor anterior; restaurar a senha antiga anularia a rotação. Os novos logs devem ser examinados sem transportar valores sensíveis para a documentação operacional.

Um teste de restauração compatível com a carga protegida encerra a verificação técnica: ele confirma que a atualização e a troca da credencial não comprometeram a recuperabilidade. Até os avisos publicados entre 25 e 27 de agosto, havia correção disponível nas linhas 13.0.3 e 13.1, mas não foram divulgados caminhos universais para os logs, limpeza automática de registros antigos ou evidências de exploração ativa. Essas lacunas exigem avaliação individual de cada ambiente.