Wyciek Vercel – jak OAuth z narzędzia AI otworzył klucze API klientów

19 kwietnia 2026 roku Vercel, jedna z najpopularniejszych platform hostingowych dla aplikacji webowych na świecie, przyznała się do włamania. W oficjalnym biuletynie bezpieczeństwa firma potwierdziła nieautoryzowany dostęp do części swoich wewnętrznych systemów oraz do ograniczonej grupy klientów. Co najciekawsze, źródłem ataku nie była luka w kodzie platformy ani błąd konfiguracji. Był nim zewnętrzne narzędzie AI o nazwie Context.ai, z którego korzystał jeden z pracowników Vercel. Poniżej rozkładamy na czynniki pierwsze, co dokładnie się stało na podstawie oficjalnego biuletynu Vercel i relacji BleepingComputer. Wyjaśniamy też, dlaczego to jest ważne dla każdego projektu hostowanego w chmurze i jakie trzy rzeczy warto sprawdzić jeszcze dzisiaj.

Co dokładnie ogłosił Vercel 19 kwietnia 2026

Oficjalny biuletyn Vercel brzmi dyplomatycznie, ale kluczowe zdanie jest jednoznaczne. Firma potwierdziła nieautoryzowany dostęp do części swoich wewnętrznych systemów oraz do ograniczonej grupy klientów. Skala incydentu była na tyle duża, że CEO Vercel Guillermo Rauch zdecydował się opublikować rekomendacje publicznie, a nie tylko dla poszkodowanych. Vercel jednocześnie zaangażował firmę Mandiant, dodatkowych specjalistów od reagowania na incydenty oraz powiadomił organy ścigania. Drugie zdanie z biuletynu mówi, że usługi platformy działały przez cały czas bez przerw. Dla wielu to kluczowa informacja. Vercel hostuje przecież olbrzymią część polskiej sceny Next.js, w tym sklepy, portale i landing page’e, które nie mogły sobie pozwolić nawet na godzinny przestój.

Rauch opisał atakujących jako “wysoce wyrafinowanych i istotnie wzmocnionych przez AI”. W tłumaczeniu na polski to oznacza, że ktoś, kto znalazł się w systemach Vercel, poruszał się po nich z prędkością i znajomością, jakiej zwykle nie widuje się u pojedynczych napastników. Ten sygnał nie jest przypadkowy, ponieważ w ślad za incydentem pojawiło się konto na forum hakerskim przedstawiające się jako ShinyHunters i oferujące dane Vercela za 2 miliony dolarów. Co prawda osoby związane z prawdziwą grupą ShinyHunters w rozmowie z BleepingComputer zaprzeczyły, jakoby to one stały za atakiem, jednak rzekome próbki danych trafiły już do obiegu. Wśród nich mają być fragmenty kodu, klucze i 580 rekordów pracowników. Autentyczność tych plików nie została niezależnie potwierdzona.

Jak OAuth z Context.ai stał się wektorem ataku

Mechanizm ataku wygląda jak klasyczny łańcuch dominających klocków. Context.ai to amerykańska platforma AI, która buduje agenty trenowane na wewnętrznej wiedzy firmy, dokumentach i procesach. Klienci Context.ai podpinają platformę do swojego Google Workspace przez aplikację OAuth, żeby model miał dostęp do e-maili, dokumentów i kalendarzy potrzebnych do treningu. Tej integracji używał również jeden z pracowników Vercel. W momencie, w którym napastnicy przejęli aplikację OAuth Context.ai, zyskali w praktyce klucze zapasowe do kont Google wszystkich klientów tej platformy.

Kolejny krok wygląda mechanicznie. Z kontem Google Workspace pracownika Vercel w ręku atakujący zalogowali się do wewnętrznych systemów firmy, do których ten pracownik miał dostęp. Stamtąd przeszli do środowisk deploymentu i wyciągnęli zmienne środowiskowe (czyli ukryte konfiguracje projektów, w których programiści trzymają klucze API, tokeny i hasła do baz danych). Mieli jednak jeden istotny limit. Mogli odczytać tylko zmienne nieoznaczone jako “sensitive”. Szczegółowy OAuth App ID, który Vercel opublikował do audytu, brzmi 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com. Każdy administrator Google Workspace powinien sprawdzić, czy ta aplikacja miała uprawnienia w jego domenie.

