Vercel przechowywał sekrety w zwykłym tekście i nazwał to funkcją

Vercel został przełamany. Atakujący przebywał w systemie przez około dwa miesiące przed wykryciem. Wyliczył i odszyfrował zmienne środowiskowe klientów — klucze API, hasła do baz danych, klucze podpisujące, tokeny — dla każdego projektu, który nie korzystał z opcjonalnej flagi „sensitive” w Vercel.

Łańcuch ataku: przełamane zostało narzędzie zewnętrzne o nazwie Context.ai. Atakujący wykorzystał tę przyczółek do przejęcia konta Google Workspace pracownika Vercel. Stamtąd przeszedł do wewnętrznych systemów Vercel. Następnie zaczął czytać sekrety.

Dane są obecnie rzekomo oferowane na BreachForums za 2 miliony dolarów.

Pole „wrażliwe”, które nie było ustawieniem domyślnym

Oto część, która ma znaczenie.

Vercel ma dwa typy zmiennych środowiskowych. Zwykłe, które są „szyfrowane w spoczynku”, ale mogą zostać odszyfrowane i odczytane przez systemy Vercel. Oraz „wrażliwe”, które wykorzystują dodatkowe szyfrowanie — według zapewnień Vercel uniemożliwiające dostęp nawet od wewnątrz.

Atak mógł odczytać wszystkie zwykłe. Chronione były wyłącznie te „wrażliwe”.

Problem: opcja „wrażliwe” wymagała włączenia przez użytkownika. Nie była ustawieniem domyślnym. Każdy deweloper, który ustawił DATABASE_URL albo STRIPE_SECRET_KEY albo JWT_SIGNING_KEY bez zaznaczenia pola — a takich była większość — miał te wartości w formacie, który atakujący z dostępem wewnętrznym mógł odszyfrować.

Wytyczne Vercel po naruszeniu: „Enable the sensitive environment variable feature for encrypted storage.” Innymi słowy: szyfrowanie, które zakładał Pan lub Pani, że chroni Wasze sekrety, w rzeczywistości ich nie chroniło — ani przed nimi, ani przed kimkolwiek, kto dostał się do ich systemów.

Dwa miesiące czasu przebywania w systemie

Początkowe przełamanie miało miejsce w lutym 2026 r. Vercel opublikował pierwszy biuletyn bezpieczeństwa 19 kwietnia. To około dwa miesiące dostępu atakującego do systemów wewnętrznych.

Własny zespół bezpieczeństwa Vercel opisał atakującego jako „wysoce zaawansowanego, na co wskazuje jego operacyjna tempo pracy i dogłębne zrozumienie powierzchni API produktu Vercel”. Kiedy firma, która hostuje Państwa infrastrukturę, mówi, że atakujący rozumiał jej systemy lepiej, niż zakładano, warto się zatrzymać.

Przez te dwa miesiące atakujący miał czas, aby wyliczyć każdą dostępną zmienną środowiskową w dotkniętych projektach klientów. Czas na eksfiltrację. Czas na sprzedaż.

Łańcuch dostaw OAuth

Punkt wejścia nie był nawet własnym kodem Vercel. Pracownik Vercel autoryzował Context.ai — narzędzie produktywności AI — przez Google OAuth. Gdy Context.ai został przełamany, atakujący odziedziczył każde uprawnienie, jakie dawał ten grant OAuth.

To schemat, który wciąż się powtarza. Organizacje starannie zabezpieczają uwierzytelnianie podstawowe, a następnie wydają tokeny OAuth narzędziom zewnętrznym, które mają własną, często słabszą, postawę bezpieczeństwa. Jedno przełamane aplikacja w łańcuchu i atakujący odziedzicza dostęp Państwa pracownika.

Przejęty identyfikator aplikacji OAuth jest publiczny: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com. Jeśli Państwa organizacja autoryzowała tę aplikację, należy ją teraz unieważnić.

Co powinni Państwo zrobić

Jeśli wdrażają Państwo na Vercel:

• Natychmiast wymieńcie wszystkie zmienne środowiskowe — nie czekajcie na ustalenie, czy zostali Państwo „dotknięci”
• Włączcie flagę „sensitive” dla wszystkich zmiennych środowiskowych odtąd
• Przejrzyjcie uprawnienia aplikacji OAuth w Google Workspace i unieważnijcie wszystko, z czego nie korzystacie aktywnie
• Przejrzyjcie logi wdrożeń Vercel pod kątem nieoczekiwanych zmian w okresie luty–kwiecień 2026 r.
• Sprawdźcie usługi zależne (bazy danych, operatorów płatności, API) pod kątem nieautoryzowanego dostępu z użyciem danych uwierzytelniających przechowywanych w Vercel

Prawdziwa lekcja

Architektura Vercel przechowywała sekrety klientów w sposób, który umożliwiał ich odszyfrowanie przy dostępie wewnętrznym. Firma oferowała silniejszą opcję, ale nie uczyniła jej ustawieniem domyślnym. Przez dwa miesiące nikt nie zauważył atakującego czytającego te sekrety.

To jest problem bezpieczeństwa typu „zaufaj nam”. Vercel szyfrował zmienne środowiskowe w spoczynku — to technicznie prawda. Ale to oni trzymali klucze deszyfrujące. Kiedy ich systemy zostały przełamane, przełamane zostały także Wasze sekrety.

Alternatywą jest architektura z wiedzą zerową, w której dostawca usługi matematycznie nie może odszyfrować Państwa danych. Nie „wybiera, że nie odszyfruje” — nie może. Żadne przełamanie wewnętrzne, żaden nieuczciwy pracownik, żaden zaawansowany atakujący przebywający w Państwa infrastrukturze przez dwa miesiące nie odczyta tego, do czego serwer nigdy nie miał kluczy deszyfrujących.

Vercel prosi klientów o zaznaczenie pola, aby włączyć prawdziwe szyfrowanie. Pytanie warto zadać: dlaczego nie była to jedyna opcja od początku?