Un serveur Vite exposé exécute-t-il du code distant ?

Oui, tant que deux conditions sont réunies. Le serveur de développement Vite doit être joignable hors de la machine, et sa version doit encore appartenir à une plage de l’avis GHSA-p4f5-76q4-ffq7, publié le 10 novembre 2026. Une requête HTTP vers ce processus suffit. Aucun compte n’est demandé. Les paquets corrigés sont sur npm depuis le 9 novembre. Le numéro change avec la branche, et Vite 5 n’a pas de correctif sur la sienne.

Le serveur de développement est le processus lancé par vite ou vite dev pendant l’écriture du code. Il transforme les modules à la demande. Les fichiers produits par vite build, une fois servis par un autre logiciel, ne sont pas ce processus.

Ce que « exposé » veut dire ici

L’avis ne retient qu’une condition. Le serveur de développement doit être exposé explicitement au réseau, par le drapeau --host ou par l’option server.host. La page des options serveur, relue le 13 novembre 2026, fixe la valeur par défaut à localhost. Vite n’écoute alors que la boucle locale. Une autre machine du réseau ne peut pas ouvrir l’URL.

server.host réglé sur true ou sur 0.0.0.0 lève cette limite. La documentation dit que le serveur écoute alors toutes les adresses, y compris le réseau local et les adresses publiques. vite --host et vite --host 0.0.0.0 font la même chose. Une valeur 127.0.0.1 ou localhost laisse le serveur sur la machine.

export default {
  server: {
    host: true,
  },
}

Ce bloc est celui qu’il faut reconnaître, pas un réglage à ajouter. Il se trouve dans vite.config.js, vite.config.ts, ou dans le script dev du package.json, parfois écrit vite --host. Un conteneur qui publie le port, souvent 5173, vers l’extérieur, avec cette option, rend le processus joignable au-delà de l’hôte.

L’avis ne parle pas des tunnels. Une URL publique renvoyée vers le port local livre la requête même si l’écoute reste sur 127.0.0.1. La condition écrite demeure --host ou server.host. Ce qui compte, ensuite, est de savoir qui peut envoyer une requête HTTP à ce processus.

Ce que l’avis mesure, et ce qu’il ne mesure pas

La page classe l’avis critique. Le vecteur CVSS 4.0 est AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N, soit un score de base de 9,1. Le 13 novembre 2026, cette page ne donne pas d’identifiant CVE. La faiblesse retenue est CWE-116 : un identifiant pris dans l’URL est recopié dans du code généré, sans échappement. Le serveur de développement traite ensuite ce code comme le sien.

Deux effets sont nommés. Un fichier placé hors de la liste autorisée par server.fs peut être lu. Du code peut aussi s’exécuter sur la machine qui héberge le serveur. Le vecteur note une confidentialité haute et une intégrité haute, et une disponibilité nulle : l’avis ne décrit pas un arrêt du processus. AT:P rappelle que le serveur doit déjà être joignable. Limité à localhost, sans tunnel, il ne remplit pas cette condition. Le rapport est publié par sapphi-red. La page précise qu’il a été soumis avec une aide logicielle.

Où le correctif a été posé

Les journaux de Vite 6.4.6 et de Vite 7.3.8, datés du 9 novembre 2026, portent la même ligne : escape ids in resolve virtual modules. Pour Vite 8, l’avis situe le code dans le binaire Rolldown, et précise que le rapport n’est pas rattaché au dépôt Rolldown. Rolldown 1.2.18, publié le 9 novembre à 10 h 09 UTC, dit que la 1.2.17 n’a été envoyée qu’à crates.io et que npm reçoit ces changements dans la 1.2.18. Le correctif échappe les noms de modules dans les messages d’erreur du plugin de résolution. Rolldown 1.1.7, à 10 h 08 UTC le même jour, ne contient que cela. L’avis rattache Vite 8.3.7 et 8.2.5 au correctif de Rolldown 1.2.17, et Vite 8.1.7 à Rolldown 1.1.7.

Le numéro à installer dépend de la branche

Les heures sont celles du registre npm, relues le 13 novembre 2026. Installer « la dernière » sans lire la branche peut laisser un projet en 5, ou demander une 8.2.5 absente du registre.

• De 8.3.0 à 8.3.6 : 8.3.7, à 10 h 25 UTC. Le tag latest est 8.3.8, le 11 novembre à 2 h 49 UTC. Les deux package.json dépendent de rolldown en ~1.2.18. Le journal de 8.3.8 n’enlève pas cette dépendance.
• De 8.2.0 à 8.2.4 : l’avis écrit 8.2.5, absente du registre. 8.2.6 y est, à 11 h 00 UTC, avec rolldown en ~1.2.18.
• De 8.0.0 à 8.1.6 : 8.1.7, à 11 h 02 UTC, qui dépend de rolldown en ~1.1.7. Rien n’est resté sur la seule branche 8.0.
• De 7.0.0 à 7.3.7 : 7.3.8, à 11 h 01 UTC.
• De 4.0.0 à 6.4.5 : 6.4.6, à 11 h 06 UTC. Le tag previous pointe sur elle.

