безопасность

Взлом Vercel: AI-инструмент стал входом в инфраструктуру

Инцидент Vercel показывает, как сторонний AI-инструмент и OAuth-доступ превращаются в supply-chain риск для разработки.

По состоянию на 20 апреля 2026 года взлом Vercel выглядит не как очередная история про украденный пароль, а как предупреждение для команд, которые быстро подключают сторонние ИИ-инструменты к рабочим аккаунтам. Vercel подтвердила несанкционированный доступ к части внутренних систем и связала исходную точку атаки с Context.ai, сторонним AI tool, которым пользовался сотрудник компании.

Главная деталь: атакующий, по версии Vercel, получил доступ через скомпрометированное Google Workspace OAuth-приложение, взял под контроль аккаунт сотрудника и смог зайти в некоторые окружения Vercel. После этого он получил доступ к переменным окружения, которые не были помечены как sensitive. Секреты, отмеченные как sensitive, Vercel описывает как нечитаемые после создания; на момент публикации компания пишет, что не видит доказательств доступа к таким значениям.

Официальный бюллетень Vercel об инциденте апреля 2026 года. Источник: Vercel.

Что подтвердил Vercel

В официальном бюллетене Vercel пишет, что инцидент затронул определённые внутренние системы компании. Первоначально компания выявила ограниченную группу клиентов с скомпрометированными учётными данными, связалась с ними напрямую и рекомендовала немедленную ротацию. Если клиент не получил уведомление, Vercel на момент обновления бюллетеня не видит оснований считать, что его Vercel credentials или персональные данные были скомпрометированы.

Компания также подчёркивает, что сервисы остаются работоспособными, расследование продолжается, к нему подключены Mandiant, другие специалисты по кибербезопасности, отраслевые партнёры и правоохранительные органы. Отдельно Vercel опубликовала индикатор компрометации для Google Workspace:

OAuth App: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com

Это важно не только клиентам Vercel. В бюллетене сказано, что Google Workspace OAuth app стороннего ИИ-инструмента мог быть частью более широкой компрометации и потенциально затрагивать сотни пользователей в разных организациях. Иными словами, риск выходит за пределы одной платформы для деплоя.

Что пока остаётся неподтверждённым

Новостные издания сообщали, что человек, заявивший связь с ShinyHunters, пытался продавать данные Vercel. The Verge пишет о публикации имён сотрудников, адресов электронной почты и временных меток активности. BleepingComputer приводит заявления о продаже исходного кода, ключей доступа, данных баз и внутренних деплоев, но отдельно отмечает: подлинность части материалов и скриншотов не была независимо подтверждена.

Для редакционной точности это ключевое различие. Подтверждённая часть истории: был несанкционированный доступ к внутренним системам Vercel, входной канал связан с Context.ai и Google Workspace OAuth, а несекретные переменные окружения могли быть прочитаны. Неподтверждённая часть: масштаб продаваемых данных, принадлежность атакующего к конкретной группе и полный состав украденных токенов.

Почему это история про AI tooling

Сторонние ИИ-инструменты всё чаще получают доступ к рабочим почтам, документам, репозиториям, тикетам, логам и внутренним панелям. Для команды это удобно: агенту или ассистенту дают контекст, и он быстрее пишет код, анализирует ошибки или готовит отчёты. Для атакующего это тоже удобно: один OAuth grant может стать дорогой внутрь компании.

Это близко к классическим supply-chain атакам, но с новым слоем. В истории с взломом LiteLLM на PyPI риск пришёл через пакет в цепочке разработки. В случае Vercel фокус смещается на SaaS-интеграции и OAuth-доступы: инструмент может быть легитимным, но его токены и разрешения становятся частью поверхности атаки.

Отсюда практический вывод: политика безопасности для ИИ-инструментов должна быть такой же строгой, как для CI/CD, менеджеров секретов и production-доступов. Если AI tool видит почту, документы или внутренние панели, это уже не «просто удобный плагин».

Что проверить администраторам прямо сейчас

Первый шаг: Google Workspace. Администратору стоит проверить, встречается ли указанный Vercel OAuth client ID в событиях OAuth Token Audit. Документация Google показывает, что такие события можно получать через Reports API с applicationName=token, а среди параметров есть client_id, app_name, scope и события authorize, activity, request, revoke.

Второй шаг: Vercel. Компания рекомендует проверить activity logs по аккаунтам и окружениям, просмотреть последние деплои, удалить подозрительные, включить Deployment Protection минимум на Standard и ротировать Deployment Protection tokens, если они используются.

Третий шаг: переменные окружения. Если в Vercel были API keys, database credentials, signing keys или другие секреты, но они не были помечены как sensitive, Vercel советует считать их потенциально раскрытыми и ротировать в приоритетном порядке. Это не значит, что каждый такой секрет точно украден. Это значит, что его уже нельзя считать надёжным.

Vercel описывает sensitive environment variables как значения, которые нельзя прочитать после создания. Источник: Vercel Docs.

Мини-чеклист для команды разработки

Проверьте Google Workspace OAuth apps по client ID из бюллетеня Vercel.
Отзовите подозрительные OAuth grants и повторно выдайте доступ только нужным приложениям.
Ротируйте Vercel environment variables, если в них были секреты без sensitive-метки.
Проверьте недавние деплои, webhooks, интеграции с GitHub, Linear и другими рабочими системами.
Разделите ИИ-инструменты по уровню доступа: чтение документации, доступ к репозиторию, доступ к production-данным должны быть разными классами риска.
Добавьте сторонние AI tools в процесс vendor review: владелец, scopes, срок действия токенов, журналирование и процедура отзыва доступа.

Этот же подход пригодится не только Vercel-клиентам. История MuleRun AI swarm уже показывала, что массовые аккаунты и автоматизация быстро превращаются в риск платформенного уровня. А в материале про GitHub Copilot и opt-out мы разбирали похожий вопрос с другой стороны: что именно уходит во внешнюю систему и кто контролирует этот поток.

Что делать с ИИ-инструментами после этого инцидента

Запрещать все ИИ-инструменты бессмысленно: они уже встроены в разработку, поддержку и аналитику. Но у каждой интеграции должен быть владелец, понятный набор разрешений и срок жизни. Если инструмент нужен на неделю для аудита, ему не нужен постоянный доступ к Workspace. Если агент анализирует ошибки, ему не нужен доступ к секретам. Если ассистент работает с кодом, это не повод открывать ему production-панели.

Взлом Vercel ценен не громким брендом, а схемой атаки. Слабым звеном оказалась не обязательно сама платформа, а связка «сторонний AI tool - OAuth - рабочий аккаунт - внутренние окружения». Для 2026 года это уже типовой сценарий риска: ИИ ускоряет работу, но одновременно расширяет цепочку доверия.

Пока расследование продолжается, безопасная позиция простая: подтвердить отсутствие указанного OAuth app, проверить журналы, ротировать потенциально затронутые секреты и перевести переменные окружения с секретами в sensitive-режим. Остальные заявления вокруг исходного кода, npm/GitHub tokens и ShinyHunters стоит держать в категории claims до прямого подтверждения.