
Це машинний переклад оригінального документа англійською мовою. У разі будь-яких розбіжностей між цим перекладом та оригінальною англійською версією, пріоритет має версія англійською мовою. Читати оригінал англійською мовою
Чит для Roblox, місяць мовчання та злам корпоративного OAuth: чому насправді вчить інцидент із Vercel
2026-04-22 · Caiioo Team
Три деталі зламу Vercel варті особливої уваги. Жодна з них не є головним заголовком. Усі вони змінюють те, як ви повинні думати про встановлення сторонніх інструментів ШІ.
Деталь 1: Ланцюжок постачання до зламу Vercel почався з чита для Roblox
Публічна історія інциденту Vercel виглядає так: співробітник Vercel встановив Context AI, надав йому широкі права Google Workspace, Context AI було зламано, токен OAuth перехоплено, зловмисник проник у Vercel.
Це історія «внизу за течією». Історія «вгорі за течією» дивніша.
Згідно з аналізом Hudson Rock — який зараз підтверджують Trend Micro, OX Security, Strapi та The Hacker News, і який не був спростований ні Vercel, ні Context AI станом на 22 квітня — початковим вектором став співробітник Context AI, чий особистий пристрій було зламано в лютому 2026 року. Зламом був Lumma Stealer, готовий інфостілер. Засобом доставки, як повідомляється, став завантажений експлойт «авто-ферма» для гри Roblox.
Стілер зробив свою справу. Він викрав облікові дані Google Workspace та облікові дані доступу до AWS співробітника. Ці дані стали важелем для всього подальшого: доступу до середовища AWS Context AI, доступу до сховища токенів OAuth, яке Context AI зберігав від імені своїх користувачів, доступу до токена, який співробітник Vercel надав для свого корпоративного Google Workspace, і, зрештою, доступу до внутрішніх середовищ Vercel та частини змінних середовища клієнтів.
Один чит для Roblox на особистому ноутбуці одного співробітника став першопричиною зламу ланцюжка постачання корпоративного OAuth, який Vercel описує як такий, що потенційно впливає на «сотні користувачів у багатьох організаціях».
Урок не в тому, що «Roblox — це погано». Урок у тому, що в архітектурі SaaS-AI поверхня атаки поширюється на особистий пристрій кожного співробітника кожного постачальника у вашому ланцюжку постачання. Ви можете мати ідеальну гігієну кінцевих точок у своїй компанії, але все одно бути скомпрометованими, тому що хтось через два постачальника від вас завантажив не той файл.
Деталь 2: Context AI дізналася в березні. Вони повідомили одного клієнта.
Власний бюлетень безпеки Context AI, опублікований на context.ai/security-update та оновлений 21 квітня 2026 року, розкриває таку хронологію:
- Березень 2026: Context AI виявляє несанкціонований доступ до середовища AWS, де розміщувався їхній застарілий продукт AI Office Suite. Вони залучають CrowdStrike для експертизи, виводять з експлуатації уражене середовище та повідомляють одного ідентифікованого постраждалого клієнта.
- Між березнем та 19 квітня: Токени OAuth, що належать «деяким» їхнім користувачам, залишаються скомпрометованими. Подальших повідомлень користувачам не надходить. Публічного розкриття немає.
- 19 квітня 2026: Vercel публікує свій бюлетень про інцидент безпеки, самостійно відстеживши злам до Context AI за допомогою власної експертизи.
- 21 квітня 2026: Context AI оновлює свій бюлетень додатковими рекомендаціями для користувачів. Жодних конкретних термінів сповіщення решти постраждалих користувачів не вказано.
- 22 квітня 2026 (на момент написання): Терміни сповіщення досі відсутні. Люди, чиї токени були скомпрометовані в лютому, досі не знають, коли і чи взагалі їм про це скажуть.
Це та частина, яка має змінити ставлення технічних команд до встановлення сторонніх інструментів ШІ. Виявлення зламу постачальником — це не те саме, що розкриття інформації вам.
У багатьох випадках у постачальника немає договірних або нормативних зобов'язань повідомляти вам про злам сервісу, навіть якщо злам включав токени OAuth, які ви їм передали. Ви можете робити все правильно зі свого боку — мінімальні права, MFA, умовний доступ, навчання з безпеки — і все одно перебувати під контролем зловмисника місяцями, тому що єдина сторона, здатна попередити вас, — це сторона, яка ще не хоче нічого говорити.
Деталь 3: Власний поділ продуктів Context AI підтверджує, яка архітектура виживає
У тому ж бюлетені Context AI захована одна фраза, яка важить більше, ніж решта документа разом узята.
Продуктом, який було зламано, був AI Office Suite — застарілий споживчий продукт Context AI. Їхній поточний корпоративний продукт, Bedrock, не постраждав. Власна причина, вказана Context AI: Bedrock «працює в середовищах клієнтів».
Та сама компанія з тією ж командою інженерів створила два продукти з двома різними архітектурами. Той, що був SaaS-посередником — той, що зберігав токени OAuth від імені клієнта в централізованій хмарі — був зламаний. Той, що працює в середовищі клієнта — той, що розмістив ШІ поруч із даними, а не дані поруч із ШІ — вижив. Не тому, що він мав кращу інженерію безпеки, а тому, що не було централізованого сховища, до якого могли б дістатися зловмисники.
Вам не потрібно вірити Caiioo на слово, що централізований SaaS ШІ має структурну проблему. Власна лінійка продуктів Context AI підтверджує це.
Що це означає для тих, хто оцінює інструменти ШІ
Консенсусний структурний урок спільноти дослідників безпеки — Trend Micro, Varonis, Halborn, OX Security, Strapi — полягає в тому, що широкі права OAuth «Дозволити все» є головним фактором ризику. Після видачі ці токени обходять MFA та умовний доступ. Злам постачальника стає зламом кожного акаунта далі по ланцюжку.
Ось три висновки:
- Надавайте перевагу мінімально необхідним правам, якщо постачальник їх пропонує. Якщо інструмент ШІ просить доступ на читання та запис до всього вашого Google Workspace для роботи з календарем — це тривожний сигнал.
- Надавайте перевагу постачальникам, чия архітектура взагалі не потребує довгострокових централізованих токенів. Це структурний крок. Моделі Bring Your Own Auth (BYOA), де клієнт OAuth створюється у вашому власному хмарному проєкті, а токени залишаються на вашому пристрої, повністю виключають постачальника з ланцюжка довіри.
- Не покладайтеся на розкриття інформації постачальником як на систему раннього попередження. Хронологія Context AI — виявлення в березні, сповіщення одного клієнта, оновлення бюлетеня 21 квітня без зобов'язань щодо ширшого сповіщення — не є винятком. Це те, що породжує економіка розкриття інцидентів за відсутності суворих юридичних зобов'язань. Ваші засоби контролю мають виходити з того, що постачальник не повідомить вас вчасно.
Як Caiioo побудований навколо цього
Caiioo — це потужний, орієнтований на конфіденційність робочий простір з агентним оркестратором та інтерфейсом чату, який працює в бічній панелі. Архітектура побудована навколо того ж висновку, який випадково підтвердив поділ продуктів Context AI: робочий простір має працювати поруч із вашими даними, а не тримати ваші дані поруч із собою.
Коротка версія: ваші токени OAuth для Workspace зберігаються в зашифрованому вигляді на вашому пристрої, а не в базі даних caiioo. Ваші виклики API Gmail/Календаря/Диска йдуть з вашого пристрою безпосередньо до Google, і наша інфраструктура ніколи не перебуває на шляху даних. Реле, яке ми використовуємо — для координації між пристроями, обміну OAuth та трафіку ліцензій/оплати — побудоване на основі Cloudflare Durable Objects для кожного користувача (кожен користувач апаратно ізольований від усіх інших) і використовує наскрізне шифрування на своїй шині повідомлень WebSocket (ми можемо маршрутизувати повідомлення, але не можемо їх прочитати). Наша центральна база даних зберігає ідентифікаційні дані облікового запису, статус оплати та метадані маршрутизації — не ваш контент, не ваші токени Workspace, не ваші розмови. Повний технічний опис, включаючи таблицю трафіку, яку ви можете перевірити самі за допомогою Little Snitch або Wireshark, знаходиться в нашому дописі про архітектурну відповідь на цей злам.
Це означає, що інцидент у стилі Context AI проти Caiioo не міг би призвести до наслідків у стилі Context AI. Не було б викраденого сховища токенів, тому що сховища токенів не існує. Не було б місяця мовчання, поки ми вирішуємо, коли повідомити користувачів, тому що в нашій інфраструктурі не було б нічого, що зловмисник міг би забрати у будь-якого користувача. Проблема «виявлення постачальником не є вашим розкриттям» зникає, коли постачальник з самого початку не має нічого вашого.
Спробуйте Caiioo
Caiioo доступний як розширення для браузера, нативний додаток для macOS, нативний додаток для iOS, нативний додаток для Android та десктопний додаток для Windows і Linux. Почніть безкоштовно.
Джерела:
- База знань Vercel: Бюлетень про інцидент безпеки у квітні 2026 року
- Context AI: Оновлення безпеки
- TechCrunch: Хостинг додатків Vercel заявляє про злам та крадіжку даних клієнтів
- The Hacker News: Злам Vercel пов'язаний із хакерською атакою на Context AI
- Trend Micro: Злам Vercel — атака на ланцюжок поставок OAuth викриває приховану загрозу
- OX Security: Vercel зламано через атаку на ланцюжок поставок Context AI
- Halborn: Пояснення — злам Vercel (квітень 2026)
- Varonis: Злам Vercel — кроки, які слід зробити зараз
- Strapi: Інцидент безпеки Vercel у квітні 2026 року
- SANS Institute NewsBites Том XXVIII Випуск 30, 21 квітня 2026 року