Le même avis couvre le paquet npm vite-plus jusqu’à 1.5.0, corrigé par 1.5.1, à 14 h 00 UTC le 9 novembre. Ses notes font passer le Vite embarqué de 8.3.5 à 8.3.7. Le tag latest, le 13 novembre, est 1.6.0, publiée le 11 novembre à 4 h 16 UTC. 1.5.1 contient aussi d’autres correctifs, hors du sujet d’ici.

npm install vite@8.3.8
npm install vite@8.2.6
npm install vite@8.1.7
npm install vite@7.3.8
npm install vite@6.4.6

Chaque commande correspond à une branche, pas à un choix libre. npm install vite@8 résout vers 8.3.8. npm install vite@8.2 résout vers 8.2.6. npm install vite@5 résout encore vers 5.4.21, qui reste dans la plage.

Vite 5.4.21 ne ferme pas l’avis

La dernière version 5 publiée sur npm est 5.4.21, le 20 octobre 2025. La dernière version 4 est 4.5.14, le 30 avril 2025. Ni l’une ni l’autre ne figure parmi les versions corrigées. Rester sur 5.4.21 laisse le projet dans la plage qui va de 4.0.0 à 6.4.5, dès lors que le serveur de développement est exposé.

Passer de 5 à 6.4.6 est une majeure, pas un correctif posé sur le lockfile. Le guide de migration de Vite 6 décrit des ruptures étrangères à cet avis. Les tests du projet restent le juge. Monter d’un coup à 8.3.8 empile plusieurs majeures. 6.4.6 est le plancher pour un projet encore en 4, 5 ou 6, pas une raison de s’y arrêter si le code peut aller plus loin.

Lire la version que le processus charge

Le numéro cité dans un tutoriel n’est pas celui du dépôt. Depuis la racine du projet, deux lectures suffisent.

npm ls vite
node -p "require('./node_modules/vite/package.json').version"

La seconde lit le paquet que Node charge ici. npm ls montre aussi les copies imbriquées : une ancienne compte si le script dev la lance. Avec pnpm, pnpm list vite tient le même rôle. Le processus déjà ouvert garde l’ancien code. Il faut l’arrêter, le relancer, puis relire la version. Le lockfile, seul, ne prouve pas que le processus a changé.

On confronte ensuite ce numéro à la plage, puis on ouvre la config. host: true, host: "0.0.0.0" ou un script vite --host répondent à la condition écrite. host: "127.0.0.1" n’y répond pas, tant qu’aucun tunnel ne publie le port.

Le dossier dist n’est pas ce serveur

vite build écrit des fichiers statiques. L’avis ne les mentionne pas. Nginx, Apache ou un hébergement qui sert le dossier dist ne font pas tourner le serveur de développement. La page des options serveur le borne : sauf mention contraire, ces options ne s’appliquent qu’au mode dev.

L’avis ne dit rien de vite preview. On ne peut donc ni le déclarer concerné, ni le déclarer hors de cause, à partir de ce seul texte. Retirer --host remet le poste hors de la condition écrite. Ce retrait ne remplace pas le paquet corrigé. Le jour où le drapeau revient, pour un téléphone sur le réseau local ou pour un conteneur, l’ancienne version retombe dans la plage de l’avis.

Questions fréquentes

Le site déjà en ligne est-il concerné ?

Pas par cet avis, s’il ne sert que le résultat de vite build et qu’aucun serveur de développement n’écoute à côté. L’avis vise le processus lancé pour développer, et seulement lorsqu’il est joignable hors de la machine.

host: localhost place-t-il le projet dans l’avis ?

La version peut être dans une plage. La condition d’exposition, non, si personne d’autre ne peut ouvrir le port. La documentation donne localhost comme défaut. La mise à jour reste le bon réflexe : elle couvre le prochain --host.

Pourquoi 8.2.5, citée par l’avis, ne s’installe-t-elle pas ?

Le 13 novembre 2026, le registre npm n’a pas de 8.2.5. Il a 8.2.6, dont la dépendance Rolldown est ~1.2.18. npm install vite@8.2 résout vers 8.2.6.

8.3.8 est-elle encore dans le correctif ?

8.3.7 est la première 8.3 citée comme corrigée. 8.3.8, publiée le 11 novembre, garde rolldown en ~1.2.18. Son journal ajoute d’autres correctifs et n’enlève pas celui-là. Le tag latest pointe sur 8.3.8.

Faut-il redémarrer après l’installation ?

Oui. Le processus déjà lancé ne recharge pas le paquet. La version à relire est celle du nouveau processus, pas seulement la ligne du lockfile.

Cet avis a-t-il un numéro CVE ?

Pas le 13 novembre 2026. La page GitHub montre le GHSA, le score 9,1 et CWE-116. La section CVE y est vide.

Relire la config avant de rouvrir le réseau

Le contrôle tient en trois lectures : la version que Node charge, la présence de --host ou de server.host, et le redémarrage après installation. Pour revoir, à côté, le JavaScript et le TypeScript qui portent ces fichiers, les parcours sont sur la page Apprentissage. Pour faire relire un serveur de développement déjà ouvert sur un réseau, le formulaire de la page Me contacter suffit.