Vite : des scans massifs ciblent directement les fichiers .env

La Cyber Security Agency of Singapore a alerté le 17 septembre 2026 sur l’exploitation active de CVE-2026-39364 contre des serveurs de développement Vite exposés au réseau. Selon l’alerte de la CSA, cette faille permet à un attaquant distant et non authentifié de contourner server.fs.deny et de récupérer des fichiers système ou de configuration normalement interdits.

L’alerte du 17 septembre ne signifie pas que tout projet utilisant Vite est accessible à distance. Le risque concerne un serveur de développement vulnérable rendu joignable sur le réseau, par exemple avec --host, server.host, un port Docker publié ou un proxy exposé ; une application statique déjà compilée, sans serveur Vite accessible, ne présente pas cette même surface d’attaque.

Une attaque à grande échelle, pas 32 000 victimes établies

Le caractère massif du phénomène repose sur un balayage automatisé observé en août 2026. La télémétrie de F5 Labs dénombre 807 attaques regroupées par session et 32 010 événements classés comme tentatives de fuite d’informations, contre 1 732 événements Vite pendant les trois mois précédents. Ces mesures décrivent des requêtes reçues par des capteurs, non 32 010 serveurs compromis ni autant de fichiers effectivement volés.

Les requêtes visaient directement .env, .env.local et .env.production, mais aussi /proc/self/environ, des fichiers d’identifiants AWS, des jetons Azure, terraform.tfstate, terraform.tfvars et des états Serverless. Elles combinaient des chemins /@fs/ avec des paramètres tels que ?raw ou ?import&raw ; certaines employaient une traversée de répertoires doublement encodée pour tenter de franchir les contrôles d’un proxy intermédiaire.

Une analyse de la Cloud Security Alliance publiée le 16 septembre confirme que les listes de chemins privilégient les secrets cloud et les états d’infrastructure plutôt que des contenus web ordinaires. Les observations publiques établissent donc une campagne de balayage et des tentatives d’extraction, mais elles ne fournissent pas de bilan vérifié des intrusions réussies.

Versions vulnérables et conditions à réunir

L’avis de sécurité du projet Vite classe comme vulnérables les versions 7.1.0 à 7.3.1 et 8.0.0 à 8.0.4, corrigées respectivement dans 7.3.2 et 8.0.5. Pour Vite-plus, les versions jusqu’à 0.1.15 incluse sont touchées et la correction se trouve dans 0.1.16.

Trois conditions doivent coïncider : le serveur de développement est explicitement exposé au réseau, le fichier ciblé se trouve dans un répertoire autorisé par server.fs.allow et une règle server.fs.deny est censée en bloquer la lecture. Des paramètres de requête particuliers peuvent alors faire renvoyer le fichier avec un statut HTTP 200, là où la requête ordinaire devrait recevoir un refus.

Arbre de décision pour qualifier l’exposition

La version est-elle concernée ? Vite 7.1.0–7.3.1, Vite 8.0.0–8.0.4 et Vite-plus 0.1.15 ou antérieur imposent une mise à jour. Une version située hors de ces plages n’est pas concernée par cette faille précise, sans être nécessairement exempte d’autres vulnérabilités.
Le serveur était-il accessible au-delà de localhost ? Il faut rechercher --host dans les scripts, server.host dans la configuration, les ports de conteneurs publiés sur une interface externe, ainsi que les ingress, tunnels et règles de proxy. Le port 5173 est courant, mais Vite peut écouter sur un autre port.
Existe-t-il des traces d’exploitation ? Les journaux doivent être examinés pour les chemins /@fs/, les noms .env, /proc/self/environ, .aws/credentials ou terraform.tfstate, et les paramètres raw, import, url ou inline. Une réponse 200 associée à une requête de ce type est plus préoccupante qu’un refus 403 et doit conduire à vérifier le contenu réellement renvoyé.
Les journaux permettent-ils de conclure ? Leur silence n’écarte pas l’exposition si le proxy ne conservait pas la chaîne de requête, si la rétention a expiré ou si le serveur était directement publié. Une version vulnérable joignable pendant la campagne doit alors être traitée comme une compromission possible.

Mettre à jour ne suffit pas si un secret a pu sortir

La correction ferme le contournement, mais ne révoque pas un identifiant déjà récupéré. Pour une instance probablement exposée, l’inventaire doit suivre ce que le processus Vite pouvait lire :

variables sensibles des fichiers .env, notamment clés d’API, mots de passe de base de données et secrets de session ;
clés et profils AWS présents dans les répertoires accessibles ;
identifiants et jetons Azure ;
secrets contenus dans les états Terraform, les fichiers tfvars et les configurations Serverless ;
certificats et clés privées correspondant aux motifs bloqués par server.fs.deny.

La séquence défensive consiste à supprimer l’accès réseau public, installer Vite 7.3.2, Vite 8.0.5 ou Vite-plus 0.1.16 selon la branche, puis révoquer et remplacer les secrets potentiellement lisibles. Le blocage de /@fs/ et des paramètres connus au niveau d’un proxy ou d’un pare-feu applicatif peut réduire l’exposition pendant la remédiation, mais ne remplace pas la mise à jour.

Ce que les données publiques ne permettent pas encore de mesurer

Le balayage massif, les familles de fichiers recherchées et les plages de versions vulnérables sont documentés. Aucun des éléments publics examinés ne donne cependant le nombre d’organisations effectivement compromises, la quantité de secrets exfiltrés ou la part de ces identifiants ensuite utilisée.

Le diagnostic repose donc sur trois faits propres à chaque environnement : une version touchée, un serveur de développement réellement joignable et des fichiers sensibles dans son périmètre de lecture. Lorsque ces conditions sont réunies, des requêtes /@fs/ réussies renforcent l’hypothèse d’une divulgation et justifient la rotation des secrets sans attendre un bilan global de la campagne.