Atakujący nie musieli znajdować luki w Vercel. Wystarczyło im narzędzie AI, któremu pracownik dał dostęp do swojej skrzynki.

Wektor ataku przypomina sytuację z życia codziennego. Wyobraź sobie, że zostawiasz klucz zapasowy do mieszkania u sąsiada, który jest miły, kompetentny i pomocny. Pewnego dnia ktoś włamuje się do jego mieszkania i znajduje tam klucze wszystkich sąsiadów, w tym Twój. Jego zabezpieczenia nie miały nic wspólnego z Twoimi. A jednak kłopot masz Ty, nie on. Dokładnie tak działa OAuth w ekosystemie narzędzi AI i o tym samym problemie pisaliśmy już przy okazji bezpieczeństwa serwerów MCP w agentach AI.

Dlaczego flaga Sensitive w Vercel okazała się krytyczna

Najciekawsza jest nie sama mechanika ataku, tylko to, co o platformie mówi skala wycieku. W Vercel każdą zmienną środowiskową możesz oznaczyć jako “sensitive”. Taka zmienna jest zaszyfrowana i niemożliwa do odczytania z poziomu panelu ani API, nawet przez uwierzytelnionego użytkownika. Atakujący nie dostali tych wartości i Vercel potwierdza to w oświadczeniu. Problem polega na tym, że ta flaga jest domyślnie wyłączona. Większość programistów, którzy kiedykolwiek dodawali zmienne w panelu Vercel, w ogóle o nim nie wiedziała. W efekcie klucze API do baz danych i sekrety Stripe leżały w formie, którą atakujący po prostu skopiował. To samo dotyczyło tokenów z Sentry, GitHub i NPM oraz dziesiątek innych wrażliwych wartości.

Co musisz sprawdzić w ciągu godziny

Vercel opublikował listę rekomendacji, ale w praktyce sprowadza się ona do trzech rzeczy, które powinien zrobić każdy użytkownik platformy. Pierwsza to rotacja wszystkich zmiennych środowiskowych nieoznaczonych jako “sensitive”. Czyli w praktyce większości, jakie masz w projekcie. Druga to audyt logów aktywności konta i wdrożeń z ostatnich dwóch tygodni, pod kątem nieznanych adresów IP, deploymentów albo zmian konfiguracji. Trzecia to włączenie flagi Sensitive dla wszystkich nowo dodawanych sekretów oraz ustawienie Deployment Protection na poziom Standard jako minimum. Jeśli używasz Vercel w firmie, dołóż czwarty krok. Wejdź do panelu administracyjnego Google Workspace i sprawdź, czy aplikacja OAuth o identyfikatorze podanym przez Vercel miała uprawnienia w Waszej domenie.

Flaga Sensitive w Vercel powinna być domyślnie włączona, a nie opcjonalna. Ten incydent właśnie zamknął tę dyskusję.

Konsekwencje są większe niż sama platforma. Każdy programista, który korzysta z PaaS (platformy jako usługi), zwyczajowo ufa dostawcy w kwestii bezpieczeństwa. Vercel przez lata budował ten komfort perfekcyjnym DX, szybkimi buildami i wygodnym CI/CD. Wpadka pokazuje, że fundamentem zaufania nie są przyjazne narzędzia, tylko domyślne ustawienia. To jest lekcja, którą zespoły z większymi wymaganiami bezpieczeństwa wyciągały od lat z incydentów typu SolarWinds czy Okta. Teraz dostaje ją też społeczność frontendowa. O podobnych ryzykach w lokalnej infrastrukturze pisaliśmy przy okazji krytycznej luki bezpieczeństwa n8n CVE-2026-33660. Z kolei o prywatności danych w samym ekosystemie Vercel piszemy w artykule o pluginie Vercel w Claude Code, który czyta prompty.

