Vite-Lücke CVE-2026-39364: Cloud-Schlüssel aus Dev-Servern

F5 Labs hat am 11. September 2026 eine groß angelegte Scan-Kampagne dokumentiert, die gezielt nach im Internet erreichbaren Vite-Entwicklungsservern sucht und dort .env-Dateien, AWS-Schlüssel, Azure-Profile und Terraform-State-Dateien im Klartext abzieht. Ausgenutzt wird CVE-2026-39364, eine Umgehung der Dateisperre server.fs.deny im Vite-Dev-Server. Gepatcht ist das seit dem 6. April 2026 in Vite 7.3.2 und Vite 8.0.5.

Betroffen sind ausschließlich Umgebungen mit einem laufenden, ans Netz gebundenen Vite-Dev-Server in Version 7.1.0 bis 7.3.1 oder 8.0.0 bis 8.0.4. Nicht betroffen sind reine Produktionsbuilds, statisch ausgelieferte Bundles und jedes Setup ohne laufenden Dev-Server. Wer heute handeln muss: alle Teams, die Vite-Dev-Server in Docker, auf Test-VMs, in Staging-Umgebungen oder per --host erreichbar betreiben. Für alle anderen reicht eine Bestandsprüfung im nächsten Wartungsfenster.

Was ist passiert?

F5 Labs berichtet in der Sensor-Intel-Serie für August 2026 von 807 sitzungsgruppierten Angriffen und rund 32.000 Einzelereignissen, die auf exponierte Vite-Instanzen zielten. Das ist laut F5 ein deutlicher Anstieg gegenüber dem bisherigen Hintergrundrauschen. Die Meldung wurde am 15. September 2026 von The Hacker News aufgegriffen.

Der Vite-Dev-Server stellt über die interne Route /@fs/ Dateien aus dem Host-Dateisystem bereit, damit Module während der Entwicklung nachgeladen werden können. Sensible Pfade werden über die Deny-Liste server.fs.deny blockiert, standardmäßig unter anderem .env und Zertifikatsdateien. Genau diese Prüfung greift bei CVE-2026-39364 nicht mehr, sobald bestimmte Query-Parameter an die URL angehängt werden.

Laut dem offiziellen GitHub Security Advisory GHSA-v2wj-q39q-566r reicht es aus, Anfragen mit ?raw, ?import&raw oder ?import&url&inline zu versehen. Der Server normalisiert den Pfad, verliert dabei den Deny-Listen-Abgleich und liefert die Datei mit HTTP 200 im Klartext zurück. Eine Authentifizierung ist nicht nötig.

Die beobachteten Scanner arbeiten dabei nicht mit einem einzelnen Pfad, sondern mit umfangreichen Wortlisten. F5 nennt unter anderem .env, .env.local, .env.production, /root/.aws/credentials, /home/ubuntu/.aws/credentials, terraform.tfstate, terraform.tfvars, serverless.yml, .azure/accessTokens.json sowie /proc/self/environ und /proc/self/cwd/.env. Der letzte Pfad ist bemerkenswert: er liest die aktive Umgebungsdatei relativ zum laufenden Prozess, ohne dass der Angreifer den absoluten Anwendungspfad kennen muss.

Zur Tarnung setzen die Anfragen gefälschte User-Agent-Header ein, die große Crawler und KI-Bots imitieren, darunter Googlebot, ClaudeBot, GPTBot, PerplexityBot, OAI-SearchBot und Amazonbot. Zusätzlich werden X-Forwarded-For und X-Real-IP mit erfundenen Werten gefüllt, um IP-basierte Zugriffslisten zu umgehen und die Logauswertung zu erschweren. Ein Teil der Scans nutzt doppelt kodierte Path-Traversal-Sequenzen mit %252f, um Normalisierungsroutinen in Reverse Proxies und Web Application Firewalls zu überlisten.

Wer ist betroffen?

Das Advisory nennt drei Bedingungen, die gleichzeitig erfüllt sein müssen. Fehlt eine davon, ist die Anwendung nach Herstellerangabe nicht angreifbar.

