Servidores de desenvolvimento Vite acessíveis pela Internet entraram na mira de uma operação automatizada que procura arquivos de ambiente, credenciais de nuvem e estados de infraestrutura como código. A atividade confirma tentativas de exploração; não confirma quantas organizações tiveram dados lidos nem se houve uso posterior das credenciais.
Uma ferramenta local colocada na borda da Internet
Vite é uma ferramenta de build e um servidor de desenvolvimento para aplicações Web. Durante o trabalho local, entrega módulos e atualiza a página por Hot Module Replacement. Esse comportamento melhora a produtividade, mas não foi concebido como camada endurecida para publicação na Internet.
Por padrão, o serviço fica no endereço local. O risco cresce com --host, server.host ou a publicação da porta do container. Também pode surgir por Service ou Ingress Kubernetes, reverse proxy, túnel de preview, regra cloud ou job de CI/CD que deixa o endpoint alcançável.
Ter Vite como dependência não torna a aplicação automaticamente vulnerável. A entrega dos artefatos de vite build, sem o dev server, não oferece o mesmo caminho. A exploração descrita exige servidor de desenvolvimento acessível e versão afetada.
Como a CVE-2026-39364 permite a leitura
A rota /@fs/ serve arquivos do sistema. Com server.fs.strict, server.fs.allow limita diretórios; server.fs.deny nega padrões sensíveis, como .env e certificados. A falha quebra essa segunda barreira em condições específicas.
Uma requisição HTTP sem autenticação pode apontar para arquivo dentro do escopo permitido e acrescentar ?raw, ?import&raw ou ?import&url&inline. Em versões vulneráveis, server.fs.deny não é aplicado como deveria e o arquivo pode voltar no corpo da resposta com status 200.
O advisory não descreve acesso irrestrito a qualquer caminho do host. Ainda assim, workspaces amplos, monorepos, volumes montados e diretórios compartilhados podem colocar segredos dentro do alcance do processo.
O que foi observado
A F5 Labs registrou 807 ataques agrupados por sessão e aproximadamente 32 mil eventos brutos. As requisições percorriam .env, perfis AWS e Azure, estados Terraform, configurações Serverless e variáveis de processo, além de variantes com travessia e codificação dupla.
Os scanners falsificavam User-Agents de crawlers e cabeçalhos como X-Forwarded-For. Esses sinais ajudam na triagem, mas são forjáveis. A conclusão sustentada é exploração observada e coleta direcionada, não uma contagem pública de vítimas ou tomadas de contas.
Ambientes e impactos
Previews, homologação, containers com 0.0.0.0, portas Docker publicadas, workspaces cloud e namespaces Kubernetes com Ingress merecem atenção. Em pipelines, um job pode iniciar o dev server para testes e expô-lo além do executor.
O impacto depende do que o processo lê. .env pode conter tokens e senhas; diretórios cloud podem guardar chaves; estados de infraestrutura revelam recursos e valores sensíveis. Um segredo válido e excessivamente privilegiado pode abrir repositórios, registries, pipelines ou recursos de nuvem.
Como detectar
O inventário deve procurar processos Vite, server.host, --host, portas publicadas e endpoints com /@vite/client. A porta 5173 é padrão, mas pode mudar se estiver ocupada; verificar apenas uma porta é insuficiente.
Em proxies, WAFs e balanceadores, consultas a /@fs/ com raw, import, url ou inline são prioritárias, sobretudo contra .env, .aws, .azure, terraform.tfstate ou /proc. Respostas 200 merecem investigação aprofundada.
Se houve exposição, é necessário correlacionar a janela com logs cloud, trilhas de identidade, cofres de segredos, registries, repositórios e CI/CD, buscando uso incompatível com origem, horário e ações esperadas.
Mitigação imediata
- Atualizar. Para esta CVE, usar Vite 7.3.2, 8.0.5 ou posterior suportado; em linhas anteriores, aplicar o último patch ou migrar por causa de falhas relacionadas.
- Retirar o dev server da Internet. Revisar Docker, Kubernetes, túneis, proxies, security groups e publicação de portas; para acesso remoto indispensável, usar rede privada, autenticação forte e duração curta.
- Manter
server.fs.strict, reduzirserver.fs.allowe nunca definirserver.allowedHostscomo true. Esses controles não substituem o patch. - Revogar ou rotacionar segredos possivelmente expostos, revisar privilégios e investigar uso. Preferir identidades de workload e credenciais temporárias.
- Bloquear manifests que executem vite dev em produção, testar serviços de preview, escanear secrets e expirar endpoints efêmeros automaticamente.
Prevenção no DevSecOps
Pipelines devem gerar artefatos estáticos e implantá-los em servidores adequados, não promover o dev server. Imagens de runtime não deveriam carregar ferramentas, caches e credenciais de build; volumes com segredos não devem ser montados em processos Web de desenvolvimento.
Políticas como código podem impedir LoadBalancers, Ingresses públicos e portas de desenvolvimento fora de namespaces autorizados. Corrigir a biblioteca sem remover o endpoint, ou remover o endpoint sem rotacionar uma chave já exposta, deixa o tratamento incompleto.
Conclusão
A campanha não transforma todo projeto frontend em incidente. Ela mostra como uma conveniência local pode virar rota de coleta ao cruzar a borda da rede. Alcance externo, versão vulnerável e segredos legíveis formam o risco real.
A decisão prática é direta: dev servers não devem ser serviços públicos. Atualizar, eliminar a exposição e revisar credenciais na mesma resposta reduz a chance de uma leitura local se converter em acesso indevido à nuvem ou à cadeia de desenvolvimento.
Be the first to comment