Vercel хранила Ваши секреты в незашифрованном виде и назвала это функцией

Vercel подверглась взлому. Злоумышленник находился внутри около двух месяцев до обнаружения. Он перечислил и расшифровал переменные окружения клиентов — ключи API, пароли баз данных, ключи подписи, токены — для каждого проекта, который не использовал опциональный флаг «sensitive» в Vercel.

Цепочка атаки: был скомпрометирован сторонний ИИ-инструмент Context.ai. Злоумышленник использовал эту точку опоры, чтобы перехватить аккаунт Google Workspace сотрудника Vercel. Оттуда он переместился во внутренние системы Vercel. Затем начал читать секреты.

В настоящее время данные, как сообщается, предлагаются на BreachForums за 2 миллиона долларов.

Флажок «sensitive», который не был включён по умолчанию

Вот что имеет значение.

В Vercel есть два типа переменных окружения. Обычные — они «зашифрованы в состоянии покоя», но могут быть расшифрованы и прочитаны системами Vercel. И «sensitive» — они используют дополнительное шифрование, которое, по заявлению Vercel, исключает даже внутренний доступ.

Злоумышленник мог прочитать все обычные. Защищены были только «sensitive».

Проблема: «sensitive» включалось по желанию. Не по умолчанию. Каждый разработчик, задавший DATABASE_URL или STRIPE_SECRET_KEY или JWT_SIGNING_KEY без установки флажка — а таких большинство — оставил эти значения в формате, который злоумышленник с внутренним доступом мог расшифровать.

Рекомендации Vercel после инцидента: «Включите функцию чувствительных переменных окружения для зашифрованного хранения». Перевод: шифрование, которое, как Вы предполагали, защищало Ваши секреты, на самом деле не защищало их от нас — или от любого, кто получил доступ к нашим системам.

Два месяца присутствия в системе

Первоначальная компрометация произошла в феврале 2026 года. Vercel опубликовала первый бюллетень безопасности 19 апреля. Это примерно два месяца доступа злоумышленника к внутренним системам.

Собственная команда безопасности Vercel охарактеризовала злоумышленника как «крайне сложного, судя по скорости его операций и глубокому пониманию поверхности API продукта Vercel». Когда компания, размещающая Вашу инфраструктуру, сообщает, что злоумышленник понимал их системы лучше, чем ожидалось, это должно Вас насторожить.

За эти два месяца у злоумышленника было время перечислить каждую доступную переменную окружения в затронутых клиентских проектах. Время для эксфильтрации. Время для продажи.

Цепочка поставок через OAuth

Точкой входа стал даже не собственный код Vercel. Сотрудник Vercel авторизовал Context.ai — ИИ-инструмент для повышения продуктивности — через Google OAuth. Когда Context.ai был скомпрометирован, злоумышленник унаследовал все разрешения, которые предоставляла эта OAuth-выдача.

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

Идентификатор скомпрометированного OAuth-приложения общедоступен: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com. Если Ваша организация авторизовала это приложение, отозвайте доступ немедленно.

Что следует сделать

Если Вы разворачиваете проекты на Vercel:

• Немедленно ротируйте все переменные окружения — не ждите, пока станет ясно, были ли Вы «затронуты»
• Включайте флажок sensitive для всех переменных окружения в дальнейшем
• Проведите аудит разрешений OAuth-приложений Google Workspace и отозвайте доступ ко всему, чем Вы не пользуетесь активно
• Проверьте журналы развёртываний Vercel на предмет неожиданных изменений в период с февраля по апрель 2026 года
• Проверьте нижестоящие сервисы (базы данных, платёжные провайдеры, API) на предмет несанкционированного доступа с использованием учётных данных, хранившихся в Vercel

Главный урок

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

Это и есть проблема безопасности по принципу «доверьтесь нам». Vercel шифровала Ваши переменные окружения в состоянии покоя — технически это верно. Но ключи шифрования находились у них. Когда их системы были скомпрометированы, вместе с ними оказались скомпрометированы и Ваши секреты.

Альтернатива — архитектура с нулевым знанием, при которой поставщик услуги математически не может расшифровать Ваши данные. Не «решил не делать» — не может. Никакая компрометация изнутри, никакой недобросовестный сотрудник, никакой сложный злоумышленник, живущий в Вашей инфраструктуре два месяца, не сможет прочитать то, для чего у сервера никогда не было ключей шифрования.

Vercel просит клиентов установить флажок, чтобы включить настоящее шифрование. Вопрос, который стоит задать: почему это не было единственным вариантом с самого начала?