Der Vite-Dev-Server wird ausdrücklich ans Netz gebunden, per --host oder über die Option server.host. Eine falsch gesetzte Docker-Portfreigabe hat laut F5 denselben Effekt.
Die sensible Datei liegt innerhalb der über server.fs.allow erlaubten Verzeichnisse.
Die Datei wird durch ein Muster in server.fs.deny blockiert, also gerade der Fall, auf den man sich verlassen wollte.

Die betroffenen Versionsbereiche laut Advisory:

Vite-Zweig	Betroffene Versionen	Erste gepatchte Version	Release-Datum Patch
8.x	8.0.0 bis 8.0.4	8.0.5	6. April 2026
7.x	7.1.0 bis 7.3.1	7.3.2	6. April 2026

Ausdrücklich nicht betroffen sind: fertige Produktionsbuilds aus vite build, statisch über Nginx, Apache, Caddy oder ein CDN ausgelieferte Bundles, Vite-Installationen ohne laufenden Dev-Server sowie Dev-Server, die ausschließlich an localhost gebunden sind. Das ist der Standardzustand von Vite. Wer nichts an der Bindung geändert hat und keine Container-Portfreigabe nach außen aufgezogen hat, ist aus dem Internet nicht erreichbar.

Wichtig für die Einordnung: Vite ist Bestandteil unzähliger Frontend-Projekte auf Basis von Vue, React, Svelte und Astro. Die Verbreitung des Werkzeugs ist also hoch, die Zahl der tatsächlich exponierten Dev-Server ist es nicht. Die Lücke wird erst durch die Fehlkonfiguration gefährlich.

Wie kritisch ist das?

Der Angriffspfad ist ein unauthentifizierter Datenabfluss, keine Remote Code Execution. Es gibt keine direkte Codeausführung durch diese Lücke. Kritisch wird es durch die Art der abgezogenen Daten: Wer eine .env mit AWS-Schlüsseln oder eine terraform.tfstate mit Cloud-Zugangsdaten verliert, verliert damit potenziell die Kontrolle über die dahinter liegende Infrastruktur. Der zweite Schritt ist dann keine Lücke mehr, sondern ein regulärer Login mit gültigen Schlüsseln.

Die Bewertungen der Quellen weichen ab, das sollte man kennen:

GitHub Security Advisory: CVSS 4.0 mit Score 8.2, Einstufung hoch, Vektor AV:N/AC:L/AT:P/PR:N/UI:N/VC:H.
NVD führt parallel eine CVSS-3.1-Bewertung mit 7.5 (hoch), Vektor AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N.
F5 Labs nennt im Bericht 7.5 und ordnet die Lücke CWE-200 zu. Das Advisory selbst führt CWE-180 und CWE-284.

Alle drei Bewertungen landen im Bereich hoch. Die Unterschiede ergeben sich aus der CVSS-Version, nicht aus einer inhaltlichen Uneinigkeit.

CVE-2026-39364 steht nach den vorliegenden Angaben von F5 nicht im CISA-KEV-Katalog. Von den mit ausgenutzten Altlücken ist laut F5 lediglich CVE-2025-31125 dort gelistet. Das ändert die Dringlichkeit für exponierte Systeme nicht: Der Trick mit dem Query-String ist trivial reproduzierbar, das Advisory enthält einen vollständigen Proof of Concept, und die Scans laufen messbar.

F5 beobachtete parallel Signaturen älterer Vite-Umgehungen, darunter CVE-2025-30208, CVE-2025-31125 und CVE-2024-45811. Dieselben Quell-IPs erzeugten Treffer über mehrere CVEs hinweg, dazu 103 Ereignisse gegen die Next.js-Middleware-Lücke CVE-2025-29927. Das deutet auf eine Scanner-Bibliothek hin, die mehrere Frameworks gleichzeitig abklopft, nicht auf einen Spezialangriff gegen Vite.

