Vercel зберігала ваші секрети у відкритому вигляді й назвала це функцією

Vercel зазнала порушення безпеки. Зловмисник перебував у системі приблизно два місяці до виявлення. Він перелічив і розшифрував змінні середовища клієнтів — ключі API, паролі до баз даних, ключі підпису, токени — для кожного проєкту, який не використовував необов'язковий прапорець "sensitive" у Vercel.

Ланцюжок атаки: було скомпрометовано сторонній AI-інструмент Context.ai. Зловмисник скористався цим, щоб перехопити обліковий запис Google Workspace співробітника Vercel. Звідти він перемкнувся на внутрішні системи Vercel. Після цього почав читати секрети.

Зараз дані нібито пропонують на BreachForums за 2 мільйони доларів.

Прапорець "sensitive", який не був типовим

Ось та частина, яка має значення.

Vercel має два типи змінних середовища. Звичайні — вони «зашифровані на диску», але можуть бути розшифровані й прочитані системами Vercel. І «конфіденційні» (sensitive) — вони використовують додаткове шифрування, яке, за словами Vercel, унеможливлює навіть внутрішній доступ.

Зловмисник міг прочитати всі звичайні. Захищеними були лише «конфіденційні».

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

Рекомендації Vercel після порушення: "Enable the sensitive environment variable feature for encrypted storage." Іншими словами: шифрування, яке, як ви вважали, захищало ваші секрети, насправді не захищало їх від нас або від будь-кого, хто потрапив у наші системи.

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

Початкове проникнення сталося в лютому 2026 року. Свій перший бюлетень з безпеки Vercel оприлюднила 19 квітня. Це приблизно два місяці, коли зловмисник мав доступ до внутрішніх систем.

Власна команда безпеки Vercel описала зловмисника як "highly sophisticated based on their operational velocity and in-depth understanding of Vercel's product API surface". Коли компанія, яка розміщує вашу інфраструктуру, каже, що зловмисник розумів їхні системи краще, ніж очікувалося, це варте уваги.

Протягом цих двох місяців зловмисник мав час перелічити всі доступні змінні середовища в уражених проєктах клієнтів. Час на вивантаження даних. Час на продаж.

Ланцюжок постачання через OAuth

Точкою входу навіть не був власний код Vercel. Співробітник Vercel надав доступ Context.ai — AI-інструменту для продуктивності — через Google OAuth. Коли Context.ai було скомпрометовано, зловмисник успадкував усі дозволи, які надавав цей OAuth-доступ.

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

Ідентифікатор скомпрометованої програми OAuth є загальнодоступним: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com. Якщо ваша організація надала доступ цій програмі, відкличте його зараз.

Що вам слід зробити

Якщо ви розгортаєте на Vercel:

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

Реальний урок

Архітектура Vercel зберігала секрети клієнтів так, що внутрішній доступ міг їх розшифрувати. Компанія пропонувала сильніший варіант, але не зробила його типовим. Протягом двох місяців ніхто не помітив, що зловмисник читає ці секрети.

Ось у чому проблема безпеки на засадах «повірте нам». Vercel шифрувала ваші змінні середовища на диску — технічно це правда. Але ключі розшифрування були в компанії. Коли їхні системи було скомпрометовано, скомпрометовано було і ваші секрети.

Альтернатива — архітектура з нульовим знанням (zero-knowledge), коли постачальник послуг математично не може розшифрувати ваші дані. Не «вирішує не робити цього», а не може. Жодне проникнення всередину, жодний недобросовісний працівник, жодний витончений зловмисник, що живе у вашій інфраструктурі два місяці, не зможе прочитати те, для чого на сервері ніколи не було ключів розшифрування.

Vercel просить клієнтів поставити прапорець, щоб увімкнути справжнє шифрування. Питання, яке варто поставити: чому це не було єдиним варіантом з самого початку?