Aller au contenu
InYourGeek
visiteur@inyourgeek — console
compléter historique ouvrirhelp
EN
Sécurité· 3 min de lecture

Des scans massifs visent les serveurs Vite exposés pour voler vos secrets

Une campagne de scan automatisé cible les serveurs de développement Vite accessibles depuis Internet pour en extraire des identifiants AWS et Azure. Les fichiers visés sont ceux que personne ne pense exposer : `.env`, clés cloud, états Terraform.

Illustration sombre d'une salle de serveurs la nuit : un ordinateur portable ouvert et oublié sur une étagère métallique diffuse une lueur ambrée, et de fins filaments lumineux s'échappent de son écran vers l'obscurité environnante.

Le site Bleeping Computer a publié le 14 septembre 2026 le détail d’une campagne de scan massif visant les serveurs de développement Vite joignables depuis Internet. L’objectif des attaquants n’est pas de prendre le contrôle des machines, mais d’en extraire des secrets : identifiants AWS, jetons d’accès Azure, fichiers de configuration.

Un mois d’observation, plus de 800 attaques

Les données proviennent des capteurs de pots de miel de l’éditeur F5, qui a relevé plus de 800 attaques et environ 32 000 événements bruts sur un mois. L’essentiel de l’activité malveillante observée provient des États-Unis, de Belgique et des Pays-Bas, les attaquants s’appuyant sur des plages d’adresses Google Cloud pour brouiller leur origine. Trois adresses ressortent comme les plus actives et sont recommandées au blocage : 34.14.15.105, 34.16.200.129 et 34.11.196.206.

Ces éléments reposent sur une source unique — le compte rendu de Bleeping Computer relayant l’analyse de F5 — et ne sont pas corroborés ailleurs à ce stade.

Une faille qui sert les fichiers en clair

La campagne exploite CVE-2026-39364, une vulnérabilité de gravité élevée divulguée le 7 avril, qui permet de contourner les contrôles d’accès aux fichiers de Vite. Sont concernées les versions 7.1.0 à 7.3.2, ainsi que la branche 8.x avant la 8.0.5.

Le mécanisme ne demande aucune authentification : il suffit d’ajouter certains paramètres à une requête HTTP GET — ?raw, ?import&raw ou ?import&url&inline — pour que le serveur cesse d’appliquer son filtrage par liste de refus et renvoie le fichier demandé en clair, avec un code 200. F5 relève aussi des variantes d’encodage et de traversée de répertoires, y compris des séquences doublement encodées, apparemment destinées à passer la normalisation des reverse proxies et des pare-feu applicatifs.

Les adresses les plus actives tirent également parti d’autres défauts de contrôle d’accès de Vite : CVE-2025-30208, CVE-2025-31125 — signalée comme activement exploitée — et CVE-2024-45811.

Ce que cherchent les listes de mots

Une fois la lecture de fichiers obtenue, le scan déroule des listes étendues : .env, .env.production, .env.local et autres fichiers d’environnement ; fichiers d’identifiants AWS dans plusieurs répertoires personnels possibles ; fichiers de configuration et sauvegardes d’identifiants AWS ; identifiants et jetons d’accès Azure ; états et fichiers de variables Terraform ; configurations et états serverless. S’y ajoutent /proc/self/environ, /proc/1/environ, /proc/self/cwd/.env et /etc/passwd.

Vite écoute sur localhost, sauf quand on lui dit le contraire

Par défaut, le serveur de développement de Vite n’écoute que sur la machine locale. Les chercheurs de F5 rappellent que ce sont les développeurs qui l’exposent, en passant l’option --host, en renseignant server.host, ou par une redirection de ports Docker mal réglée. Le problème n’est donc pas la commande npm run dev en elle-même, mais la distance entre ce qu’elle est conçue pour faire et l’endroit où elle finit par tourner.

Les mesures recommandées tiennent en quatre gestes : mettre Vite à jour vers la dernière version, qui corrige les failles exploitées ; bloquer l’accès au port 5173 ; bloquer les requêtes /@fs/ suspectes ; ne pas accorder de confiance aux User-Agent qui se présentent comme des robots d’indexation. Et si un serveur Vite non corrigé a été exposé publiquement, renouveler tous les secrets à portée du système vulnérable.

Un serveur de développement est un outil de confort, prévu pour une machine qui ne parle qu’à elle-même. Ouvert sur Internet, il devient un service que personne n’a conçu pour l’être — et qui répond quand même.

Sources (1)

PartagerXLinkedInFacebookBluesky

Article rédigé avec l'assistance d'une IA à partir des sources citées, puis relu et validé avant publication par Sébastien Soulier.