Geografisch entfielen laut F5 17.297 Ereignisse auf die USA, 4.407 auf Belgien, 4.011 auf die Niederlande, 2.842 auf Singapur und 1.994 auf Taiwan. Die Quell-IPs liegen überwiegend in Google-Cloud-Bereichen (34.x und 35.x), also auf gemieteter Infrastruktur. Eine Zuordnung zu einer benannten Angreifergruppe nimmt F5 nicht vor, und auch S-EDV kann hier keine belegen.

Was sollten Admins jetzt tun?

Erstens: Bestand und Version prüfen. In jedem Frontend-Projekt die eingesetzte Vite-Version ermitteln. npm ls vite zeigt auch transitive Abhängigkeiten, die über ein Framework-Starterkit hereingekommen sind. Die Lockfile ist die verbindliche Quelle, nicht der Wunschbereich in package.json.
Zweitens: Patchstand herstellen. Auf 7.3.2 beziehungsweise 8.0.5 oder neuer aktualisieren. Der aktuelle Stand des Repositorys ist 8.3.0, veröffentlicht am 10. September 2026 (abgerufen am 16. September 2026 über die GitHub-API).
Drittens: Exposition beenden. Das ist der eigentliche Fehler und wichtiger als der Patch. Kein Vite-Dev-Server gehört ins Internet. --host aus Startskripten und CI-Aufrufen entfernen, server.host in der Konfiguration zurücknehmen, Docker-Portmappings von 0.0.0.0:5173 auf 127.0.0.1:5173 ziehen.
Viertens: Von außen gegenprüfen. Die Standardports 5173 (Dev) und 4173 (Preview) von einem externen Host aus testen, zusätzlich Cloud-Security-Groups und Firewall-Regeln durchsehen. Ein Reverse Proxy, der versehentlich einen Dev-Upstream veröffentlicht, ist der zweithäufigste Weg nach draußen.
Fünftens: Logs auswerten. In Proxy- und Webserver-Logs nach Anfragen auf /@fs/ suchen, insbesondere in Kombination mit ?raw, %252f oder Bot-User-Agents. HTTP 200 auf einem solchen Pfad ist ein Treffer, kein Fehlalarm.
Sechstens: Bei Verdacht alle Secrets als kompromittiert behandeln. Wenn ein exponierter Dev-Server mit anfälliger Version lief, ist der Inhalt der .env als offengelegt zu betrachten, auch ohne Logbeweis. Rotieren, nicht hoffen. Dazu gehören AWS-Access-Keys, Azure-Tokens, Datenbankpasswörter, API-Schlüssel Dritter und Signaturgeheimnisse.
Siebtens: Cloud-Audit-Logs prüfen. AWS CloudTrail und Azure Activity Log auf ungewohnte Regionen, neu erstellte IAM-Benutzer, neue Access-Keys und Zugriffe zu untypischen Zeiten durchsehen. Der Zeitraum sollte mindestens August 2026 bis heute abdecken.
Achtens: Härtung nachziehen. Secrets aus Repositories und Container-Images heraushalten, .env-Dateien konsequent in .gitignore führen und Entwicklungsumgebungen netzseitig von Produktion trennen.
Neuntens: Backup der Terraform-States prüfen. State-Dateien enthalten häufig Zugangsdaten im Klartext. Wer sie offengelegt hat, muss die dort referenzierten Geheimnisse ebenfalls rotieren und künftig ein Remote-Backend mit Verschlüsselung nutzen.

Für die Versionsprüfung genügen zwei Befehle:

# Installierte Vite-Version inklusive transitiver Abhaengigkeiten anzeigen
npm ls vite

# Gegenprobe direkt in der Lockfile, falls npm ls unvollstaendig ist
grep -A 2 '"node_modules/vite"' package-lock.json

Die Erreichbarkeitsprüfung erfolgt von einem Host außerhalb des eigenen Netzes, nicht vom Entwicklungsrechner selbst:

# Standardports des Dev- und Preview-Servers von aussen testen
nmap -Pn -p 5173,4173 ihre-externe-adresse.example

# Lokale Bindungen kontrollieren, 0.0.0.0 ist hier das Warnsignal
ss -tlnp | grep -E '5173|4173'

