В августе 2026 года специалисты F5 Labs обнаружили автоматизированное массовое сканирование доступных из интернета серверов разработки Vite. Злоумышленники искали системы с уязвимостью CVE-2026-39364, сведения о которой опубликовали в апреле 2026 года. Проблема получила высокий уровень опасности и оценку 8,2 по шкале CVSS: для атаки не нужны ни учётная запись, ни предварительная авторизация.
Ошибка позволяет обойти ограничения server.fs.deny с помощью параметров запроса ?raw, ?import&raw или ?import&url&inline. Атакующий отправляет HTTP GET-запрос к /@fs/, указывает путь к закрытому файлу и добавляет один из этих параметров. Vite обрабатывает обращение, но не применяет правило запрета. В результате сервер может вернуть содержимое файла открытым текстом с кодом HTTP 200, словно запрос был совершенно обычным.
Для эксплуатации должны совпасть три условия. Сервер разработки Vite доступен по сети из-за флага --host либо настройки ; нужный файл находится в каталоге, разрешённом через server.fs.allow; его имя или путь при этом подпадает под шаблон в server.fs.deny. По умолчанию Vite слушает localhost, поэтому сам по себе наружу не торчит. Опасность появляется после явного включения сетевого доступа или из-за неверного проброса портов контейнера Docker.
Сканеры охотятся за конфигурациями и учётными данными Amazon Web Services (AWS), профилями Microsoft Azure, API-секретами, паролями баз данных и административными ключами облачных сред. В списке целей встречаются terraform.tfstate, serverless.yml, файлы .env и сертификаты .crt. Утечка состояния Terraform особенно неприятна: там могут лежать параметры инфраструктуры, адреса ресурсов и чувствительные значения, оставленные провайдерами или модулями.
Отдельная серия запросов направлена к /etc/passwd, /proc/self/environ, /proc/1/environ и /proc/self/cwd/.env. Последний путь, по оценке F5 Labs, выдаёт хорошее знание реальных схем развёртывания. Он позволяет получить активный .env относительно рабочего каталога запущенного процесса, не угадывая абсолютный путь приложения. То есть сканирование рассчитано не на случайную находку одного файла, а на быстрое восстановление контекста работающего сервиса.
Чтобы запросы выглядели привычнее, злоумышленники подставляют User-Agent известных поисковых и ИИ-роботов: Googlebot, ClaudeBot компании Anthropic, GPTBot и OAI-SearchBot компании OpenAI, PerplexityBot и Amazonbot. Доверять такому заголовку нельзя: клиент задаёт его самостоятельно, а сходство с легитимным ботом ещё ничего не доказывает.
В заголовках X-Forwarded-For и X-Real-IP также указываются поддельные адреса, среди примеров F5 Labs — 34.94.237[.]62 и 104.28.219[.]193. Такой приём может запутать журналы и обойти наивную фильтрацию по IP, если прокси без проверки принимает присланные клиентом значения. Источник соединения следует определять по данным доверенного балансировщика, а не по произвольному заголовку из внешнего запроса.
Заметная доля вредоносной активности шла из США, Бельгии, Нидерландов, Сингапура и Тайваня. Часто использовались диапазоны Google Cloud Platform, особенно 34.x и 35.x. Облачные адреса смешиваются с нормальным трафиком и потому плохо подходят для грубой блокировки: запрет целого диапазона способен задеть законные сервисы, не остановив сканеры надолго.
Практическая защита начинается с удаления Vite-сервера разработки из публичного контура. Нужно проверить --host, , правила Docker и публикацию портов, затем установить исправленную версию Vite согласно апрельскому бюллетеню 2026 года. Одних шаблонов server.fs.deny недостаточно. В журналах стоит искать обращения к /@fs/ с параметрами обхода, запросы к перечисленным системным путям, необычные ответы HTTP 200 и сочетания «ботового» User-Agent с подозрительными X-Forwarded-For или X-Real-IP.
Если сервер уже был доступен извне, простого обновления мало. Следует считать потенциально раскрытыми ключи AWS, профили Azure, API-токены, пароли баз данных, облачные административные данные, сертификаты и секреты из .env, terraform.tfstate и serverless.yml. Их нужно отозвать или заменить, проверить облачные журналы на неизвестные входы и операции, а также выяснить, какие файлы реально мог прочитать процесс Vite в пределах server.fs.allow.
Изображение носит иллюстративный характер
Ошибка позволяет обойти ограничения server.fs.deny с помощью параметров запроса ?raw, ?import&raw или ?import&url&inline. Атакующий отправляет HTTP GET-запрос к /@fs/, указывает путь к закрытому файлу и добавляет один из этих параметров. Vite обрабатывает обращение, но не применяет правило запрета. В результате сервер может вернуть содержимое файла открытым текстом с кодом HTTP 200, словно запрос был совершенно обычным.
Для эксплуатации должны совпасть три условия. Сервер разработки Vite доступен по сети из-за флага --host либо настройки ; нужный файл находится в каталоге, разрешённом через server.fs.allow; его имя или путь при этом подпадает под шаблон в server.fs.deny. По умолчанию Vite слушает localhost, поэтому сам по себе наружу не торчит. Опасность появляется после явного включения сетевого доступа или из-за неверного проброса портов контейнера Docker.
Сканеры охотятся за конфигурациями и учётными данными Amazon Web Services (AWS), профилями Microsoft Azure, API-секретами, паролями баз данных и административными ключами облачных сред. В списке целей встречаются terraform.tfstate, serverless.yml, файлы .env и сертификаты .crt. Утечка состояния Terraform особенно неприятна: там могут лежать параметры инфраструктуры, адреса ресурсов и чувствительные значения, оставленные провайдерами или модулями.
Отдельная серия запросов направлена к /etc/passwd, /proc/self/environ, /proc/1/environ и /proc/self/cwd/.env. Последний путь, по оценке F5 Labs, выдаёт хорошее знание реальных схем развёртывания. Он позволяет получить активный .env относительно рабочего каталога запущенного процесса, не угадывая абсолютный путь приложения. То есть сканирование рассчитано не на случайную находку одного файла, а на быстрое восстановление контекста работающего сервиса.
Чтобы запросы выглядели привычнее, злоумышленники подставляют User-Agent известных поисковых и ИИ-роботов: Googlebot, ClaudeBot компании Anthropic, GPTBot и OAI-SearchBot компании OpenAI, PerplexityBot и Amazonbot. Доверять такому заголовку нельзя: клиент задаёт его самостоятельно, а сходство с легитимным ботом ещё ничего не доказывает.
В заголовках X-Forwarded-For и X-Real-IP также указываются поддельные адреса, среди примеров F5 Labs — 34.94.237[.]62 и 104.28.219[.]193. Такой приём может запутать журналы и обойти наивную фильтрацию по IP, если прокси без проверки принимает присланные клиентом значения. Источник соединения следует определять по данным доверенного балансировщика, а не по произвольному заголовку из внешнего запроса.
Заметная доля вредоносной активности шла из США, Бельгии, Нидерландов, Сингапура и Тайваня. Часто использовались диапазоны Google Cloud Platform, особенно 34.x и 35.x. Облачные адреса смешиваются с нормальным трафиком и потому плохо подходят для грубой блокировки: запрет целого диапазона способен задеть законные сервисы, не остановив сканеры надолго.
Практическая защита начинается с удаления Vite-сервера разработки из публичного контура. Нужно проверить --host, , правила Docker и публикацию портов, затем установить исправленную версию Vite согласно апрельскому бюллетеню 2026 года. Одних шаблонов server.fs.deny недостаточно. В журналах стоит искать обращения к /@fs/ с параметрами обхода, запросы к перечисленным системным путям, необычные ответы HTTP 200 и сочетания «ботового» User-Agent с подозрительными X-Forwarded-For или X-Real-IP.
Если сервер уже был доступен извне, простого обновления мало. Следует считать потенциально раскрытыми ключи AWS, профили Azure, API-токены, пароли баз данных, облачные административные данные, сертификаты и секреты из .env, terraform.tfstate и serverless.yml. Их нужно отозвать или заменить, проверить облачные журналы на неизвестные входы и операции, а также выяснить, какие файлы реально мог прочитать процесс Vite в пределах server.fs.allow.
