Rotuj, ponownie wdróż, cofnij: nasza reakcja na incydent Vercel

19 kwietnia 2026 Vercel ujawnił incydent bezpieczeństwa wywołany przez skompromitowaną aplikację OAuth innej firmy działającą wewnątrz ich Google Workspace. Przeprowadziliśmy procedurę reagowania we wszystkich projektach Vercel zarządzanych przez webvise jeszcze przed końcem weekendu, a logi audytowe zarówno Vercel, jak i Google Workspaces, które administrujemy, nie wykazały żadnych nieprawidłowości. Nie była to luka w kodzie samego Vercel. Był to kompromis łańcucha dostaw SaaS-to-SaaS przez granicę zaufania OAuth, a jego charakter zmienia to, jak powinna wyglądać właściwa reakcja.

Rotacja sekretów w panelu Vercel to może połowa odpowiedzi. Druga połowa leży w Google Workspace, a większość opracowań jej nie omawia.

Przeczytali Państwo ujawnienie i zmienili każdy klucz, jaki mogli znaleźć. To właściwy pierwszy krok. Niniejszy artykuł opisuje całą procedurę, którą przeprowadziliśmy od początku do końca, techniczny szczegół powodujący, że rotacja musi obejmować działające funkcje, oraz dlaczego charakter tego naruszenia powinien zmienić Państwa plan reagowania na przyszłość.

• Rotacja zmiennych środowiskowych Vercel zmienia wartości w panelu, nie w działających funkcjach. Wartości wchodzą w życie dopiero przy kolejnym wdrożeniu.

• Audyt OAuth w Google Workspace to ta połowa, o której prawie nikt nie pisze. To właśnie ta ścieżka zaufania umożliwiła atakującemu dotarcie do Vercel.

• Nie była to luka w Vercel. Był to kompromis SaaS-to-SaaS przez nadanie OAuth, a standardowa reakcja w stylu CVE nie zamknęła pętli.

• Długoterminowo należy przenieść sekrety z env vars do menedżera sekretów uruchamianego w czasie rzeczywistym. Na każdym koncie, które może instalować aplikacje OAuth, należy wymagać odpornego na phishing MFA.

• Miesięczne audyty nadań OAuth innym firmom w dostawcy tożsamości są teraz elementem podstawowym, nie opcjonalnym usprawnieniem.

Co dokładnie ujawnił Vercel

Krótko: aplikacja SaaS innej firmy z dostępem OAuth wewnątrz Google Workspace Vercel została skompromitowana, a atakujący wykorzystał tę granicę zaufania, by dotrzeć do wartości zmiennych środowiskowych w części projektów klientów. Vercel opublikował ID klienta OAuth jako wskaźnik kompromitacji i poprosił każdego klienta o rotację sekretów przechowywanych jako zmienne środowiskowe. Nic w tym incydencie nie dotyczyło luki w kodzie Vercel. Powierzchnią ataku był graf zaufania tożsamości między dwoma narzędziami SaaS.

To ma znaczenie dla sposobu reagowania. Jeśli luka tkwi we własnym kodzie platformy, należy zastosować łatę, dokonać rotacji tego, co wyciekło, i przejść dalej. Jeśli luka leży w ścieżce zaufania między platformami, rotacja jest konieczna, ale nie zamyka dziury. Trzeba również cofnąć nadanie, którym posłużył się atakujący, bo inaczej kolejny kompromis tego samego narzędzia powtórzy ten sam zasięg.

Jeśli chcą Państwo, żeby ktoś z zewnątrz przejrzał Państwa konfigurację Vercel, zanim napisze się o niej post-mortem, przeprowadzamy przeglądy bezpieczeństwa dla zespołów Vercel, Google Workspaces i nadań SaaS-to-SaaS.

Krok pierwszy: rotacja sekretów, które naprawdę mają znaczenie

