Atacantes estão conduzindo uma campanha de varredura automatizada em larga escala contra servidores de desenvolvimento Vite expostos na internet, com o objetivo de roubar credenciais da AWS, tokens de acesso do Azure, variáveis de ambiente e segredos de infraestrutura como código (IaC). Sensores honeypot da F5 registraram 807 ataques agrupados em sessões e cerca de 32.000 eventos brutos em agosto de 2026, um aumento acentuado em relação aos 1.732 eventos de leitura de arquivos relacionados ao Vite observados nos três meses anteriores.
Descoberta e escopo da campanha
A operação explorou principalmente a vulnerabilidade CVE-2026-39364, uma falha de alto risco de divulgação de arquivos no Vite publicada em abril de 2026. Os atacantes também testaram contornadores de controle de acesso mais antigos do Vite, sugerindo que a infraestrutura de varredura utiliza uma biblioteca de exploits ampla em vez de depender de uma única vulnerabilidade. O rápido aumento na atividade demonstra como os atores de ameaças incorporam rapidamente falhas de estrutura recém-divulgadas em campanhas automatizadas de coleta de credenciais em nuvem.
A vulnerabilidade CVE-2026-39364 afeta as versões do Vite 7.1.0 até 7.3.1 e Vite 8.0.0 até 8.0.4. A vulnerabilidade permite que atacantes não autenticados recuperem arquivos que a configuração server.fs.deny deveria bloquear, incluindo arquivos .env e certificados. O Vite fornece uma rota interna @fs que serve arquivos do sistema de arquivos host durante o desenvolvimento. Embora o mecanismo de lista de bloqueio seja destinado a impedir que navegadores solicitem conteúdo sensível, parâmetros de consulta especialmente construídos, incluindo ?raw, ?import&raw e ?import&url&inline, podem contornar essa proteção e fazer com que o servidor retorne arquivos restritos com uma resposta HTTP 200.
Vetor e exploração técnica
A exploração requer que o servidor de desenvolvimento Vite seja alcançável por rede, que o arquivo alvo esteja dentro de um diretório permitido pelo server.fs.allow e que o arquivo corresponda a uma regra server.fs.deny. O Vite vincula-se ao localhost por padrão, mas os desenvolvedores podem expô-lo a interfaces LAN ou públicas através da opção --host, configuração server.host, mapeamentos de porta de contêiner, regras de ingress do Kubernetes ou erros de grupo de segurança em nuvem.
A F5 observou requisições que combinavam o endpoint @fs com contornadores de string de consulta, travessia de caminho e separadores duplamente codificados. Exemplos incluíram requisições para .env, /root/.env, /proc/self/environ e caminhos profundamente codificados contendo %252f. A codificação dupla pode ajudar requisições maliciosas a passar por proxies reversos ou firewalls de aplicativos web que normalizam caminhos de maneira diferente do servidor backend.
Os scanners usaram uma lista de palavras de credenciais cuidadosamente montada cobrindo .env.local, .env.production, .env.staging, arquivos de credenciais da AWS sob diretórios comuns de usuário Linux, caches de SSO da AWS, chaves de backup, rootkey.csv, aws-exports.js e arquivos de configuração do Amplify. Eles também procuraram por accessTokens.json do Azure e arquivos de credenciais, junto com estado do Terraform, variáveis do Terraform, estado do Serverless Framework e outros artefatos de implantação.
Impacto e alcance
Particularmente notável foi a sondagem para /proc/self/cwd/.env, que pode revelar o arquivo de ambiente do aplicativo ativo sem exigir que um atacante conheça seu caminho de instalação absoluto. Uma resposta bem-sucedida poderia expor chaves de API, senhas de banco de dados, chaves de acesso à nuvem, segredos de sessão, endereços de infraestrutura e dados de recursos gerenciados pelo Terraform, potencialmente transformando uma divulgação de servidor de desenvolvimento em uma comprometimento mais amplo da nuvem.
A campanha enviou requisições HTTP/1.0 com Connection: close, um padrão consistente com scanners automatizados leves. As requisições rotacionaram strings User-Agent forjadas imitando Googlebot, ClaudeBot, GPTBot, PerplexityBot, OAI-SearchBot e Amazonbot, enquanto cabeçalhos X-Forwarded-For e X-Real-For fabricados tentaram confundir a análise de log ou evadir listas de permissão de IP mal implementadas.
A maioria da atividade originou-se de infraestrutura de hospedagem em nuvem, particularmente endereços nos intervalos 34.x e 35.x do Google Cloud Platform. Os Estados Unidos responderam por 17.297 eventos registrados, seguidos pela Bélgica com 4.407, Holanda com 4.011, Cingapura com 2.842, Taiwan com 1.994 e Japão com 1.353.
Medidas de mitigação recomendadas
Organizações devem atualizar instalações afetadas para as versões Vite 7.3.2, 8.0.5 ou versões suportadas mais recentes e remover servidores de desenvolvimento de redes voltadas para o público. Equipes de segurança devem auditar arquivos Docker Compose, serviços Kubernetes, configurações de ingress, proxies reversos, regras de firewall e grupos de segurança em nuvem em busca de portas de desenvolvimento expostas, particularmente a porta 5173 comumente usada pelo Vite.
Defensores também devem inspecionar logs HTTP em busca de requisições contendo /@fs/, parâmetros de consulta raw ou import suspeitos, sequências de travessia codificadas e tentativas de recuperar arquivos de ambiente, AWS, Azure, Terraform ou /proc. Não confie em identidades de bot apenas de strings User-Agent; valide o acesso de rastreador com verificação de IP e DNS reverso apropriada.
Qualquer organização que expôs um servidor Vite não corrigido deve assumir que os atacantes podem ter coletado segredos acessíveis. Chaves da AWS, tokens do Azure, credenciais de banco de dados, segredos de API, chaves de assinatura e credenciais gerenciadas pelo Terraform devem ser revogadas ou rotacionadas, seguidas por uma revisão de logs de auditoria em nuvem para autenticação não autorizada, elevação de privilégios, persistência e criação de recursos.
O que os CISOs devem fazer imediatamente
1. Verifique se há servidores Vite expostos publicamente ou em redes LAN acessíveis.
2. Atualize todas as instâncias do Vite para a versão 7.3.2 ou superior imediatamente.
3. Revise as configurações de segurança de grupo em nuvem para garantir que a porta 5173 não esteja aberta para a internet.
4. Implemente monitoramento de logs para detectar padrões de ataque relacionados ao endpoint @fs.
5. Revogue e rotacione todas as credenciais de nuvem que possam ter sido expostas em ambientes de desenvolvimento.