Vite: ataques expõem credenciais de nuvem
Uma campanha automatizada de varredura em larga escala está explorando servidores de desenvolvimento baseados no Vite expostos à internet. O objetivo dos invasores é localizar arquivos com informações confidenciais, como chaves da AWS, tokens do Azure, senhas de bancos de dados e estados de ambientes Terraform.
A atividade foi identificada por sensores honeypot da F5, que registraram 807 ataques e aproximadamente 32 mil eventos brutos em agosto. O volume representa um crescimento expressivo em relação aos 1.732 eventos anteriormente associados ao Vite, indicando que a exploração deixou de ser pontual e passou a integrar operações automatizadas de busca por credenciais.
Falha permite acessar arquivos do sistema
A campanha se concentra principalmente na CVE-2026-39364, vulnerabilidade de alta gravidade divulgada em abril. O problema afeta as versões 7.1.0 a 7.3.1 e 8.0.0 a 8.0.4 do Vite.
Durante o desenvolvimento, o Vite disponibiliza a rota interna `@fs`, utilizada para servir arquivos do sistema operacional do host. Em determinadas condições, parâmetros de consulta como `?raw`, `?import&raw` e `?import&url&inline` conseguem contornar o mecanismo de proteção e fazer com que o servidor entregue arquivos que deveriam permanecer restritos. Quando a tentativa é bem-sucedida, o conteúdo pode ser retornado com código HTTP 200, dando a impressão de uma resposta legítima.
A exploração depende de alguns requisitos. O servidor precisa estar acessível pela rede, e o arquivo requisitado deve estar dentro das regras que o Vite considera permitidas. Na prática, porém, configurações inadequadas podem ampliar esse alcance e transformar uma ferramenta destinada ao ambiente local em uma porta de entrada para dados sensíveis.
Configurações que aumentam o risco
Por padrão, o Vite costuma se vincular ao endereço local da máquina. O problema surge quando essa configuração é alterada para permitir acesso externo. Isso pode ocorrer com o uso da opção `-host`, com o encaminhamento de portas em contêineres ou por meio de regras permissivas em grupos de segurança de provedores de nuvem.
Ambientes de desenvolvimento publicados temporariamente para testes também podem permanecer acessíveis por mais tempo do que o necessário. Em muitos casos, o serviço não recebe o mesmo nível de proteção aplicado a aplicações de produção, embora esteja conectado às mesmas redes, variáveis de ambiente e serviços internos.
Os pesquisadores observaram tentativas que combinavam a rota `@fs` com travessia de diretórios, codificação dupla e diferentes formatos de caminho. Entre os alvos estavam arquivos como `.env` e `/proc/self/environ`. Essas técnicas podem ajudar a driblar proxies reversos, filtros de aplicação e firewalls que não interpretam os caminhos da mesma maneira que o servidor de desenvolvimento.
Arquivos procurados pelos invasores
A lista usada na campanha demonstra que os operadores conhecem a estrutura comum de projetos modernos. Os pedidos incluem arquivos de configuração, credenciais de provedores de nuvem, tokens de autenticação e arquivos de estado utilizados pelo Terraform.
Um dos alvos mais relevantes é `/proc/self/cwd/.env`. Esse caminho permite tentar localizar o arquivo de ambiente associado ao diretório de trabalho do processo em execução, sem que o atacante precise descobrir previamente onde o projeto foi instalado.
Um arquivo `.env` exposto pode conter chaves de API, credenciais de serviços externos, senhas de bancos de dados, tokens de integração contínua e parâmetros para acesso a recursos internos. Em ambientes de nuvem, a consequência pode ser ainda mais grave: chaves de acesso podem permitir a criação de máquinas virtuais, leitura de buckets, alteração de configurações ou movimentação lateral dentro da conta.
Arquivos de estado do Terraform também são especialmente sensíveis. Dependendo da configuração, eles podem armazenar identificadores de recursos, endereços internos, parâmetros de infraestrutura e até segredos que não foram devidamente protegidos.
Origem e características da campanha
A maior parcela do tráfego observado partiu de infraestrutura hospedada em nuvem, principalmente do Google Cloud Platform. Para dificultar a investigação, os invasores também falsificaram identificações de rastreadores e agentes de usuário, tentando fazer com que as requisições parecessem tráfego legítimo de mecanismos de busca ou ferramentas de monitoramento.
Os Estados Unidos concentraram o maior número de eventos. Na sequência apareceram Bélgica, Países Baixos, Singapura, Taiwan e Japão. A distribuição geográfica, contudo, não permite atribuir os ataques diretamente a esses países, já que servidores comprometidos, redes alugadas e serviços de nuvem podem ser usados para mascarar a origem real.
A mesma infraestrutura também foi observada testando uma falha no Next.js e acionando assinaturas relacionadas a outras três vulnerabilidades de desvio de acesso a arquivos. Uma delas foi incluída pela CISA em seu catálogo de falhas exploradas, o que reforça a hipótese de que os operadores utilizam ferramentas automatizadas para testar vários produtos e identificar alvos vulneráveis.
Como reduzir a exposição
A medida mais importante é atualizar o Vite imediatamente. As versões recomendadas são a 7.3.2, a 8.0.5 ou qualquer edição posterior disponibilizada pelo projeto. A atualização deve ser aplicada em todos os ambientes, incluindo máquinas de desenvolvedores, servidores de integração contínua, contêineres e instâncias temporárias usadas em testes.
Também é necessário remover servidores de desenvolvimento de redes públicas. Eles devem permanecer acessíveis apenas localmente ou por meio de uma rede privada, VPN, túnel autenticado ou mecanismo equivalente. A simples existência de autenticação na aplicação não deve ser considerada proteção suficiente se o servidor continua vulnerável ao acesso indevido de arquivos.
Equipes de infraestrutura precisam revisar regras de firewall, grupos de segurança, balanceadores e mapeamentos de portas. Deve-se verificar se opções como `-host 0.0.0.0` foram usadas sem necessidade e se contêineres estão expondo portas diretamente à internet.
Rotação de credenciais é essencial
Se houver qualquer possibilidade de que um arquivo `.env`, um estado do Terraform ou uma variável de processo tenha sido acessado, as credenciais devem ser consideradas comprometidas. Nesse cenário, é recomendável revogar e substituir chaves da AWS, tokens do Azure, senhas de bancos de dados, credenciais de APIs e certificados relacionados ao ambiente.
A rotação precisa ser acompanhada por uma análise de logs. Na AWS, devem ser revisados eventos de autenticação, criação de recursos, alterações de políticas e acessos incomuns. No Azure, é importante examinar registros de login, uso de tokens, alterações em assinaturas e operações realizadas por identidades de serviço.
Além da troca de segredos, a organização deve reduzir privilégios. Chaves utilizadas por aplicações de desenvolvimento não devem possuir permissões administrativas nem acesso amplo a contas de produção. O uso de identidades temporárias, cofres de segredos e autenticação multifator ajuda a limitar o impacto de uma eventual exposição.
Indicadores para monitoramento
As equipes de segurança devem procurar requisições contendo `@fs`, referências a `.env`, `/proc/self/environ`, `/proc/self/cwd` e padrões de travessia de diretórios. Respostas incomuns com código 200 para caminhos que normalmente não fazem parte da aplicação também merecem investigação.
Outros sinais incluem picos de tráfego contra portas de desenvolvimento, requisições com parâmetros `raw` e `inline`, agentes de usuário falsificados e acessos originados de provedores de nuvem sem relação com a operação da empresa.
A adoção de inventário atualizado é igualmente importante. Muitas organizações não sabem quais servidores de teste, notebooks, containers ou pipelines estão acessíveis externamente. A descoberta contínua de ativos reduz esse ponto cego e permite corrigir serviços esquecidos antes que sejam encontrados por campanhas automatizadas.
Por fim, o caso mostra que ferramentas de desenvolvimento não devem ser tratadas como inofensivas apenas por não integrarem o ambiente de produção. Quando estão conectadas a variáveis de ambiente, repositórios, credenciais e serviços corporativos, uma falha aparentemente limitada pode se transformar em um incidente de grande alcance. Atualização, isolamento de rede, controle de privilégios e monitoramento devem ser aplicados em conjunto para impedir o roubo de segredos de nuvem.