# Docker-Portfreigaben pruefen
docker ps --format '{{.Names}}	{{.Ports}}'

Für die Logsuche nach dem beschriebenen Muster:

# Zugriffe auf die @fs-Route mit Bypass-Parametern finden
grep -E '/@fs/.*(\?raw|import&raw|%252f)' /var/log/nginx/access.log

# Nur die Treffer mit HTTP 200 herausfiltern
grep -E '/@fs/' /var/log/nginx/access.log | awk '$9 == 200'

Einordnung für Unternehmen

Für kleine und mittlere Unternehmen ist an dieser Meldung weniger die CVE interessant als das Muster dahinter. Entwicklungswerkzeuge sind selten für den Betrieb im offenen Netz gebaut. Vite bindet sich bewusst an localhost, und die Deny-Liste ist eine zusätzliche Absicherung, keine Zugangskontrolle. Sobald ein Dev-Server öffentlich erreichbar ist, hängt die Sicherheit an einer einzigen Filterfunktion. Bricht die, liegen die Zugangsdaten offen.

Typische Wege in die Exposition kennen wir aus der Praxis: ein Entwickler startet den Server mit --host, um vom Tablet zu testen, und das Startskript bleibt. Ein Docker-Compose-Eintrag bekommt 5173:5173 statt 127.0.0.1:5173:5173. Eine Cloud-Security-Group wird für einen Test geöffnet und nicht geschlossen. Ein Reverse Proxy erhält eine Wildcard-Route auf den Entwicklungs-Upstream. Keiner dieser Schritte fühlt sich beim Ausführen wie ein Sicherheitsvorfall an.

Der zweite Punkt betrifft die Schadenshöhe. Ein offengelegter Cloud-Schlüssel ist qualitativ etwas anderes als eine offengelegte Konfigurationsdatei. Er erlaubt legitim aussehende Zugriffe, die in Logs nicht als Angriff auffallen. Deshalb ist die Rotation nach einem möglichen Zugriff keine Vorsichtsmaßnahme, sondern der eigentliche Sanierungsschritt. Wer nur patcht und die Schlüssel behält, hat die Lücke geschlossen und den Zugang offen gelassen.

Organisatorisch lohnt sich eine einfache Regel: Entwicklungs- und Testumgebungen erhalten grundsätzlich keine öffentliche IP und keine Portfreigabe. Wer von unterwegs testen muss, nutzt ein VPN oder einen authentifizierten Tunnel. Das kostet einmal Einrichtungsaufwand und nimmt eine ganze Klasse von Vorfällen dauerhaft aus dem Risikoprofil.

Zum Projektstand: Das Vite-Repository auf GitHub verzeichnet 82.846 Sterne, steht unter MIT-Lizenz und hatte am 16. September 2026 den letzten Push am selben Tag. Die aktuelle stabile Version ist 8.3.0 vom 10. September 2026. Das Projekt reagiert also sichtbar zügig, die Patches lagen am Tag der Advisory-Veröffentlichung vor.

Passende Anleitungen auf S-EDV

Gitleaks im Docker-Container als Secret-Scanner: findet Zugangsdaten in Repositories und Commits, bevor sie in einer .env auf einem Server landen.
Docker Compose absichern mit Secrets, Healthchecks und Non-Root: zeigt unter anderem, wie Portfreigaben und Secrets in Compose-Dateien korrekt gesetzt werden.
VPS absichern und härten mit UFW, SSH-Keys und Fail2ban: schließt offene Ports auf Test- und Entwicklungsservern konsequent ab.

Was ist passiert?

Wer ist betroffen?

Wie kritisch ist das?

Was sollten Admins jetzt tun?

Einordnung für Unternehmen

Passende Anleitungen auf S-EDV

Quellen

Weiter lesen

Cisco Secure Email Gateway: CVE-2026-76461 wird aktiv ausgenutzt, Root-Befehle per E-Mail

Smart Glasses im Unternehmen: Hamburger Prüfbericht schränkt die DSGVO-Haushaltsausnahme ein

Revolut gab Kundendaten nach gefälschter Behördenanfrage heraus