Każdą zmienną środowiskową mogącą przyznać dostęp do czegokolwiek traktowaliśmy domyślnie jako skompromitowaną. Taki wniosek wynika z treści ujawnienia. Poniżej wymieniono klasy sekretów, które ponownie wystawiliśmy we wszystkich zarządzanych projektach.

• Dane logowania do baz danych. Ciągi połączenia, hasła replik tylko do odczytu i klucze roli admin w każdym projekcie z bazą danych.

• Klucze API Resend do transakcyjnej poczty elektronicznej w każdym projekcie wysyłającym wiadomości weryfikacyjne, powiadomienia lub wiadomości rejestracyjne.

• Dane uwierzytelniające Google APIs dla integracji z Workspace, Calendar, Drive i Analytics działających po stronie serwera.

• Klucze AI Gateway, w tym tokeny dostępu do modeli, dane uwierzytelniające dostawców i tokeny limitu szybkości dla wszystkiego routowanego przez bramę.

• Dane uwierzytelniające integracji ingest dla punktów końcowych webhooków, potoków zdarzeń i wszystkiego pobierającego dane do projektu z zewnątrz.

Dwie kategorie wymagają szczególnej uwagi: zmienne kończące się na `_URL`, które zawierają dane uwierzytelniające wewnątrz ciągów połączenia, oraz wszystko oznaczone `_TEST` lub `_DEV`, co okazuje się wskazywać na środowisko produkcyjne. Należy je rotować razem z pozostałymi. Atakujący odczytujący env vars nie przejmuje się wybraną flagą ani tym, co sugeruje nazwa zmiennej.

Krok drugi: ponowne wdrożenie (techniczny szczegół, który sprawia, że rotacja staje się realna)

To najważniejsza część, o której mówi się najmniej. Vercel stosuje zmiany zmiennych środowiskowych w momencie budowania i wdrażania, nie w czasie wykonywania. Projekt, który zaktualizowano, ale nie wdrożono ponownie, nadal uruchamia build ze wczoraj, który ma stary sekret wbudowany w swoje środowisko uruchomieniowe. Dokonano rotacji w panelu, nie w systemie.

Konkretny przykład: klucz API Resend rotuje się o 10:14 i otwiera nową kartę, żeby sprawdzić coś innego. Funkcja próbuje wysłać e-mail weryfikacyjny o 10:17, wywołuje Resend ze starym kluczem nadal wbudowanym w wdrożone środowisko i Resend odrzuca żądanie. Użytkownik nie dostaje swojego e-maila. Należy pomnożyć to przez każdą funkcję, każdy cron i każdy handler webhooków działające na starym buildzie.

Aby zweryfikować procedurę, należy otworzyć zakładkę Deployments w każdym projekcie i znaleźć wdrożenie z sygnaturą czasową późniejszą niż rotacja. Jeśli górny wiersz pokazuje sygnaturę czasową wcześniejszą niż moment rotacji, rotacja nie trafiła do żadnego działającego procesu. Drugim wyraźnym krokiem w naszej procedurze było wymuszone ponowne wdrożenie produkcji w każdym zarządzanym projekcie po rotacji, przed przejściem dalej.

Krok trzeci: cofnięcie nadania OAuth w Google Workspace

To ta połowa procedury, o której prawie nie było mowy w weekendowych wątkach. Incydent miał źródło w Google Workspace. Atakujący dostał się przez aplikację OAuth innej firmy z nadanym zakresem w Workspace, a następnie przestawił się na Vercel przez ścieżkę zaufania SaaS-to-SaaS. Jeśli rotacja odbyła się tylko po stronie Vercel, ta sama aplikacja OAuth nadal tam siedzi z tym samym zakresem, gotowa do nadużycia przy następnym kompromisie.

Ścieżka w konsoli admin: admin.google.com, bezpieczeństwo, kontrola API, kontrola dostępu aplikacji, aplikacje innych firm. Należy wyszukać ID klienta OAuth opublikowany przez Vercel jako wskaźnik. Jeśli jest obecny, cofnąć go. Następnie trzeba wykonać trudniejsze zadanie: przejrzeć każde inne nadanie OAuth na liście, potwierdzić, że każdy zakres był zamierzony, i cofnąć wszystko, do czego nie ma aktualnego uzasadnienia.

