Vite is a frontend tooling framework for JavaScript.

CVE-2026-39364 is an unauthenticated file-read bypass in the Vite development server. By appending query parameters like ?raw??, ?import&raw, or ?import&url&inline to HTTP requests, an attacker can circumvent server.fs.deny rules and retrieve files that should be blocked — most critically .env files containing cloud credentials (AWS keys, Azure tokens), TLS certificates, and Terraform state. Affected versions are Vite 7.1.0 through 7.3.1 and 8.0.0 through 8.0.4, fixed in 7.3.2 and 8.0.5 respectively. The exploit is trivially simple: a single crafted GET request with no authentication required.

The vendor's HIGH / 7.5 rating is directionally correct but slightly generous for most enterprise environments. The CVSS vector scores this as a clean network-reachable, no-auth, no-interaction confidentiality breach — and that's technically accurate. However, the vulnerability only fires on the Vite dev server, not production builds. The dev server must be network-exposed via the --host flag or equivalent config, which is an anti-pattern in any mature deployment. That said, the F5 Labs August 2026 honeynet data showing 32,000+ scanning events and 807 grouped attack sessions proves this anti-pattern is widespread enough to matter. The active exploitation keeps this firmly in HIGH territory despite the narrow attack surface.

Why this verdict

• Active exploitation confirmed: F5 Labs documented 32,000+ scanning events in August 2026, a ~18x increase over the prior 3-month baseline. Attackers are systematically harvesting AWS keys, Azure tokens, and Terraform state from exposed Vite dev servers. This is not theoretical.
• Trivial exploit complexity: The attack is a single unauthenticated HTTP GET request with a query parameter appended. No tooling, no chaining, no special conditions beyond network reachability. Nuclei template has been public since April 2026.
• Role multiplier: (a) *Low-value role* — developer workstation running vite dev locally: not reachable, no impact. (b) *Typical role* — staging/preview server with --host in a cloud VPC: reachable only internally, moderate impact if .env has real secrets. (c) *High-value role* — CI/CD build environment or cloud-hosted dev server accidentally exposed to the internet with production .env secrets or cloud IAM credentials on disk: blast radius extends from host → cloud account → potentially fleet-scale via Terraform state or IAM escalation. The high-value role is plausible but represents a minority of Vite installations (estimated <5%), which keeps this at HIGH rather than CRITICAL.
• Friction — dev server only: Production Vite deployments use vite build and serve static assets through nginx/CDN/S3. The dev server is a development-time tool. Exploiting this requires the anti-pattern of exposing a dev server to the network, which limits the reachable population significantly.
• Friction — default config is safe: Vite binds to localhost by default. The --host flag or server.host: '0.0.0.0' must be explicitly set, meaning exposure is an opt-in misconfiguration rather than a default-vulnerable state.

Why not higher?

CRITICAL would require the affected component to be canonically deployed in a high-value role (identity provider, domain controller, hypervisor, network edge). Vite is a frontend build tool whose dev server is explicitly not intended for production use. The high-value CI/CD exposure scenario exists but represents a small fraction (<5%) of the installed base. The vulnerability is also confidentiality-only with no code execution, limiting the direct blast radius to file reads.

Why not lower?

Active mass-scanning campaigns documented by F5 Labs in August 2026 prove real-world exploitation is occurring at scale. The exploit is trivially simple (single GET request, no auth), PoCs and Nuclei templates are widely available, and the stolen data (cloud credentials) enables devastating lateral movement into cloud infrastructure. Downgrading to MEDIUM would understate the operational risk for any organization that might have even one accidentally exposed Vite dev server.

