Vercel сообщил об утечке env vars клиентов через скомпрометированный Context.ai
19 апреля 2026 Vercel сообщил, что через скомпрометированный ИИ-ассистент Context.ai утекли не-sensitive переменные окружения клиентов. Разбираем цепочку атаки, даём чеклист из шести шагов и объясняем, что делает флаг sensitive.
Новости Tproger
Если у вас есть проекты на Vercel и в них хранятся API-ключи или токены без пометки «sensitive» — ротируйте их прямо сейчас. 19 апреля Vercel опубликовал, что атакующий получил доступ к части клиентских переменных окружения через скомпрометированный ИИ-инструмент Context.ai, которым пользовался один из сотрудников Vercel.
Инцидент формально небольшой — Vercel пишет про «ограниченный subset» клиентов, — но показательный. Злоумышленники всё чаще заходят в большие платформы не через уязвимости в коде, а через сторонние ИИ-интеграции, которым разработчики дают «Allow all» на Google Workspace (то есть соглашаются на все запрошенные OAuth-scopes — чтение почты, диска, календаря). Для российских разработчиков ситуация актуальна в двух сценариях: деплоите ли вы что-то на Vercel напрямую или работаете на зарубежного заказчика, у которого есть Vercel-проекты. Логика рекомендаций — «sensitive env vars + аккуратные OAuth-scopes + 2FA» — применима и к Netlify, Cloudflare Pages и любому другому хостингу с dashboard-ом.
Ключевые выводы
Инцидент Vercel 19 апреля 2026
Точка входа, что утекло, что делать
Точка входа: OAuth-токен сотрудника Vercel в Context AI Office Suite. Сотрудник выдал приложению «Allow all» на Google Workspace.
Что утекло: переменные окружения на Vercel, которые не помечены как sensitive — API-ключи, токены, DB-credentials, ключи подписи.
Что защищено: env vars с флагом sensitive, npm-пакеты Vercel (проверено совместно с GitHub, Microsoft, npm и Socket), enterprise-клиенты Context.ai на Context Bedrock — это собственная on-premise enterprise-платформа Context.ai, не AWS Bedrock.
Сколько затронуто: по данным Vercel, «ограниченный subset» клиентов получил персональное уведомление. Если письма не было — вас, скорее всего, не коснулось.
Что делать: ротировать все не-sensitive env vars, включить 2FA, пометить секреты как sensitive, проверить activity log.
Что такое «sensitive» env vars на Vercel
В Vercel у каждой переменной окружения есть чекбокс «Sensitive». Если он включён, значение переменной хранится так, что его нельзя прочитать обратно — ни в UI, ни через API. Приложение получает значение в рантайме, но никакой интерфейс на стороне Vercel не может его показать даже самому владельцу проекта. Если чекбокс выключен — значение лежит в открытом виде в панели, и разработчик (а значит, и тот, кто получил его учётку) может его увидеть.
До инцидента новые переменные по умолчанию создавались без флага sensitive — значит, часть секретов в проектах была в открытом виде в панели, даже у аккуратных команд. Польза sensitive-флага простая: даже если атакующий украл учётку разработчика и вошёл в dashboard, прочитать значения этих переменных он уже не может — значения доступны только приложению в рантайме. После инцидента Vercel сделал sensitive-флаг включённым по умолчанию и улучшил team-wide управление переменными.
Как атакующий дошёл до env vars Vercel
Из двух официальных заявлений восстанавливается такая цепочка:
- Июнь 2025. Context.ai запустил Context AI Office Suite — consumer-продукт для работы с ИИ-агентами (документы, слайды, таблицы). У Suite была функция «агенты действуют в вашем Google Workspace»: писать письма, создавать документы.
- До апреля 2026. Сотрудник Vercel подключил свой служебный Google Workspace-аккаунт к Context AI Office Suite и выдал OAuth-приложению «Allow all» — разрешил читать и модифицировать всё, что доступно в Workspace: почту, диск, календарь.
- Март 2026. Context.ai независимо обнаружил несанкционированный доступ к своему AWS-окружению. Привлекли CrowdStrike для расследования, закрыли AWS и свернули потребительский продукт.
- Апрель 2026. По данным от Vercel и внутреннего расследования Context.ai выяснил: во время инцидента были скомпрометированы OAuth-токены пользователей AI Office Suite. Один из них использовался атакующим для входа в Google Workspace сотрудника Vercel — через почту и привязанные магические ссылки атакующий добрался до панели управления Vercel.
- 19 апреля 2026. Vercel опубликовал первое уведомление об инциденте, затем раскрыл IOC и источник атаки. Context.ai выпустил параллельное заявление.
Vercel оценивает атакующего как «высокопрофессионального» — исходя из скорости работы и детального понимания внутренних систем платформы. К расследованию привлечены Mandiant и правоохранительные органы.
Индикатор компрометации (IOC)
Vercel опубликовал ID OAuth-приложения, через которое проходила атака. Администраторам Google Workspace стоит проверить, не авторизован ли этот app у кого-то из сотрудников:
Проверить можно в консоли Google Admin: Security → API controls → Third-party app access. Если app найден — отозвать все его токены, связаться с сотрудниками, у которых он был подключён, и ротировать их секреты по тому же чеклисту, что и клиентам Vercel.
Что делать клиентам Vercel
Прямой чеклист из рекомендаций Vercel. Начинать сверху, даже если уведомления от Vercel не получали — «ограниченный subset» определяется по подтверждённым фактам, а расследование ещё идёт.
- Ротировать все не-sensitive env vars — API-ключи, токены, строки подключения к БД, ключи подписи. Все значения, которые видны в интерфейсе Vercel в открытом виде, считайте потенциально утёкшими.
- Пометить секреты как sensitive. Зайдите в Settings → Environment Variables, откройте каждый секрет, включите чекбокс Sensitive. С этого момента значение нельзя будет прочитать обратно.
- Включить 2FA на всех аккаунтах команды. Authenticator-app или passkey — ссылки есть в официальном бюллетене Vercel.
- Проверить activity log проекта и команды на подозрительные действия: неожиданные деплои, смена настроек, приглашения новых членов команды. Лог доступен в dashboard и через CLI.
- Поставить Deployment Protection как минимум в режим Standard. Если использовали Deployment Protection tokens — ротировать их.
- Удалить подозрительные деплои. Если в логе есть деплой, которого вы не помните, — удалить его, даже если не уверены.
Удалить проект или аккаунт недостаточно — по словам Vercel, скомпрометированные секреты остаются валидными, пока вы их не ротируете. Сначала ротация, потом чистка.
Чему учит этот инцидент
Это не первая supply-chain атака, но она показательна двумя вещами.
Первое: сторонний ИИ-инструмент с «Allow all» на Google Workspace — это, по сути, полный доступ к почте, диску и календарю компании. Любая его компрометация превращается в компрометацию всего, что висит на SSO вокруг Google Workspace. У Vercel это привело к тому, что одна галочка сотрудника открыла доступ к production env vars целой платформы.
Второе: «encrypted at rest» — это не защита от кражи credentials из рабочей среды. Env vars всегда должны быть декодированы для запуска приложения; поэтому бекенд Vercel умеет их читать, и атакующий, получивший доступ к интерфейсу команды, тоже мог. Флаг sensitive решает именно эту задачу — делает значение нечитаемым для самого интерфейса, не для рантайма.
FAQ
Я клиент Vercel — откуда узнать, затронуло ли меня?
Vercel обещает связаться напрямую с каждым пострадавшим клиентом. Если письма от них не было — вы, скорее всего, не в затронутом subset. Но на всякий случай лучше всё равно пройти чеклист выше: ротация не-sensitive секретов не помешает и за пределами этого инцидента.
Чем sensitive env var отличается от обычного?
Обычный env var на Vercel можно открыть в dashboard и увидеть значение. Sensitive — нет: значение записывается один раз, потом доступно только приложению в рантайме, но не интерфейсу. Это защищает от сценариев, где атакующий получил доступ к учётке разработчика, но не к машине, на которой крутится приложение.
Npm-пакеты от Vercel можно использовать?
Да. Vercel совместно с GitHub, Microsoft, npm и Socket подтвердил, что ни один публикуемый компанией пакет не скомпрометирован, признаков tampering нет. Supply chain в npm чист.
Что делать, если мой аккаунт Context.ai тоже был?
Context.ai пишет, что инцидент касается только deprecated AI Office Suite (запущенного в июне 2025), но не их enterprise-продукта Context Bedrock — это on-premise платформа для корпоративных клиентов, архитектурно отделённая от consumer-инфраструктуры. Если вы были пользователем Office Suite — стоит написать на security@context.ai, отозвать все OAuth-токены, подключённые к Google Workspace, и ротировать все секреты, которые могли быть доступны через почту или документы.
Выводы
Когда один OAuth-токен может скомпрометировать dev-tools, CI-pipeline, секреты и деплой одновременно — это сигнал, что где-то в архитектуре доверия пошло не так.
Полный тред — на Hacker News: в обсуждении 858 баллов и почти 500 комментариев разбирают, как архитектура «одна OAuth-связка = доступ ко всему» стала нормой в SaaS.
После инцидента Vercel выкатил четыре продуктовых изменения, полезных и за пределами этой истории: sensitive-флаг включён по умолчанию для новых переменных, улучшено team-wide управление env vars, activity log стал информативнее и получил deep-linking по фильтрам, обновлены письма-приглашения в команду. Старые проекты это не починит автоматически — идти в Settings и помечать секреты sensitive вручную всё равно придётся.
Полный текст уведомлений — бюллетень Vercel и statement Context.ai. Обе страницы обновляются по мере расследования, стоит подписаться на уведомления или заглянуть через неделю.
