Массовое сканирование открытых dev-серверов показало неприятную вещь: уязвимость Vite превратилась в быстрый способ вытащить облачные секреты из проектов на AWS и Azure. Для русскоязычных команд это не экзотика из чужого периметра, а вполне бытовой риск: один забытый --host в dev-контейнере — и наружу могут уехать ключи, токены и Terraform-состояния.
По данным BleepingComputer, кампания использует CVE-2026-39364 — уязвимость высокой степени опасности в Vite версий 7.1.0–7.3.2, а также в ветке 8.x до 8.0.5. Проблему раскрыли 7 апреля 2026 года. Она позволяет неаутентифицированному атакующему менять query-параметры в HTTP GET-запросе и обходить ограничения на чтение файлов, получая содержимое в открытом виде из мест, куда обычный запрос добраться не должен.
Атаки заметила F5 на своих honeypot-сенсорах. За месяц компания увидела более 800 атак и около 32 тыс. сырых событий. Механика выглядит не как тонкая ручная эксплуатация, а как массовая проверка всего, что торчит в интернет: если Vite dev server отвечает, к запросам добавляют параметры вроде ?raw, ?import&raw или ?import&url&inline. В уязвимых конфигурациях сервер не применяет deny-list-фильтрацию и отдаёт целевой файл с HTTP 200.
Главная цель — не исходники ради спортивного интереса, а секреты. Сканеры перебирают списки путей к .env, .env.production, .env.local и другим environment-файлам, ищут AWS credentials и конфиги в разных домашних директориях, резервные копии credential-файлов, Azure-токены, Terraform state и variables, serverless-конфигурации, /proc/self/environ, /proc/1/environ, /proc/self/cwd/.env и даже /etc/passwd. Если в dev-среде лежит ключ с широкими правами, атака быстро перестаёт быть проблемой фронтенд-инструмента и становится облачным инцидентом.
F5 также видит попытки traversal и варианты с кодированием, включая двойное кодирование последовательностей обхода директорий. Это похоже на попытку пройти через reverse proxy или WAF, где нормализация URL может отличаться от того, что в итоге обработает backend. Большая часть вредоносной активности, по наблюдениям компании, шла из США, Бельгии и Нидерландов. Для маскировки атакующие использовали IP-диапазоны Google Cloud, что осложняет простую фильтрацию по провайдеру: заблокировать весь крупный облачный диапазон обычно проще в презентации, чем в продакшене.
Интересная деталь: самые активные IP-адреса эксплуатировали не только CVE-2026-39364, но и другие проблемы контроля доступа в Vite — CVE-2025-30208, CVE-2025-31125 и CVE-2024-45811. CVE-2025-31125 уже отмечалась как активно эксплуатируемая. Это важный сигнал для команд, которые чинят «одну конкретную CVE» и считают задачу закрытой. В реальной кампании злоумышленник не обязан выбирать один путь: он перебирает всё, что даёт файловый доступ, особенно если цель — автоматизированный сбор секретов.
По умолчанию Vite обычно привязывается к localhost, но на практике dev-серверы часто оказываются снаружи. Причины знакомые: флаг --host для тестирования на другом устройстве, настройка server.host, неаккуратный Docker port mapping или временный стенд, который внезапно пережил свой «временный» статус. Внутри команды это может выглядеть безобидно: надо быстро показать сборку продакту, дизайнеру или QA. Снаружи это выглядит как endpoint на порту 5173, который можно сканировать пачками.
Минимальный набор действий здесь довольно приземлённый. Нужно обновить Vite до версии, где закрыты затронутые уязвимости, и проверить, нет ли dev-серверов, доступных из интернета. Отдельно F5 рекомендует блокировать доступ к порту 5173, фильтровать подозрительные запросы к /@fs/ и не полагаться на User-Agent поисковых роботов как на признак безвредности. Среди источников атак компания выделяет адреса 34.14.15[.]105, 34.16.200[.]129 и 34.11.196[.]206 — их можно добавить в blocklist, но это скорее первая заплатка, чем защита.
Если уязвимый Vite был публично доступен, считать секреты «возможно скомпрометированными» — не паранойя, а рабочая гигиена. Ротация должна затронуть всё, до чего мог дотянуться процесс: AWS access keys, Azure-токены, service principal secrets, переменные окружения CI/CD, ключи к хранилищам и Terraform backend. Заодно стоит проверить права этих ключей: если dev-токен может читать production-бакеты или управлять инфраструктурой, проблема не в Vite, а в модели доступа.
Уязвимость Vite в этой истории ценна не сложностью эксплуатации, а тем, что бьёт по привычной серой зоне между локальной разработкой и интернетом. Чем больше команд собирает фронтенд в контейнерах, поднимает preview-окружения и шарит dev-серверы наружу, тем чаще инструменты разработки становятся частью внешнего периметра. Похоже, следующий этап зрелости для DevSecOps — инвентаризировать не только продакшен-сервисы, но и всё, что разработчики подняли «на пять минут» и забыли выключить.