Массовое сканирование Vite добралось до того самого слоя инфраструктуры, который многие команды до сих пор считают «временным» и «только для разработки»: открытых dev-серверов. Исследователи F5 Labs зафиксировали в августе 2026 года автоматизированную кампанию, в которой злоумышленники вытаскивали из таких серверов облачные ключи AWS и Azure, конфиги и state-файлы инфраструктуры, сообщает The Hacker News.
В центре истории — CVE-2026-39364, уязвимость Vite с оценкой 8.2 по CVSS. Ошибка позволяет неаутентифицированному атакующему обойти ограничения на доступ к файлам через манипуляции с query-параметрами. Проще говоря, файл вроде .env, который должен быть закрыт правилом server.fs.deny, в ряде условий всё равно можно получить обычным HTTP-запросом.
Vite описал проблему ещё в апреле 2026 года. Сценарий выглядит неприятно буднично: к запросу добавляют параметры вроде ?raw, ?import&raw или ?import&url&inline, после чего dev-сервер отдаёт содержимое файла с HTTP 200. Для атаки должны совпасть три условия: Vite dev server явно открыт в сеть через --host или server.host, чувствительный файл лежит в разрешённой области server.fs.allow, а запрет в server.fs.deny формально должен был этот файл блокировать.
Главная беда не в самой технике обхода, а в том, что Vite часто используют в средах, где рядом лежит всё нужное для быстрого запуска проекта: переменные окружения, API-ключи, параметры базы, cloud credentials, конфиги деплоя. Dev-сервер по умолчанию привязан к localhost, но разработчики нередко включают --host для тестирования с телефона, демонстрации коллеге, работы в контейнере или CI-окружении. Если Docker-порты проброшены слишком щедро, «локальная удобная штука» внезапно становится интернет-сервисом.
По данным F5 Labs, атакующие били по endpoint /@fs/ и подставляли пути к чувствительным файлам. Среди целей были переменные окружения, AWS credentials, резервные копии AWS-конфигураций, Azure profiles, terraform.tfstate, serverless.yml, а также системные файлы вроде /etc/passwd, /proc/self/environ и /proc/1/environ. Отдельно исследователи выделили попытки читать /proc/self/cwd/.env: такой путь позволяет добраться до активного .env относительно процесса, не угадывая абсолютный путь приложения.
Это важная деталь для разработчиков и платформенных команд. Атака не требует сложной эксплуатации с цепочкой zero-day и кастомным шеллкодом. Это массовое сканирование Vite: найти открытый dev server, попробовать набор типовых путей, притвориться приличным ботом, забрать секреты, уйти дальше. Если в terraform.tfstate или env-файле есть ключи с широкими правами, инцидент уже выходит за пределы фронтенд-сборщика и превращается в проблему облачной безопасности.
Маскировка тоже без особой романтики, зато практичная. Запросы использовали фальшивые User-Agent, имитируя Googlebot, ClaudeBot, GPTBot, PerplexityBot, OAI-SearchBot и Amazonbot. В заголовки X-Forwarded-For и X-Real-IP подставлялись поддельные адреса, чтобы путать журналы и обходить примитивные списки доступа по IP. Значительная часть активности, по наблюдениям F5 Labs, шла из США, Бельгии, Нидерландов, Сингапура и Тайваня; также использовались диапазоны Google Cloud Platform, включая адреса 34.x и 35.x.
Для бизнеса вывод неприятный, но полезный: dev-инструменты больше нельзя считать безопасными только потому, что они «не прод». В реальности именно они часто оказываются менее защищёнными, хуже мониторятся и содержат больше секретов, чем публичное приложение. Командам стоит проверить, где Vite dev server слушает не только localhost, закрыть внешнюю доступность, обновить уязвимые версии, пересмотреть server.fs.allow и server.fs.deny, а после обнаружения открытого инстанса — ротировать ключи, а не просто чинить конфиг.
Для русскоязычных команд, которые активно используют Vite в React-, Vue- и Svelte-проектах, это хороший повод пройтись по Docker Compose, preview-окружениям и внутренним стендам. Массовое сканирование Vite показывает знакомый сдвиг: атакующие всё чаще охотятся не за «главным приложением», а за рыхлой инженерной обвязкой вокруг него. Следующий спор в командах будет не о том, удобен ли --host 0.0.0.0, а о том, кто отвечает за секреты, когда удобство разработки внезапно стало внешним периметром.