HashiCorp, Veeam e a Django Software Foundation corrigiram 11 vulnerabilidades no Terraform MCP Server, no Veeam Service Provider Console e no Django.
As três mais graves são:
- uma falha sem autenticação no console da Veeam, que expõe as credenciais de um agente gerenciado, com nota 9,5;
- uma falha entre locatários no servidor MCP da HashiCorp, que permite reutilizar o token Terraform de um usuário em solicitações de usuários posteriores, com pontuação máxima de 10,0 no registro CVE;
- uma falha nas consultas espaciais do GeoDjango, que pode gravar um arquivo em disco e, em algumas configurações, executar código, acessível por um usuário da equipe com permissão de visualização em um modelo registrado que contenha um campo espacial.
Todas já têm correção disponível.
Os operadores devem atualizar o Terraform MCP Server para a versão 1.1.0 ou superior, o Veeam Service Provider Console para 9.3.0.35057 e o Django para 6.0.8 ou 5.2.17.
A exposição depende da configuração.
As falhas da HashiCorp afetam o modo Streamable HTTP, e não o stdio.
As falhas da Veeam atingem builds 9 da versão 9.3.
As instruções públicas da Django para o caminho de ataque no admin exigem uma conta de equipe com permissão de visualização em um modelo que contenha um campo espacial.
Nenhum dos três comunicados afirma que as falhas estejam sendo exploradas ativamente e, em 5 de agosto de 2026, nenhum dos 11 CVEs aparece no catálogo de Known Exploited Vulnerabilities da CISA.
Também não surgiu prova de conceito pública.
Fingir ser um agente e capturar suas credenciais
O Veeam Service Provider Console, o console multitenant usado por empresas de hospedagem e provedores de serviços gerenciados para operar e monitorar backups de clientes, recebeu quatro correções no build 9.3.0.35057, detalhadas em um comunicado de segurança publicado em 4 de agosto.
Duas são críticas.
A Veeam lançou o build em 29 de julho.
A mais importante é a
CVE-2026-58073
, com nota CVSS 9,5, que permite a um invasor sem autenticação se passar por um agente gerenciado e obter as credenciais desse agente.
A métrica CVSS indica complexidade de ataque alta.
A segunda falha crítica,
CVE-2026-58072
, com CVSS 9,0, é uma gravação arbitrária de arquivo no servidor de gerenciamento, que pode levar à execução remota de código e exige uma conta com poucos privilégios.
A nota 9,5 parece ser a pior das duas porque não exige login, mas a alta complexidade de ataque explica por que o vetor não é uma exploração direta.
Sem autenticação, nesse caso, não significa fácil.
Dois bugs de alta severidade completam o conjunto:
CVE-2026-58067
, uma negação de serviço por exaustão de memória sem autenticação, e
CVE-2026-58071
, que expõe a API do dispositivo proxy como Administrador do Portal durante uma breve janela após o início de uma sessão administrativa.
As quatro falhas afetam o VSPC 9.2.1.33875 e todas as versões anteriores da série 9.
A correção é a atualização para 9.3.0.35057.
Este é o segundo ciclo de correção crítica para o console em cerca de três meses.
Em maio, a Veeam corrigiu a
CVE-2026-32998
, uma falha de execução remota de código com nota 9,4 associada à execução de scripts de alarmes.
O token de um locatário, reutilizado para o próximo
O Terraform MCP Server da HashiCorp, que conecta assistentes de IA ao Terraform por meio do Model Context Protocol, traz três falhas relacionadas em seu transporte Streamable HTTP, divulgadas em 28 de julho e corrigidas na versão 1.1.0.
A HashiCorp disponibilizou a versão corrigida em 14 de julho, seguida pela 1.2.0 em 4 de agosto.
Implantações que usam apenas o modo stdio, a configuração local para um único usuário, não são afetadas.
Os problemas estão no modo HTTP para múltiplos usuários, pensado para ambientes centralizados e compartilhados, a configuração que a HashiCorp promoveu quando tornou o servidor geralmente disponível em junho.
A mais grave é a
CVE-2026-16498
, com CVSS 10,0, uma falha de reutilização de credenciais entre locatários no modo HTTP sem estado.
A biblioteca MCP subjacente não atribui identificadores de sessão exclusivos, e o cache de credenciais do servidor dependia desses identificadores para distinguir usuários.
Assim, o token Terraform de um usuário podia ser reutilizado em solicitações de usuários posteriores, independentemente do token informado por eles.
A raiz do problema está em uma suposição sobre a camada abaixo da ferramenta: o servidor usava esses identificadores de sessão para separar locatários, mas, no modo sem estado, a biblioteca MCP não fornecia IDs exclusivos.
A segunda falha,
CVE-2026-16496
, com CVSS 8,9, é a versão, no modo com estado, da mesma falha de isolamento.
O modo com estado é o padrão quando o servidor roda de forma centralizada.
Nesse caso, o cache usava o ID da sessão MCP como única chave de busca, sem vincular o cliente em cache ao token que o criou.
Isso permitia que um usuário que obtivesse o ID de sessão de outra pessoa executasse chamadas de ferramenta com o cliente Terraform dessa vítima e alcançasse recursos autorizados pelo token da vítima.
Juan Pablo Martinez Kuhn, da Coinspect, relatou a falha.
A HashiCorp encontrou as outras duas internamente.
A terceira,
CVE-2026-14869
, com CVSS 8,6, é uma falha de falsificação de solicitação do lado do servidor.
Um middleware de requisições rejeitava um endereço Terraform fornecido pelo cliente quando ele chegava como cabeçalho HTTP, mas não quando o mesmo valor vinha como parâmetro de consulta.
Um chamador sem autenticação que conseguisse alcançar o listener Streamable HTTP poderia fazer o servidor enviar seu token bearer configurado para um endpoint controlado pelo invasor.
Dois pontos dificultam ler os números CVSS como uma ordem de prioridade.
Eles não usam a mesma escala: a Veeam calcula as notas com CVSS 4.0 e os registros da HashiCorp com 3.1, portanto 9,5 e 10,0 não representam a mesma medição.
Além disso, as duas falhas de isolamento afetam configurações diferentes.
A de 10,0,
CVE-2026-16498
, atinge o modo sem estado, que o operador precisa habilitar manualmente.
Já a de 8,9,
CVE-2026-16496
, afeta o modo com estado, que é o padrão em uma implantação central.
Qual das duas está ao alcance depende de como o servidor foi configurado, e não de qual delas tem a nota mais alta.
Há uma divergência nos intervalos de versões afetadas publicados.
O comunicado geral da HashiCorp lista as versões de 0.2.1 a 1.0.0, enquanto os registros individuais de CVE começam na versão 0.3.0.
Ambas as fontes concordam que a versão 1.1.0 é a primeira corrigida.
As notas vêm dos registros CVE atribuídos pela HashiCorp.
O comunicado em si não lista nenhuma.
Operadores que não puderem atualizar imediatamente devem restringir o acesso de rede ao listener Streamable HTTP a usuários confiáveis e tratar os IDs de sessão MCP como valores sensíveis.
De volta ao caminho raster do GeoDjango
O Django lançou as versões 6.0.8 e 5.2.17 em 4 de agosto, com as mesmas correções aplicadas ao ramo principal e ao ramo candidato a lançamento do Django 6.1.
A atualização cobre quatro CVEs.
O Django classifica a severidade de acordo com sua própria política de segurança, e apenas uma foi considerada alta.
Essa falha,
CVE-2026-15307
, está no GeoDjango, a camada de dados geográficos do framework.
As consultas espaciais aceitavam valores str e dict e os repassavam ao GDALRaster quando pareciam representar rasters.
Dependendo do driver de raster, isso podia gravar um arquivo em disco ou fazer o processo do Django emitir uma requisição de rede.
Gravar um arquivo em um local que depois seja importado pela aplicação pode resultar em execução remota de código.
O caminho documentado no admin pode ser acessado por usuários da equipe com permissão de visualização em um modelo registrado que contenha um campo espacial.
A correção proíbe valores dict e strings que não sejam valores GEOSGeometry válidos em consultas espaciais, uma mudança incompatível com versões anteriores.
A atribuição direta a campos de modelo ainda aceita esses tipos.
As outras três falhas têm severidade menor:
- um bug moderado de cross-site scripting armazenado no admin, em que valores inseguros de URLField podiam ser renderizados como links e executar código ao serem clicados, na
CVE-2026-15920
;
- uma negação de serviço moderada por objetos GEOMETRYCOLLECTION muito aninhados, que podiam provocar uma falha de segmentação no GEOS, na
CVE-2026-15830
, agora limitada a 198 coleções;
- uma negação de serviço de baixo impacto por consumo de memória em check_for_language(), na
CVE-2026-15337
, agora recusando códigos de idioma com mais de 500 caracteres.
Ramos antigos sem suporte, incluindo Django 5.1, 5.0 e 4.2, não foram avaliados e também podem ser afetados.
O código GIS do Django já chamou a atenção de invasores neste ano.
Em fevereiro, o projeto corrigiu a
CVE-2026-1207
, uma falha de injeção SQL em consultas raster do PostGIS.
A CrowdSec relatou exploração em ambiente real.
A empresa publicou uma regra de detecção em 18 de fevereiro, observou os primeiros ataques em 26 de fevereiro e depois viu tentativas contínuas de sondagem para localizar implantações de Django com suporte a PostGIS.
Essa falha exigia um back-end PostGIS e entrada controlada pelo usuário em uma consulta específica.
A sondagem localiza o tipo de aplicação sem abri-la.
O caminho documentado da nova falha exige uma conta da equipe, e identificar um site público não fornece isso, então o reconhecimento que encontrou Django com suporte a PostGIS para por um passo antes de uma entrada real.
O que permanece é a atenção sobre esse código.
Publicidade
Vibecoding cria 10x mais sistemas, 20x mais vulneráveis. E quem ganha com isso é a galera do hacking ético e pentest. Quer ser pago para invadir sistemas? Então você tem que aprender com a Solyd que são os melhores do Brasil. Saiba mais...