Kurs n8n 2.0 · Kodożercy

Od zera do własnych automatyzacji – bez doświadczenia

Kurs n8n 2.0 od Kodożerców przeprowadzi Cię krok po kroku przez budowanie prawdziwych automatyzacji. Od webhooków, przez integracje z API, po własne przepływy danych – wszystko bez programowania.

Sprawdź kurs n8n 2.0 →

FAQ – najczęstsze pytania o wyciek Vercel

Czy dane moich klientów wyciekły?

Vercel potwierdza, że dotknięty został “ograniczony podzbiór” klientów i że osoby z tej grupy zostały skontaktowane bezpośrednio. Jeśli nie dostałeś maila od zespołu bezpieczeństwa Vercel, prawdopodobnie Twój projekt nie był w tej grupie. Mimo to rekomendowana jest rotacja wszystkich zmiennych środowiskowych, które nie były oznaczone jako “sensitive”, ponieważ nie wiadomo, kto jeszcze może mieć dostęp do wycieku.

Co to jest Context.ai i dlaczego dał dostęp atakującym?

Context.ai to platforma AI budująca agenty trenowane na wewnętrznej wiedzy firmy. Łączy się z Google Workspace przez OAuth, żeby model mógł czytać dokumenty, e-maile i kalendarze. Atakujący przejęli aplikację OAuth Context.ai, co dało im dostęp do kont Google wszystkich klientów tej platformy, w tym jednego z pracowników Vercel.

Czy to znaczy, że każde narzędzie AI z OAuth jest ryzykiem?

Każda integracja OAuth to dodatkowy punkt zaufania w łańcuchu. Ryzyko nie dotyczy samej idei OAuth, tylko tego, jak rygorystycznie firma trzyma higienę integracji. W praktyce warto raz na kwartał przeglądać listę aktywnych aplikacji OAuth w Google Workspace i Microsoft 365 oraz usuwać te, z których nikt już nie korzysta.

Czy powinienem przestać używać Vercel?

Krótka odpowiedź to nie. Vercel zareagował szybko, publicznie, podał konkretne identyfikatory do audytu i włączył do akcji Mandiant. To jest właśnie ten rodzaj transparentności, którego oczekuje się od dostawcy PaaS. Długoterminowo wniosek brzmi inaczej. Zespoły z większymi wymaganiami bezpieczeństwa powinny włączyć flagę Sensitive wszędzie, gdzie trzymają sekrety, oraz rozważyć rotację sekretów jako element regularnego procesu, nie tylko reakcję na incydent.

Podsumowanie

Wyciek z Vercel nie zaczął się od luki w platformie, tylko od OAuth zewnętrznego narzędzia AI, z którego korzystał jeden pracownik. W efekcie atakujący dostał się do wewnętrznych systemów firmy i wyciągnął zmienne środowiskowe części klientów. Ochronę miały tylko sekrety oznaczone jako “sensitive”, ale ta flaga jest domyślnie wyłączona i większość użytkowników nawet o niej nie wiedziała. Jeśli korzystasz z Vercel, zrotuj klucze, zrób audyt logów i włącz flagę Sensitive dla wszystkich nowych zmiennych. Jeśli zarządzasz Google Workspace w firmie, sprawdź, czy aplikacja OAuth z podanym przez Vercel identyfikatorem miała u Was uprawnienia. Przy okazji zweryfikuj wszystkie inne integracje AI. Narzędzie, które dzisiaj pomaga pracownikom pisać maile, jutro może stać się bramą do Twoich sekretów.

Mateusz Wojdalski

Specjalista SEO i content marketingu w Devstock. Zajmuję się strategią treści, automatyzacją procesów marketingowych i wdrożeniami AI w codziennej pracy. Badam nowe narzędzia, adaptuję je do realnych zadań i piszę o tym, co faktycznie działa.