Roteren, opnieuw deployen, intrekken: onze reactie op het Vercel-incident

Op 19 april 2026 maakte Vercel een beveiligingsincident openbaar dat te herleiden was naar een gecompromitteerde OAuth-applicatie van een derde partij binnen de Google Workspace van Vercel. Wij hebben de respons uitgevoerd op elk door webvise beheerd Vercel-project voordat het weekend voorbij was, en de auditlogs van zowel Vercel als de Google Workspaces die wij beheren kwamen schoon terug. Dit was geen kwetsbaarheid in de eigen code van Vercel. Het was een SaaS-to-SaaS supply-chain-compromis via een OAuth-vertrouwensgrens, en de aard ervan verandert hoe een correcte respons er uitziet.

Secrets roteren in uw Vercel-dashboard is misschien de helft van de respons. De andere helft bevindt zich in Google Workspace, en de meeste analyses besteden daar nauwelijks aandacht aan.

U hebt de disclosure gelezen en elke sleutel die u kon vinden doorgedraaid. Dat is de juiste eerste stap. Dit artikel beschrijft wat wij van begin tot eind hebben uitgevoerd, de technische valkuil die rotatie van toepassing maakt op lopende functies, en waarom de aard van deze inbreuk bepaalt hoe uw responsplan er de volgende keer uit moet zien.

• Het roteren van Vercel env vars wijzigt het dashboard, niet de lopende functies. Waarden worden pas van kracht bij de volgende deploy.

• De Google Workspace OAuth-audit is de helft die nauwelijks besproken wordt. Dat is het vertrouwenspad dat de aanvaller heeft gebruikt om Vercel te bereiken.

• Dit was geen Vercel-kwetsbaarheid. Het was een SaaS-to-SaaS-compromis via een OAuth-verlening, en een normale CVE-respons sluit de lus niet.

• Op de lange termijn: verplaats secrets uit env vars naar een runtime secret manager. Vereis phishing-resistente MFA voor iedereen die OAuth-apps kan installeren.

• Maandelijkse audits van OAuth-verleningen van derden in uw identiteitsprovider maken nu deel uit van de basis, niet van een volwassenheidsupgrade.

Wat Vercel daadwerkelijk heeft bekendgemaakt

De korte versie: een SaaS-applicatie van een derde partij met OAuth-toegang binnen de Google Workspace van Vercel werd gecompromitteerd, en de aanvaller gebruikte die vertrouwensgrens om de waarden van omgevingsvariabelen op te vragen van een deel van de klantprojecten. Vercel publiceerde een OAuth client ID als indicator van compromis en vroeg elke klant om elk secret dat als omgevingsvariabele is opgeslagen te roteren. Niets hiervan had te maken met een kwetsbaarheid in de eigen code van Vercel. Het aanvalsoppervlak was de identiteitsvertrouwensgraph tussen twee SaaS-tools.

Dat is van belang voor de manier waarop u reageert. Als de kwetsbaarheid in de eigen code van het platform zit, patcht u, roteert u wat er is uitgelekt en gaat u verder. Als de kwetsbaarheid in het vertrouwenspad tussen platforms zit, is rotatie noodzakelijk, maar sluit het de opening niet. U moet ook de verlening intrekken waarop de aanvaller is meegelift, anders herhaalt de volgende compromittering van datzelfde tool dezelfde schade.

Als u een tweede paar ogen wilt op uw Vercel-configuratie voordat het post-mortem van komend weekend over u gaat, voeren wij beveiligingsreviews uit voor Vercel-teams, Google Workspaces en SaaS-to-SaaS-verleningen.

Stap een: roteer de secrets die er echt toe doen

Wij hebben elke omgevingsvariabele die toegang kan verlenen tot wat dan ook standaard als gecompromitteerd behandeld. Dat is de aanname die de disclosure vereist. Hieronder staan de secretklassen die wij op de beheerde projecten opnieuw hebben aangemaakt.

• Databasereferenties. Verbindingsstrings, wachtwoorden van read-only replica's en admin-tier rolsleutels op elk project met een database-backend.

• Resend API-sleutels voor transactionele e-mail op elk project dat verificatie-, meldings- of aanmeldingsberichten verstuurt.

• Google API-referenties voor Workspace-, Agenda-, Drive- en Analytics-integraties die server-side draaien.

• AI Gateway-sleutels inclusief modeltoegangstoken, providerreferenties en rate-limittokens voor alles dat via de gateway wordt gerouteerd.

• Ingest-integratiereferenties voor webhookendpoints, eventpipelines en alles dat gegevens van buiten in het project trekt.

Twee categorieën die extra controle verdienen: variabelen die eindigen op `_URL` en referenties insluiten in verbindingsstrings, en alles met het label `_TEST` of `_DEV` dat toch naar productie blijkt te verwijzen. Roteer die samen met de rest. Een aanvaller die env vars leest, geeft niet om welke vlag u heeft gekozen of wat de variabelenaam suggereert dat hij doet.

Stap twee: opnieuw deployen (de technische valkuil die rotatie werkelijk maakt)

Dit is het onderdeel dat het meeste belang heeft en de minste aandacht krijgt. Vercel past wijzigingen in omgevingsvariabelen toe op het moment van bouwen en deployen, niet tijdens runtime. Een project dat u heeft bijgewerkt maar onaangepast heeft gelaten, draait nog steeds de build die u gisteren heeft opgeleverd, met het oude secret nog steeds ingebakken in zijn runtime. U heeft het dashboard geroteerd, niet het systeem.

