Para construir el entorno de vulnerabilidad localmente desde cero, primero cree un proyecto con create-vite:

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:

Finalmente, inicie el entorno:

Por supuesto, también puede usar directamente la carpeta vuln-env de este repositorio, ejecutar npm install y luego npm run dev.

3. Reproducción de vulnerabilidades

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:

POC de CVE-2025-31125:

El contenido leído está codificado en base64; después de decodificarlo, se obtiene el contenido original del archivo.

POC de CVE-2025-31486:

El POC mencionado en el aviso que utiliza una ruta relativa es el siguiente:

x representa la ruta del proyecto local. El POC de prueba local es:

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.

4. Análisis del código fuente

4.1 CVE-2025-30208

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:

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.

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().

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().

Después de algunas operaciones de asignación, se cargan los complementos según el valor de id. El orden de carga de los complementos es el siguiente:

La causa de CVE-2025-30208 es que la URL cuidadosamente construida por el atacante se analiza y procesa, pasando la verificación if (rawRE.test(id)) del complemento assetPlugin, y se envía a la función fsp.readFile(), lo que provoca la lectura de archivos locales.

4.2 CVE-2025-31125

La causa de CVE-2025-31125 es que la URL se analiza y cumple la condición id.endsWith(".wasm?init") del complemento wasmHelperPlugin, se envía a la función fileToUrl$1(), cumple la condición inlineRE$2.test(id) y luego se envía a la función fsp.readFile(), lo que provoca la lectura de archivos locales.

4.3 CVE-2025-31486

CVE-2025-31486 es muy similar a CVE-2025-31125. En el diagrama de análisis de CVE-2025-31125, se puede ver que en la función fileToDevUrl() solo hay dos declaraciones if que contienen expresiones regulares. El bloque if que contiene inlineRE$2.test(id) es el punto de activación de CVE-2025-31125, y el bloque if siguiente con svgExtRE.test(id) es el punto de activación de CVE-2025-31486.

El método de explotación con rutas relativas elude la verificación de ensureServingAccess(). Cuando la url ingresa a la función isFileServingAllowed(), primero se le aplica cleanUrl() en fsPathFromUrl() para eliminar ?# y el contenido posterior. Para la URL en el POC, ocurre la siguiente transformación:

Luego, la Url ingresa a isFileLoadingAllowed() y se verifica mediante isUriFilePath(), y luego pasa la verificación de isParentDirectory().

5. Corrección de vulnerabilidades

5.1 CVE-2025-30208

Del commit de corrección 262b5ec, se puede ver que la solución oficial es limpiar las ? superfluas al final del parámetro. Entonces, cuando el parámetro se enfrenta a if ((rawRE.test(...) || urlRE.test(...)) && !ensureServingAccess(...)), la coincidencia exitosa de rawRE.test() permite que se ingrese normalmente a ensureServingAccess(), verificando así si el servicio permite el acceso, evitando la lectura no autorizada causada por el cortocircuito de la expresión lógica antes de la corrección.

5.2 CVE-2025-31125

Del commit de corrección 5967313, se puede ver que se agregó la expresión regular inlineRE. De esta manera, ?inline=1.wasm?init será coincidente por la expresión regular y luego ingresará normalmente a ensureServingAccess() para determinar si el servicio es accesible.

5.3 CVE-2025-31486

Del commit de corrección 62d7e81, se puede ver que la corrección oficial incluye principalmente dos partes. La primera parte es agregar una nueva coincidencia de expresión regular svgRE para manejar la elusión mediante .svg.

La segunda parte, para manejar la lectura mediante rutas relativas, limpia el parámetro id antes de pasarlo a svgRe.test(), de modo que el parámetro que participa en la detección de svgRe.test() sea consistente con el parámetro utilizado en la concatenación de file.