Для: разработчиков и операторов, которые развёртывают приложения на Vercel, команд, которые хранят производственные секреты (API-ключи, учётные данные баз данных, ключи подписи) в переменных окружения, администраторов Google Workspace и всех, кто работает с PaaS (платформой, которая запускает ваши приложения за вас) по такому же принципу.
Эта статья основана на официальном бюллетене Vercel о безопасности и документации Vercel. Она не описывает методы атак и не содержит значений индикаторов компрометации (IoC).
Что пользователям Vercel делать сегодня
Проверьте, нет ли сообщения от Vercel, и продолжайте, даже если его нет
Vercel сообщает, что связалась с затронутыми клиентами напрямую и рекомендовала немедленно сменить учётные данные. В её обновлении от 22 апреля говорится, что расширенная проверка выявила небольшое число дополнительных скомпрометированных аккаунтов, которые также были уведомлены. Сначала уточните, на какие адреса приходят сообщения от Vercel (владельцы команды, контакты для выставления счетов).
Но Vercel представляет шаги ниже как передовые практики, которым нужно следовать в любом случае. Отсутствие сообщения от Vercel — не повод ничего не делать.
Составьте список переменных окружения, не помеченных как sensitive, и в первую очередь смените секреты
Vercel просит считать потенциально раскрытыми переменные окружения, которые не были помечены как sensitive, — API-ключи, токены, учётные данные баз данных, ключи подписи и т. д. — и в первую очередь сменить их.
В таблице переменных окружения на панели каждая переменная имеет метку Config (значение можно показать после сохранения) или Secret (значение нельзя показать после сохранения). Секреты, которые стоят под меткой Config, — это и есть текущий список работ. Проверьте и общие переменные уровня команды, а не только переменные проекта.
Меняйте в таком порядке: добавьте новый ключ и выполните развёртывание, затем отключите старый
Документация Vercel задаёт такой порядок смены без простоя:
- В стороннем сервисе (поставщике базы данных или API) выпустите новые учётные данные и пока сохраните старые
- Обновите переменную окружения в Vercel
- Выполните повторное развёртывание (для переменной уровня команды — каждого проекта, который её использует)
- После проверки работоспособности отключите старые учётные данные
Одно изменение переменной оставляет работающие развёртывания на старом значении, и только шаг 4 делает утёкшее значение бесполезным.
Сохраняйте новое значение как Secret
Сохраняйте созданные новые значения как Secret (только для записи). В своём бюллетене Vercel говорит, что функция sensitive защищает значения секретов от последующего чтения.
По состоянию на 30 сентября 2026 года документация указывает, что значение Secret скрывается после сохранения и меняется только при вводе нового значения, а Secret, которые раньше были доступны только для Production и Preview, теперь разрешены и в Development. О том, что куда относится, см. сравнение далее в статье.
Смените секреты до того, как удалять какие-либо проекты
Vercel прямо указывает, что удаление проектов или аккаунта не устраняет риск, поскольку утёкший секрет остаётся действительным в базе данных или API, к которым он открывает доступ. Если вы чистите старые проекты или уходите из Vercel, сначала отключите ключи у поставщика, и только потом удаляйте проекты.
Проверьте журнал активности и недавние развёртывания
Vercel рекомендует проверить журнал активности вашего аккаунта и окружений (на панели или через CLI) на предмет подозрительной активности и изучить недавние развёртывания на предмет всего неожиданного или подозрительного. Она советует удалить любое развёртывание, вызывающее сомнения. Тот же журнал используйте для поиска признаков того, что кто-то просматривал значения переменных окружения.
Установите Deployment Protection не ниже Standard и смените его токены
Vercel рекомендует установить Deployment Protection не ниже Standard и, если вы используете токены Deployment Protection, сменить их. В документации Vercel Standard описан как рекомендуемый вариант для большинства проектов: он защищает preview-URL и URL отдельных развёртываний, а текущие производственные URL остаются публичными.
Включите многофакторную аутентификацию для аккаунта Vercel
Vercel рекомендует многофакторную аутентификацию с приложением-аутентификатором или passkey. Почему они надёжнее SMS, рассказано в статье Выбор многофакторной аутентификации.
Администраторам Google Workspace: найдите OAuth-приложение, указанное в бюллетене
Vercel опубликовала идентификатор OAuth-приложения Google Workspace этого ИИ-инструмента и рекомендует администраторам Google Workspace и владельцам учётных записей Google немедленно проверить, используется ли это приложение.
По данным Vercel, это OAuth-приложение стало объектом более широкой компрометации, которая потенциально затронула сотни пользователей во многих организациях, — поэтому организации, которые не используют Vercel, тоже могут попадать в зону риска. Идентификатор берите из бюллетеня Vercel, ссылка на который есть в списке источников ниже.
Ограничьте ИИ-инструменты и OAuth-приложения, которые подключают сотрудники
По данным Vercel, злоумышленник использовал доступ к стороннему ИИ-инструменту, чтобы захватить учётную запись сотрудника в Google Workspace, а оттуда перешёл в его аккаунт Vercel.
Подключение полезного ИИ-инструмента к корпоративному аккаунту через «Войти с Google» или «Разрешить доступ к Drive» происходит каждый день во всех организациях. Ниже перечислены настройки, которые администратор Google Workspace может изменить сегодня, чтобы снизить этот риск.
Составьте список сторонних приложений, подключённых к корпоративным аккаунтам
На справочной странице Google для администраторов «Контроль доступа приложений к данным Google Workspace» сказано, что консоль администратора показывает, какие приложения получали доступ к данным организации, какие пользователи их авторизовали и какие области доступа (OAuth-scopes) запросило каждое приложение.
Выгрузите список и отметьте приложения, которые никто не может объяснить, а также приложения с правами на чтение всего Drive или Gmail.
Заблокируйте неиспользуемые приложения и сузьте права у оставшихся
На той же странице указано, что каждому приложению можно задать статус Trusted, Limited, Specific Google data или Blocked. Оставленным приложениям ограничьте доступ только до нужных им данных, а остальные заблокируйте.
Запретите сотрудникам самостоятельно подключать не настроенные приложения
Можно задать политику организации: разрешено ли пользователям авторизовать сторонние приложения, которые администратор не настроил. Разрешение только приложений, запрашивающих базовую информацию для входа, ставит проверку администратором перед каждым новым ИИ-инструментом.
Для Gmail и Drive можно также отдельно ограничить высокорисковые области доступа, например отправку писем или удаление файлов.
Отделите административные учётные записи производственной среды от учётных записей, к которым подключаются ИИ-инструменты
Это рекомендация этого сайта. В данном инциденте учётная запись Google, к которой был подключён ИИ-инструмент, стала путём в аккаунт Vercel. Людям с административными правами на производство или хостинг стоит подумать о том, чтобы не подключать пробные ИИ-инструменты к учётной записи, которой они входят в эти системы. Если инструмент всё же нужно подключить, используйте отдельную учётную запись с ограниченным доступом к бизнес-данным.
Что произошло (по бюллетеню Vercel)
Всё ниже приведено так, как указано в бюллетене Vercel о безопасности «Vercel April 2026 security incident». Vercel несколько раз обновляла бюллетень, а после 24 апреля перешла к обновлению только при наличии критически важных изменений.
19 апреля 2026
Vercel сообщает о несанкционированном доступе к отдельным внутренним системам Vercel, говорит, что привлекла экспертов по реагированию на инциденты и уведомила правоохранительные органы, и публикует идентификатор OAuth-приложения, чтобы другие организации могли проверить свою среду.19 апреля (позднее обновление)
Vercel публикует источник атаки (скомпрометированный сторонний ИИ-инструмент) и добавляет рекомендации.20 апреля
Vercel уточняет определение скомпрометированных учётных данных и добавляет рекомендации. В тот же день она заявляет, что её npm-пакеты были проверены и признаны не скомпрометированными, добавляет рекомендации по многофакторной аутентификации и выпускает улучшения продукта.22 апреля
Vercel публикует результаты расширенной проверки: небольшое число дополнительных аккаунтов, скомпрометированных в ходе этого инцидента, которые были уведомлены, а также отдельно небольшое число клиентских аккаунтов с признаками компрометации, которые, по-видимому, не связаны с этим инцидентом и получили конкретные корректирующие меры.23 апреля
Vercel дополнительно уточняет свои выводы.24 апреля
Обновлений нет. С этого момента Vercel сообщает, что будет уведомлять затронутых клиентов и обновлять бюллетень, если появятся критически важные изменения.
- Источник
- Компрометация стороннего ИИ-инструмента, которым пользовался сотрудник Vercel. OAuth-приложение этого инструмента для Google Workspace стало объектом более широкой компрометации во многих организациях
- Путь
- Захват учётной записи сотрудника в Google Workspace → аккаунт сотрудника в Vercel → окружение Vercel → перемещение по системам для перечисления и расшифровки переменных окружения
- Что было получено
- Для ограниченного круга клиентов — переменные окружения, не помеченные как sensitive (те, что расшифровываются в открытый текст)
- Дополнительные выводы
- Небольшое число дополнительных аккаунтов, скомпрометированных в ходе этого инцидента, теперь уведомлены. Отдельно — небольшое число аккаунтов с признаками компрометации, которые, по-видимому, не связаны с этим инцидентом и, судя по всему, не возникли в системах Vercel
- Не затронуто
- npm-пакеты, опубликованные Vercel (подтверждено совместно с GitHub, Microsoft, npm и одной из компаний в сфере безопасности)
- Оценка Vercel
- Vercel оценивает злоумышленника как высокоподготовленного, исходя из скорости действий и глубокого понимания поверхности API продукта Vercel. Она работает с фирмами по реагированию на инциденты, отраслевыми партнёрами и правоохранительными органами
- Изменения продукта
- Улучшение управления переменными окружения (более надёжные настройки по умолчанию, усиленные защитные механизмы, обучение внутри продукта), общий для команды обзор управления и безопасности переменных окружения, а также более удобный журнал активности
Примечание к тексту: количество не опубликовано, инструмент здесь не назван
Vercel описывает затронутых клиентов только как «ограниченный круг» и «небольшое число»; количество она не опубликовала. Этот сайт не приводит цифры, которые организация не раскрыла.
В бюллетене Vercel назван поставщик ИИ-инструмента, но в соответствии с политикой этого сайта мы называем только организацию, которая раскрыла инцидент, а другие стороны описываем по роли («сторонний ИИ-инструмент»). Чтобы проверить собственную организацию, используйте идентификатор OAuth-приложения из бюллетеня Vercel, а не название.
На каком этапе можно было предотвратить ущерб
1. Сторонний ИИ-инструмент
Его OAuth-приложение широко скомпрометировано
↓→
Полезная настройка
Администраторы ограничивают, какие приложения подключаются и с какими областями доступа
2. Учётная запись сотрудника в Google
Захвачена; использована для входа в Vercel
↓→
Полезная настройка
Без пробных инструментов на административных учётных записях производственной среды
3. Окружение Vercel
Переменные окружения перечислены
↓→
Что могут сделать клиенты
Клиенты не могут предотвратить этот шаг; утечка значений зависит от категории на шаге 4
4a. Читаемые (Config)
Расшифрованы и получены в открытом виде
4b. Только для записи (Secret)
Vercel сообщает о компрометации только 4a
Что можно хранить в Config (значения можно показать)
- Значения, безвредные при публичном доступе: публичные URL, флаги функций, уровни логирования
- Значения, которые всё равно попадают в браузер: например, всё с префиксом
NEXT_PUBLIC_ - Настройки, которые нужно читать обратно: названия регионов, имена бакетов — то, что ничего не открывает само по себе
Что должно храниться в Secret (значения нельзя показать)
- API-ключи и токены доступа: платежи, отправка писем, AI API
- Строки подключения к базам данных и пароли
- Ключи подписи и шифрования: подпись сессий и JWT, секреты для проверки webhook
- Административные учётные данные внешних сервисов: ключи доступа к облаку и подобные
Взгляд этого сайта: значения, которые можно показать позже, может прочитать и злоумышленник
Причина, по которой переменную окружения оставляют читаемой, почти всегда в том, чтобы потом можно было проверить её значение. Этот инцидент показал, что та же категория читаема для любого, кто проник в платформу. Переменные, которые Vercel сообщает как скомпрометированные, — именно эта категория.
Достаточно одной проверки: понадобится ли вам когда-нибудь читать это значение обратно на этом экране? Если нет, сделайте его Secret. Секрет, значение которого вы хотите иметь возможность посмотреть, должен храниться там, где вы его действительно храните, — в менеджере паролей или в консоли поставщика, а не в читаемой копии на платформе развёртывания.
Документация Vercel также предлагает командную политику Separate Production Secret Values, которая требует, чтобы секреты Production отличались от секретов в Preview и Development. Это ещё одна настройка, которая не даёт утёкшему ключу из preview работать в production.
Та же логика применима и к другим PaaS и CI-системам. Каждый сервис, который хранит ваши секреты в читаемом виде, становится вторым местом хранения, отдельным от того, которым вы действительно управляете. Основы того, где хранить секреты и как их разделять, описаны в статье Что делает файлы .env и API-ключи рискованными.
Цепочка компрометаций, которая началась с инструмента разработчика, также произошла в мае 2026 года с TanStack, Nx Console и GitHub. Там отправной точкой был канал распространения кода (npm-пакеты и расширение редактора), а урок о структурах, в которых один украденный ключ не может публиковать в одиночку, изложен в статье Что разработчикам проверить после цепочки TanStack, Nx Console и GitHub.
В инциденте с Vercel отправной точкой был не код, а права SaaS-сервиса, подключённого через OAuth. О случае, когда отправной точкой стал инструмент, работающий в CI, см. компрометацию цепочки поставок Trivy.
Источники (публичные данные)
Факты в этой статье взяты из следующих публичных источников. Методы атак, значения IoC и сведения, которые идентифицируют злоумышленника, не рассматриваются.
- Vercel, «Vercel April 2026 security incident» (бюллетень о безопасности, опубликован 19 апреля 2026, обновлён 24 апреля) — vercel.com
- Документация Vercel, «Sensitive environment variables» (типы Config и Secret, редакция от 28 августа 2026) — vercel.com
- Документация Vercel, «Rotating environment variables» (смена без простоя) — vercel.com
- Документация Vercel, «Deployment Protection» (Standard Protection) — vercel.com
- Справка для администраторов Google Workspace, «Контроль доступа приложений к данным Google Workspace» — knowledge.workspace.google.com
История обновлений
2026-09-30: первая версия, основанная на бюллетене Vercel о безопасности (редакция от 24 апреля) и официальной документации Vercel по состоянию на 30 сентября 2026 года. Мы обновим эту страницу, если Vercel обновит свой бюллетень.
Читайте далее
- Более новый случай на платформе для разработчиков: несанкционированный доступ к внутреннему приложению продаж WorkOS
- Где должны храниться секреты: Что делает файлы .env и API-ключи рискованными / Что такое файл .env?
- Другие инциденты, которые начались с инструментов разработчика: Цепочка TanStack, Nx Console и GitHub / Что делать пользователям CI после компрометации Trivy
- Утечки через действительные учётные данные: В 2026 году утечки происходили через действительные учётные данные
- Защита учётной записи: Выбор многофакторной аутентификации
- Не храните секреты в репозиториях: Остановите секреты до коммита с gitleaks
- Другие инциденты 2026 года: Утечки данных и кибератаки 2026 года