Przeprowadziliśmy ten audyt w każdym administrowanym przez nas Workspace. Wskaźnik nie był obecny, a większość nadań miała uzasadniony cel biznesowy. Kilka nie miało i zostały cofnięte. Od tamtej pory przyjęliśmy miesięczny rytm: audyt nadań OAuth na początku każdego miesiąca, cofanie wszystkiego nieużywanego przez 30 dni.

Krok czwarty: działania długoterminowe

Rotacja i cofnięcie nadań zamknęły bezpośrednie narażenie. Działania długoterminowe mają zapobiec temu, żeby kolejny incydent znów był weekendowym chaosem. Wdrażamy je w zarządzanych projektach w nadchodzących tygodniach i rekomendujemy każdemu zespołowi prowadzącemu infrastrukturę opartą na SaaS.

• Pobieranie sekretów w czasie wykonywania z menedżera sekretów zamiast wbudowywania ich w env vars. Rotacja staje się operacją push, nie ponownym wdrożeniem.

• Krótkotrwałe poświadczenia dla baz danych i API wszędzie tam, gdzie dostawca je obsługuje. Ważność liczona w minutach, nie miesiącach.

• Zaplanowana rotacja dla poświadczeń, których nie można uczynić krótkotrwałymi. Oparta na kalendarzu, nie na incydentach.

• Odporny na phishing MFA na każdym koncie admin, które może instalować aplikacje OAuth u dostawcy tożsamości. Passkeys lub tokeny sprzętowe, bez niczego opartego na SMS.

• Miesięczne audyty nadań OAuth w Workspace, Microsoft 365 lub jakimkolwiek dostawcy tożsamości. Ścieżka atakującego tym razem prowadziła przez nadanie OAuth i następnym razem też tak będzie.

Większość zespołów nie ma jednego właściciela dla żadnego z tych punktów. To cicha przyczyna, dla której incydenty wciąż kończą się tymi samymi podpunktami w post-mortem. Porozmawiajmy o tym, jak webvise wbudowuje te elementy w retainer utrzymaniowy każdego zarządzanego projektu.

Dlaczego to naruszenie jest inne

Model naruszenia, dla którego zbudowana jest większość programów bezpieczeństwa: atakujący znajduje CVE na serwerze, który się prowadzi, exploituje go i wyciąga dane. Rotacja, łatanie i monitoring perimetryczny pokrywają ten model. Incydent z 19 kwietnia 2026 ma inny kształt.

Atakujący kompromituje jedno narzędzie SaaS autoryzowane przez zespół, a następnie wykorzystuje relację zaufania między tym narzędziem a innymi narzędziami SaaS, by dotrzeć do danych, których żadne z nich nie udostępniłoby obcej osobie. Konto Vercel nie zostało naruszone i Google Workspace też nie. Naruszone zostało trzecie narzędzie, które ktoś połączył kilka miesięcy temu, a zakresy nadane temu narzędziu propagowały kompromis dalej.

Model obronny musi odpowiadać modelowi ataku. Oznacza to traktowanie nadań OAuth jako zależności produkcyjnych, audytowanie ich według harmonogramu i przenoszenie sekretów z zmiennych środowiskowych, z których atakujący z takim nadaniem może je odczytać. Nasze logi audytowe wyszły czyste tego weekendu, ale to efekt tego konkretnego incydentu, nie dowód na to, że model reagowania jest przyszłościowy.

Przeprowadzamy przeglądy bezpieczeństwa dla zespołów Vercel, Google Workspaces i grafów tożsamości SaaS-to-SaaS w ramach każdego zaangażowania zarządzanego przez webvise. Jeśli przed kolejnym ujawnieniem chcą Państwo zewnętrznego spojrzenia na swoją konfigurację, zacznijmy rozmowę.