На этом этапе версия Vite в сгенерированном package.json может содержать символ ^ (например, "vite": "^6.2.0"); её необходимо вручную изменить на точный номер версии (например, "vite": "6.2.0"), а затем выполнить:

Наконец, просто запустите окружение:

Конечно, можно также напрямую использовать папку vuln-env из этого репозитория: после npm install просто выполните npm run dev.

3. Воспроизведение уязвимости

Для удобства все три уязвимости воспроизводились на версии 6.2.0. Выполните npm run dev и дождитесь запуска окружения.

POC для CVE-2025-30208:

POC для CVE-2025-31125:

Прочитанное содержимое закодировано в base64; после декодирования можно получить исходное содержимое файла.

POC для CVE-2025-31486:

POC для чтения через относительный путь, упомянутый в уведомлении, выглядит следующим образом:

x обозначает путь к локальному проекту; локальный тестовый POC выглядит следующим образом:

Можно заметить, что POC в основном делятся на два типа: те, которым не требуется добавлять HTTP Header, обязательно содержат ?import&. Пока оставим это без пояснений — объяснение будет дано на этапе анализа исходного кода.

4. Анализ исходного кода

4.1 CVE-2025-30208

Для анализа исходного кода требуется отладка; здесь проект отлаживается через VSCode. Содержимое файла launch.json следующее:

Судя по официальному исправлению, было усилено условие if в функции transformMiddleware, которое проверяет формат URL и определяет, разрешён ли доступ к сервису. Поставим точку останова в функции transformMiddleware и проследим процесс разбора запроса.

Поскольку в созданном проекте есть только скомпилированные JS-файлы, просто выполним поиск ключевого слова функции по всем файлам и добавим точку останова.

Запустим POC — точка останова успешно сработала в целевой функции. Видно, что после присвоения некоторых переменных процесс вызова входит в функцию viteTransformMiddleware; после проверки того, является ли метод запроса GET и является ли запрос корневым каталогом или иконкой, URL через removeTimestampQuery теряет завершающий ?.

С помощью cleanUrl() получается URL без параметров запроса; в этот момент значением withoutQuery является "/@fs/c:/windows/win.ini", поэтому выполнение не входит в блок кода if (!isSourceMap). Затем с помощью publicDirInRoot проверяется, настроен ли каталог статических ресурсов в корне проекта, а url.startsWith(publicPath) проверяет, начинается ли запрошенный URL с настроенного публичного пути (например, /public/). Когда оба условия выполняются одновременно, вызывается warnAboutExplicitPublicPathInUrl(url) для выдачи предупреждения. Обычно это означает, что разработчик мог ошибочно добавить публичный путь повторно. URL не соответствует условиям, поэтому соответствующий блок кода также пропускается. Результаты rawRE.test(url) и urlRE.test(url) равны False, поэтому результат ensureServingAccess() не проверяется, а результат логического выражения сразу устанавливается в False, и блок кода пропускается. В следующей проверке if URL соответствует регулярному выражению, определённому ImportQueryRE, и входит в блок кода if; URL через функцию removeImportQuery() преобразуется в /@fs/c:/windows/win.ini?raw и передаётся в функцию transformRequest().

В условии if, проверяющем isJSRequest(url), видно, что дополнительно проверяется, равно ли значение HTTP-заголовка sec-fetch-dest значению script; если да, то проверка также проходит. Именно поэтому, как упоминалось ранее, POC в основном делятся на два типа: добавление HTTP Header и ?import& — оба нужны для прохождения проверки if. (На самом деле пройти проверку можно и другими способами, например через isHTMLProxy(url) -> /@fs/c:/windows/win.ini?html-proxy&raw??)

После обработки параметров, проверки окружения, проверки ключа кэша и обнаружения повторных запросов выполнение входит в функцию doTransform​().

После проверки действительности кэша URL /@fs/c:/windows/win.ini?raw разбирается и получается ID c:/windows/win.ini?raw​, после чего выполнение входит в функцию loadAndTransform().

После аналогичных операций присваивания на основе значения id подключаются плагины. Порядок загрузки плагинов показан ниже:

Причина возникновения CVE-2025-30208 заключается в том, что специально сконструированный злоумышленником URL после разбора и обработки проходит проверку if (rawRE.test(id)) в плагине assetPlugin, а затем передаётся в функцию fsp.readFile(), что приводит к чтению локальных файлов.

4.2 CVE-2025-31125

Причина возникновения CVE-2025-31125 в том, что после разбора URL удовлетворяет условию id.endsWith(".wasm?init") в плагине wasmHelperPlugin, передаётся в функцию fileToUrl$1(), а после удовлетворения inlineRE$2.test(id) — в функцию fsp.readFile(), что приводит к чтению локальных файлов.

4.3 CVE-2025-31486

CVE-2025-31486 очень похожа на CVE-2025-31125. Из схемы анализа CVE-2025-31125 видно, что в функции fileToDevUrl() всего два оператора if с проверкой регулярных выражений: блок if с inlineRE$2.test(id) — это место срабатывания CVE-2025-31125, а следующий сразу за ним блок if с svgExtRE.test(id) — место срабатывания CVE-2025-31486.

А метод эксплуатации через относительный путь обходит проверку ensureServingAccess(). После того как URL входит в функцию isFileServingAllowed(), сначала cleanUrl() из fsPathFromUrl() удаляет ?# и всё, что идёт после него. Тогда с URL из POC произойдут следующие изменения:

Затем URL проходит проверку в isUriFilePath() внутри isFileLoadingAllowed(), а после этого — проверку isParentDirectory().

5. Исправление уязвимости

5.1 CVE-2025-30208

Судя по исправляющему коммиту 262b5ec, официально принятый способ исправления заключается в удалении лишнего ? в конце параметра. Тогда при проверке if ((rawRE.test(...) || urlRE.test(...)) && !ensureServingAccess(...)) параметр благодаря успешному совпадению rawRE.test() сможет нормально войти в ensureServingAccess(), чтобы проверить, разрешён ли доступ к сервису. Это устраняет несанкционированное чтение, вызванное замыканием логического выражения до исправления.

5.2 CVE-2025-31125

Судя по исправляющему коммиту 5967313, официально было добавлено регулярное выражение inlineRE. Тогда ?inline=1.wasm?init будет сопоставлено с регулярным выражением и нормально войдёт в ensureServingAccess() для проверки, разрешён ли доступ к сервису.

5.3 CVE-2025-31486

Судя по исправляющему коммиту 62d7e81, официальное исправление в основном состоит из двух частей. Первая часть — добавление сопоставления с регулярным выражением svgRE для обработки обхода через .svg.

Вторая часть — для обработки чтения через относительный путь параметр id очищается и только затем передаётся в svgRe.test(), чтобы параметр, участвующий в проверке svgRe.test(), совпадал с параметром, участвующим в конкатенации file.