Concreet voorbeeld: u roteert uw Resend API-sleutel om 10:14 en opent een nieuw tabblad om iets anders te controleren. Een functie probeert om 10:17 een verificatiemailte te versturen, roept Resend aan met de oude sleutel die nog in de gedeployde omgeving is ingebakken, en Resend weigert het verzoek. Uw gebruiker ontvangt zijn e-mail niet. Vermenigvuldig dat met elke functie, elke cron en elke webhookhandler die de oude build draait.

Om uw respons te verifiëren, opent u het tabblad Deployments op elk project en zoekt u een deployment met een tijdstempel na uw rotatie. Als de bovenste rij een tijdstempel toont van voor het moment van rotatie, heeft de rotatie geen enkel lopend proces bereikt. De tweede expliciete stap in onze aanpak was een geforceerde herdeployment naar productie op elk beheerd project na de rotatie, voordat we verder gingen.

Stap drie: trek de Google Workspace OAuth-verlening in

Dit is de helft van de respons die in de weekendthreads nauwelijks besproken werd. Het incident is ontstaan in Google Workspace. De aanvaller is binnengekomen via een OAuth-applicatie van een derde partij met een verleend bereik binnen Workspace, en heeft vervolgens via een SaaS-to-SaaS-vertrouwenspad naar Vercel gepivoteerd. Als u alleen aan de Vercel-kant heeft geroteerd, staat diezelfde OAuth-app er nog steeds met hetzelfde bereik, klaar om misbruikt te worden zodra deze de volgende keer wordt gecompromitteerd.

Het pad in uw beheerconsole: admin.google.com, beveiliging, API-beheer, app-toegangsbeheer, apps van derden. Zoek naar de OAuth client ID die Vercel als indicator heeft gepubliceerd. Trek deze in als hij er staat. Doe daarna het moeilijkere werk: bekijk elke andere OAuth-verlening in de lijst, bevestig dat elk bereik opzettelijk is, en trek in wat u geen levende reden heeft om te bewaren.

Wij hebben deze audit uitgevoerd op elke Workspace die wij beheren. De indicator was niet aanwezig en de meeste verleningen hadden een legitiem zakelijk doel. Een handvol niet, en die hebben wij ingetrokken. Sindsdien werken wij met een maandelijkse cadans: audit OAuth-verleningen aan het begin van elke maand en trek in wat de afgelopen 30 dagen niet is gebruikt.

Stap vier: de stappen voor de lange termijn

Rotatie en intrekking hebben de directe blootstelling aangepakt. De stappen voor de lange termijn zijn wat voorkomt dat het volgende incident een weekendcrisis wordt. Wij implementeren deze op de beheerde projecten in de komende weken, en wij bevelen ze aan elk team aan dat een SaaS-zwaar stack draait.

• Haal secrets tijdens runtime op uit een secret manager in plaats van ze in env vars te bakken. Rotatie wordt een push, geen redeploy.

• Kortlevende referenties voor databases en API's waar de provider ze ondersteunt. Minuten geldigheid, geen maanden.

• Geplande rotatie voor de referenties die niet kortlevend kunnen worden gemaakt. Kalendergestuurd, niet incidentgestuurd.

• Phishing-resistente MFA op elk adminaccount dat OAuth-applicaties kan installeren in uw identiteitsprovider. Passkeys of hardwaretokens, niets op basis van SMS.

• Maandelijkse OAuth-verlening-audits in Workspace, Microsoft 365 of welke identiteitsprovider u ook gebruikt. Het pad van de aanvaller was dit keer een OAuth-verlening; de volgende keer ook.

De meeste teams hebben voor geen van deze punten een duidelijke eigenaar. Dat is de stille reden waarom incidenten keer op keer eindigen met dezelfde punten in het post-mortem. Neem contact met ons op over hoe webvise deze onderdelen integreert in het onderhoudsretainer voor elk beheerd project.

Waarom deze inbreuk anders is

Het inbreukmodel waarvoor de meeste beveiligingsprogramma's zijn gebouwd: een aanvaller vindt een CVE in een server die u beheert, misbruikt die, en dumpt uw gegevens. Rotatie, patching en perimetermonitoring dekken dat model. Het incident van 19 april heeft een andere vorm.

Een aanvaller compromitteert een SaaS-tool die uw team heeft geautoriseerd, en maakt vervolgens gebruik van de vertrouwensrelatie tussen die tool en uw andere SaaS-tools om gegevens te bereiken die geen van beide aan een buitenstaander zou hebben gegeven. Uw Vercel-account is niet gecompromitteerd, en uw Google Workspace ook niet. Een derde tool die iemand maanden geleden heeft gekoppeld, werd gecompromitteerd, en de bereiken die u aan die tool heeft verleend, hebben het compromis stroomafwaarts doorgegeven.

Het defensieve model moet overeenkomen met het aanvalsmodel. Dat betekent OAuth-verleningen behandelen als productie-afhankelijkheden, ze op een schema auditen en secrets uit omgevingsvariabelen halen waar een aanvaller met die verlening ze kan lezen. Onze auditlogs kwamen dit weekend schoon terug, maar dat is de opbrengst van dit specifieke incident, geen bewijs dat het responsmodel toekomstbestendig is.

Wij voeren beveiligingsreviews uit op Vercel-teams, Google Workspaces en SaaS-to-SaaS-identiteitsgraphs als onderdeel van elk beheerd engagement bij webvise. Als u een extern paar ogen op uw configuratie wilt voordat de volgende disclosure in een weekend valt, start dan een gesprek.