1. Audit and kill exposed Vite dev servers immediately — Search network logs, cloud security groups, and Kubernetes ingress rules for anything listening on port 5173 (or common alternatives) that responds with Vite signatures. Terminate or firewall-restrict these within 3 days per the noisgate mitigation SLA for HIGH. Use nuclei -t CVE-2026-39364.yaml -l targets.txt to scan your perimeter.
2. Block /@fs/ paths with query parameters at the WAF/reverse proxy — If you must expose a Vite dev server temporarily (e.g., for QA preview environments), add a WAF rule denying any request matching /@fs/ with ?raw, ?import, or ?url query parameters. Deploy within 30 days.
3. Migrate secrets out of .env files into a secret manager — Even after patching, .env files on disk are a persistent risk. Move all credentials to HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault. This eliminates the high-value payload attackers are targeting.
4. Rotate all credentials that may have been exposed — If any Vite dev server was internet-facing while running a vulnerable version, assume .env contents and any readable credentials are compromised. Rotate AWS keys, Azure tokens, database passwords, and API keys immediately.
5. Enforce localhost-only binding in CI/CD and development configs — Add server.host: 'localhost' to vite.config.ts and lint CI/CD pipeline definitions to reject --host 0.0.0.0 or equivalent. This prevents future re-exposure.

Run this on any host where you suspect Vite dev servers may be running, or from an auditor workstation against a list of target IPs/hostnames. No special privileges needed — it just makes HTTP requests. Example: bash check_cve_2026_39364.sh http://devserver.internal:5173

#!/usr/bin/env bash\n# CVE-2026-39364 Vite server.fs.deny bypass checker\n# Usage: bash check_cve_2026_39364.sh <BASE_URL>\n# Example: bash check_cve_2026_39364.sh http://localhost:5173\n# Requires: curl\n# Exit codes: 1=VULNERABLE, 0=PATCHED, 2=UNKNOWN\n\nset -euo pipefail\n\nBASE_URL=\"${1:-}\"\nif [ -z \"$BASE_URL\" ]; then\n  echo \"Usage: $0 <BASE_URL>\"\n  echo \"Example: $0 http://localhost:5173\"\n  exit 2\nfi\n\n# Remove trailing slash\nBASE_URL=\"${BASE_URL%/}\"\n\necho \"[*] Testing CVE-2026-39364 against $BASE_URL\"\n\n# Test payloads that bypass server.fs.deny\nPAYLOADS=(\n  \"/@fs/.env?raw??\"\n  \"/@fs/.env?import&raw\"\n  \"/@fs/.env?import&url&inline\"\n)\n\nVULNERABLE=0\nREACHABLE=0\n\nfor payload in \"${PAYLOADS[@]}\"; do\n  URL=\"${BASE_URL}${payload}\"\n  echo \"[*] Testing: $URL\"\n  HTTP_CODE=$(curl -s -o /dev/null -w \"%{http_code}\" --connect-timeout 5 --max-time 10 \"$URL\" 2>/dev/null || echo \"000\")\n  \n  if [ \"$HTTP_CODE\" = \"000\" ]; then\n    echo \"    [-] Connection failed\"\n    continue\n  fi\n  \n  REACHABLE=1\n  \n  if [ \"$HTTP_CODE\" = \"200\" ]; then\n    # Verify response body is not empty/error page\n    BODY=$(curl -s --connect-timeout 5 --max-time 10 \"$URL\" 2>/dev/null)\n    if [ -n \"$BODY\" ] && ! echo \"$BODY\" | grep -qi \"<!DOCTYPE\"; then\n      echo \"    [!] HTTP 200 with file content returned — VULNERABLE\"\n      VULNERABLE=1\n      break\n    fi\n  else\n    echo \"    [+] HTTP $HTTP_CODE (blocked or not found)\"\n  fi\ndone\n\nif [ \"$VULNERABLE\" -eq 1 ]; then\n  echo \"\"\n  echo \"VULNERABLE — CVE-2026-39364: server.fs.deny bypass confirmed\"\n  exit 1\nelif [ \"$REACHABLE\" -eq 0 ]; then\n  echo \"\"\n  echo \"UNKNOWN — could not reach Vite dev server at $BASE_URL\"\n  exit 2\nelse\n  echo \"\"\n  echo \"PATCHED — server.fs.deny bypass payloads were blocked\"\n  exit 0\nfi

Sources

1. GitHub Advisory GHSA-v2wj-q39q-566r
2. F5 Labs — Mass Scanning for Exposed Vite Endpoints
3. SecurityOnline — Vite CVE-2026-39364 Exploited
4. Nuclei Template — CVE-2026-39364.yaml
5. GBHackers — Mass Scanning Targets Exposed Vite Servers
6. CyberSecurityNews — Vite Servers Under Attack
7. Red Hat Security Advisory