Jeden pracownik firmy Context.ai pobierał skrypty do automatycznego grania w Roblox. Kilka tygodni później atakujący miał dostęp do zmiennych środowiskowych infrastruktury Vercel — jednej z największych platform dla deweloperów na świecie, obsługującej miliony wdrożeń aplikacji.
Między tymi dwoma zdarzeniami jest łańcuch czterech ogniw. Żadne z nich nie jest klasycznym włamaniem przez podatność. Każde jest nadużyciem istniejącego, autoryzowanego połączenia.
Vercel i Context.ai
Vercel to platforma do wdrażania i hostowania aplikacji webowych — szczególnie popularna w ekosystemie Next.js i frameworków opartych na React. Używana przez dziesiątki tysięcy zespołów deweloperskich od startupów po korporacje. Platforma ma dostęp do repozytoriów kodu, zmiennych środowiskowych zawierających klucze API i poświadczenia produkcyjne, oraz potoków wdrożeniowych łączących kod z infrastrukturą.
Context.ai to narzędzie AI do pracy biurowej — rozszerzenie Chrome oferujące asystenta AI zintegrowanego z pocztą, dokumentami i narzędziami do współpracy. Jeden z pracowników Vercel używał Context.ai z firmowym kontem Google Workspace.
19 kwietnia 2026 roku Vercel poinformował o incydencie bezpieczeństwa. Dochodzenie prowadzą Google Mandiant, GitHub, Microsoft, npm i Socket.
Cztery ogniwa łańcucha
Ogniwo pierwsze: skrypt Roblox i Lumma Stealer.
Hudson Rock odkrył że pracownik Context.ai w lutym 2026 roku pobierał złośliwe skrypty do gry Roblox — konkretnie narzędzia do automatycznego zbierania zasobów w grze, tzw. "auto-farm executors". Te narzędzia są notorycznym wektorem dla kradzieży danych. Lumma Stealer zainstalowany przez złośliwy skrypt zebrał z zainfekowanej maszyny poświadczenia Google Workspace, klucze do Supabase, Datadog i Authkit. Wśród skradzionych danych znalazło się konto support@context.ai — z poziomem dostępu wystarczającym do eskalacji uprawnień w infrastrukturze Context.ai.
Ogniwo drugie: pivot do infrastruktury Context.ai.
Używając skradzionych poświadczeń atakujący uzyskał nieautoryzowany dostęp do środowiska AWS Context.ai w marcu 2026 roku. Context.ai wykrył i zablokował ten dostęp — ale, jak firma przyznała później, atakujący zdążył też skompromitować tokeny OAuth dla użytkowników korzystających z rozszerzenia Chrome. Warto odnotować że Google usunął rozszerzenie Context.ai ze sklepu Chrome Web Store 27 marca 2026 — jeszcze przed tym jak Vercel odkrył incydent.
Ogniwo trzecie: OAuth jako most do Vercel.
Tu jest serce historii. Rozszerzenie Chrome Context.ai żądało przy instalacji rozległych uprawnień OAuth do Google Workspace. Pracownik Vercel zainstalował rozszerzenie i zalogował się przez firmowe konto enterprise, przyznając uprawnienia Allow All. Vercel wskazuje że wewnętrzna konfiguracja OAuth pozwoliła tej akcji na przyznanie szerokich uprawnień w całym enterprise Google Workspace firmy.
Atakujący posiadający skompromitowany token OAuth Context.ai mógł przez niego wejść do Google Workspace Vercel — bo jedno konto pracownika połączyło oba systemy przez standardowy mechanizm uwierzytelnienia delegowanego.
Ogniwo czwarte: pivot przez Google Workspace do infrastruktury Vercel.
Z poziomu Google Workspace jednego pracownika atakujący — opisywany przez Vercel jako "wysoce zaawansowany ze względu na tempo operacyjne i dogłębne rozumienie powierzchni API produktu" — przeszedł do konta Vercel tego pracownika, a stamtąd do środowiska Vercel. OX Security, który przeprowadził niezależną analizę, potwierdza że dostęp zaczął się od instalacji rozszerzenia Chrome i zalogowania przez konto enterprise z uprawnieniami Allow All.
Efekt: enumeracja i odszyfrowanie zmiennych środowiskowych przechowywanych w platformie. Vercel zaznacza że były to zmienne "niepoufne" — ale sam fakt dostępu do wartości których nie powinien mieć nieautoryzowany podmiot jest incydentem bez względu na klasyfikację danych.
Dlaczego to jest ta sama historia co cały kwiecień
Pisaliśmy o ataku na CPUID — skompromitowany poboczny interfejs API jako punkt wejścia do systemu dystrybucji. O kampanii TeamPCP i Checkmarx — zewnętrzna akcja GitHub jako punkt wejścia do potoków CI/CD. O nieautoryzowanym dostępie do Mythos przez Discord — zewnętrzny wykonawca i odgadnięty URL jako droga do modelu o ograniczonym dostępie.
Incydent Vercel jest wariantem tego samego wzorca z jednym istotnym elementem: narzędzie AI z rozszerzeniem Chrome i uprawnieniami OAuth jako punkt wejścia.
To jest nowa kategoria powierzchni ataku, którą warto nazwać wprost. Rozszerzenia przeglądarki z dostępem do firmowych kont Google Workspace mają przez OAuth potencjalny dostęp do całego ekosystemu narzędzi podpiętych pod te konta. Każde rozszerzenie zainstalowane przez pracownika z firmowym kontem enterprise i uprawnieniami Allow All jest potencjalnie mostem między zewnętrzną usługą a wewnętrzną infrastrukturą firmy.
Nie przez podatność w kodzie Vercel. Przez standardowy, autoryzowany mechanizm uwierzytelnienia delegowanego — używany dokładnie tak jak był zaprojektowany.
Roblox jako punkt wejścia do infrastruktury deweloperskiej
Jest w tej historii jeden szczegół, który warto zatrzymać dłużej niż na chwilę.
Łańcuch ataku zaczął się od pracownika Context.ai pobierającego skrypty do gry Roblox na maszynie, na której pracował z dostępem do firmowych systemów. Hudson Rock opisuje "auto-farm executors" jako "notoryczne wektory dla wdrożeń Lumma Stealer."
To nie jest wyjątkowy przypadek. Lumma Stealer jest aktywnie dystrybuowany przez złośliwe oprogramowanie podszywające się pod modyfikacje do gier, narzędzia do pobierania plików, cracki do oprogramowania. Pracownicy korzystający z firmowych maszyn — lub prywatnych maszyn z dostępem do firmowych kont — do aktywności pozazawodowych mieszają konteksty bezpieczeństwa w sposób który jest trudny do zarządzania i łatwy do przeoczenia.
Pisaliśmy o tym jak CPUID pokazał że obrona oparta na tarciu traci wartość gdy atakujący może działać szybko i tanio. Lumma Stealer w skrypcie Roblox to tarcie zerowe dla atakującego: dystrybucja przez kanały które pracownicy odwiedzają dobrowolnie, wykonanie przez samego użytkownika, zbieranie poświadczeń automatyczne.
Konsekwencje dla zarządzania uprawnieniami OAuth
Incydent Vercel jest opisywany przez badaczy jako studium przypadku w zakresie zarządzania uprawnieniami OAuth w środowiskach enterprise.
Jaime Blasco z Nudge Security zwraca uwagę że rozszerzenie Chrome Context.ai zawierało osadzony grant OAuth umożliwiający odczyt plików Google Drive użytkownika — 110671459871-f3cq3okebd3jcg1lllmroqejdbka8cqq.apps.googleusercontent.com. Wewnętrzna konfiguracja OAuth Vercel pozwoliła żeby zgoda udzielona przez jednego pracownika przez konto enterprise objęła cały enterprise Google Workspace firmy.
To jest konkretna klasa ryzyka: aplikacje OAuth zainstalowane przez indywidualnych pracowników przez konta enterprise mogą dziedziczyć uprawnienia organizacyjne szersze niż intencja pracownika. Allow All kliknięte przez jedną osobę może oznaczać Allow All dla całej organizacji w zależności od konfiguracji tenant.
Vercel po incydencie wprowadził zmiany: domyślne ustawianie zmiennych środowiskowych jako "poufnych", lepsza widoczność na poziomie całego zespołu i edukacja wbudowana w produkt dotycząca zarządzania zmiennymi. Osoby odpowiedzialne za bezpieczeństwo w organizacjach używających Google Workspace powinny zweryfikować listę zainstalowanych aplikacji OAuth — szczególnie rozszerzeń Chrome zainstalowanych przez konta enterprise — i sprawdzić zakres przyznanych uprawnień.
Co to mówi o rozszerzeniach AI
Kwiecień 2026 przyniósł kilka incydentów związanych z narzędziami AI jako wektorem ataku — ale z różnych stron.
SGLang pokazał że plik modelu może zawierać złośliwy kod wykonywalny. Comment and Control pokazał że asystent AI w GitHub Actions może być wektorem kradzieży kluczy przez tytuły zgłoszeń. Shai-Hulud przez Shai-Hulud pokazał że narzędzia AI do kodowania mogą być zatrute przez łańcuch dostaw.
Vercel przez Context.ai dodaje czwarty wariant: rozszerzenie Chrome AI narzędzia z uprawnieniami OAuth jako most między skompromitowaną zewnętrzną usługą a wewnętrzną infrastrukturą firmy.
Narzędzia AI mają tendencję do żądania szerokich uprawnień bo szeroki dostęp do danych użytkownika jest tym co czyni je użytecznymi: odczyt poczty, dokumentów, kalendarza, historii przeglądarki. Te uprawnienia są funkcją produktu. Stają się ryzykiem bezpieczeństwa gdy narzędzie zostanie skompromitowane lub gdy użytkownik instaluje je przez konto enterprise z konfiguracją dziedziczącą uprawnienia organizacyjne.
Podsumowanie
Incydent Vercel zaczął się od złośliwego skryptu Roblox na maszynie pracownika firmy zewnętrznej. Skończył na atakującym enumerującym zmienne środowiskowe jednej z największych platform deweloperskich na świecie — przez cztery ogniwa łańcucha, z których każde było nadużyciem autoryzowanego połączenia.
Żadne z tych ogniw nie było podatnością w kodzie Vercel. Żadne nie wymagało ominięcia mechanizmu bezpieczeństwa. Lumma Stealer wykonał pracownik instalując skrypt. OAuth wykonał pracownik klikając Allow All. Pivot przez Google Workspace wykonał atakujący przez standardowy mechanizm uwierzytelnienia delegowanego.
To jest właśnie ta klasa ataków którą najtrudniej zatrzymać przez tradycyjne mechanizmy obronne: nie atak na system, atak na zaufanie między systemami.
Źródła
Vercel — oficjalny biuletyn bezpieczeństwa z opisem incydentu i wskaźnikami kompromitacji OAuth: https://vercel.com/kb/bulletin/vercel-april-2026-security-incident
The Hacker News — szczegóły łańcucha kompromitacji i analiza Hudson Rock: https://thehackernews.com/2026/04/vercel-breach-tied-to-context-ai-hack.html
OX Security — niezależna analiza punktu wejścia przez rozszerzenie Chrome: https://www.ox.security/blog/context-ai-to-vercel-how-a-browser-extension-became-a-supply-chain-pivot/
Nudge Security / Jaime Blasco — szczegóły uprawnień OAuth rozszerzenia i daty usunięcia ze sklepu Chrome: https://www.nudgesecurity.com/post/context-ai-oauth-scope-analysis-vercel-breach
BleepingComputer — kontekst incydentu i kroki zaradcze: https://www.bleepingcomputer.com/news/security/vercel-confirms-security-breach-tied-to-compromise-of-third-party-context-ai-tool/
