Vercel gehackt (april 2026): Het 60-minuten noodplan dat elke developer vandaag moet uitvoeren

Op 19 april 2026 bevestigde Vercel dat aanvallers een derde-partij AI-tool (Context.ai) hebben gecompromitteerd, het Google Workspace-account van een Vercel-medewerker hebben overgenomen en omgevingsvariabelen hebben gelezen die niet als "gevoelig" waren gemarkeerd in een beperkt aantal klantprojecten. Als u de afgelopen 30 dagen iets op Vercel hebt gedeployed, moet u ervan uitgaan dat een van uw env-vars mogelijk al in verkeerde handen is — en u moet snel handelen.

De ongemakkelijke waarheid: de meeste vibe-coders zetten .env-waarden direct vanuit een template in productie zonder ooit de "Gevoelig"-schakelaar aan te raken. Dat is precies de categorie variabelen die de aanvaller heeft gelezen. Dit plan begeleidt u door de komende 60 minuten — wat u moet controleren, wat u moet roteren en hoe u uw stack kunt beveiligen zodat het volgende platform-lek uw app niet onderuit haalt.

TL;DR: Wat u in de komende 60 minuten moet doen

Als u niets anders leest, doe dan nu deze zes dingen:

1. Pauzeer auto-deploys op uw productiebranches.
2. Voer vercel env pull uit en doorzoek de uitvoer op secretpatronen (sk_live_, AKIA, ghp_, eyJ).
3. Roteer elke API-sleutel die is opgeslagen als niet-gevoelige omgevingsvariabele — begin met betalings-, database-, authenticatie- en cloudprovidersleutels.
4. Voeg geroteerde secrets opnieuw toe met de "Gevoelig"-schakelaar van Vercel, en deployer opnieuw.
5. Open uw Vercel-activiteitenlog voor 1–20 april en markeer elk deployment, elke login of elk tokengebeurtenis dat u niet herkent.
6. Controleer het auditlog van uw GitHub-organisatie voor dezelfde periode — nieuwe PATs, deployssleutels of workflowwijzigingen.

Hieronder vindt u de volledige uitleg, met de commando's, patronen en rotatievolgorde die u nodig heeft.

Wat er daadwerkelijk is gebeurd bij het Vercel-lek van april 2026

Vercel maakte op 19 april 2026 bekend dat een aanvaller Context.ai heeft gecompromitteerd, een derde-partij AI-productiviteitstool die werd gebruikt door een Vercel-medewerker. Vanaf daar nam de aanvaller het Google Workspace-account van de medewerker over, drong hij de interne omgeving van Vercel binnen en kreeg hij toegang tot omgevingsvariabelen die niet als "gevoelig" waren gemarkeerd.

Variabelen die als "gevoelig" zijn gemarkeerd, gebruiken een apart versleuteld leespad, en Vercel stelt dat er geen bewijs is dat deze zijn blootgesteld. Al het andere — gewone env-vars met API-sleutels, database-URL's, JWT-secrets — was leesbaar. Een post op een cybercrimeforum beweert Vercel-gegevens te verkopen voor 2 miljoen dollar, hoewel Vercel geen exfiltratie heeft bevestigd. In elk geval is de veilige aanpak om voor rotatiedoeleinden van een compromittering uit te gaan, ook als Vercel u niet direct heeft gemaild.

Het bedrijf beoordeelde de aanvaller als "uiterst geavanceerd op basis van zijn operationele snelheid en gedetailleerde kennis van Vercel's systemen." Vertaling: dit was geen script-kiddie — neem de klok serieus.

Bent u getroffen? Controleer in 5 minuten

Kort antwoord: als u Vercel gebruikt en u niet consequent de "Gevoelig"-schakelaar heeft gebruikt, behandel uzelf dan als getroffen. Hier is de triage van 5 minuten:

• Open het Vercel-activiteitenlog en filter van 1 april 2026 tot nu. Zoek naar onbekende logins, tokenaanslagen of deployments.
• Ga naar Google Workspace Admin → Beveiliging → API-controles en zoek naar de gepubliceerde indicator of compromise: OAuth-client-ID 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com. Als deze is geautoriseerd, trek die dan onmiddellijk in.
• Controleer of iemand in uw team ooit via Google SSO heeft ingelogd op Context.ai. Zo ja, behandel hun accounts als verhoogd risico.
• Bekijk het tabblad Omgevingsvariabelen van uw Vercel-project. Tel hoeveel er NIET als "Gevoelig" zijn gemarkeerd. Elk van die variabelen is in de gevarenzone.

Als u een e-mail van Vercel heeft ontvangen die begint met "We identified a security incident affecting your account" — u bevindt zich in de bevestigd-getroffen groep. Sla direct over naar de rotatiesectie en begin NU.

Het 60-minuten noodresponsplan

De volgorde is gebaseerd op de impact. Sla geen stappen over — elke stap maakt de volgende mogelijk.

Stap 1: De omgeving bevriezen (eerste 10 minuten)

Stop de bloeding voordat u begint met forensisch onderzoek:

• Pauzeer auto-deploys op main/production-branches (Vercel Dashboard → Project → Instellingen → Git).
• Schakel de Vercel GitHub App tijdelijk uit op github.com/organizations/<uw-org>/settings/installations als u een diepere compromittering vermoedt.
• Exporteer uw Vercel-auditlog naar een CSV en sla dit lokaal op. U heeft dit nodig als dit later een AVG-meldingsplichtig incident wordt.
• Schakel Observability Plus in (ook een proefweek) zodat u uitgebreide logs behoudt.

Dit is de stap "bewijs bewaren". Roteren vóór u een logsnap shot maakt, vernietigt uw tijdlijn.

Stap 2: Env-vars ophalen en scannen op secrets

Open uw terminal en voer uit:

vercel link
vercel env pull .env.vercel-audit

Scan vervolgens de uitvoer. De snelste manier is de CLI van GitGuardian:

ggshield secret scan path .env.vercel-audit

Als u niets wilt installeren, gebruik dan grep met deze patronen — ze detecteren 80% van gelekte secrets in env-bestanden:

grep -E "AKIA[0-9A-Z]{16}|sk_live_[0-9a-zA-Z]{24}|ghp_[0-9a-zA-Z]{36}|ghs_[0-9a-zA-Z]{36}|npm_[0-9a-zA-Z]{36}|eyJ[a-zA-Z0-9_-]+|-----BEGIN" .env.vercel-audit

Elke overeenkomst is een rotatiekandidaat. Elk niet-overeenkomend secret dat toch een credential is (database-URL's, Redis-wachtwoorden, webhook-signeringssleutels) is OOK een rotatiekandidaat — grep vangt alleen het voor de hand liggende.

Stap 3: Secrets roteren in prioriteitsvolgorde (niet alfabetisch)

Hier gaan de meeste teams de mist in. Ze roteren 40 secrets in willekeurige volgorde, een sessiesleutel invalideert alle actieve logins en supporttickets stromen binnen. Doe het in niveaus:

Tier 0 — Roteren in de komende 30 minuten:

• Alle GitHub Personal Access Tokens (fijnmazig en klassiek)
• Alle bestaande Vercel gevoelige env-var-tokens
• Deployment Protection-tokens

Tier 1 — Vandaag roteren:

• Geheime sleutels van betalingsverwerkers (Stripe sk_live_, Adyen, Braintree)
• AUTH_SECRET, NEXTAUTH_SECRET, JWT-signeringssleutels, sessiecookies
• Databaseverbindingsstrings met schrijftoegang (DATABASE_URL, Mongo, Redis)
• Cloudprovidersleutels (AWS IAM, GCP-serviceaccounts, Azure-clientsecrets)
• Webhook-signeringsecrets (bijwerken aan zender- EN ontvangerskant)

Tier 2 — Deze week roteren:

• Derde-partij SaaS-sleutels (e-mail, sms, analytics, CRM)
• OAuth-clientsecrets
• SMTP-referenties, CDN-sleutels

Tier 3 — Roteren wanneer het uitkomt:

• Alleen-lezen analyticstoken, Sentry-DSN's, publieke/anonieme sleutels

Kritieke volgorde van handelingen:

• Voor databases: maak de nieuwe gebruiker aan voordat de oude wordt ingetrokken, anders haalt u de site offline tijdens de rotatie.
• Voor sessiesleutels: plan een uitloggebeurtenis — alle actieve sessies worden ongeldig.
• Voor webhooks: werk beide kanten bij in hetzelfde deployvenster.
• Deployer opnieuw na elke wijziging van een omgevingsvariabele. Vercel bakt waarden in tijdens het bouwen, niet tijdens de uitvoering.

Stap 4: Alles opnieuw toevoegen als "Gevoelig"

Wanneer u de nieuwe waarden terugplaatst, zet de "Gevoelig"-schakelaar aan voor elke variabele. Gevoelige waarden gebruiken een apart versleuteld pad en zijn, volgens Vercel's eigen bulletin, in dit incident niet blootgesteld. Dit is de éénklik-wijziging die de meeste getroffen klanten had kunnen beschermen.

Stap 5: Uw repository controleren op ongewenste wijzigingen

Vergelijk HEAD op uw hoofdbranch met een bekende goede commit van vóór 1 april. Focusseer op:

• package.json-scripts — met name postinstall, prepare, preinstall
• Lockfiles (package-lock.json, pnpm-lock.yaml) voor onverwachte nieuwe afhankelijkheden
• .github/workflows/*.yml voor nieuwe workflows of niet-gepinde actions
• vercel.json voor wijzigingen in buildcommando's of verdachte redirects
• next.config.js voor nieuwe headers of redirects naar onbekende domeinen

Als u npm-pakketten publiceert, voer dan ook npm view <pkg> time --json uit en controleer of niets is gepubliceerd zonder uw toedoen.

Stap 6: Downstream jagen

Aanvallers stoppen niet bij env-vars — ze gebruiken ze. Query uw downstream-systemen voor de periode vanaf 1 april:

• AWS CloudTrail: onverwachte CreateUser, AttachUserPolicy, S3 GetObject-bursts, logins vanuit nieuwe IP-adressen.
• Database-auditlogs: grote SELECT *-query's, exports, verbindingen vanuit ongebruikelijke regio's.
• Stripe / Adyen: nieuwe API-sleutels, verdachte terugbetalingen, klantaanslagen vanuit vreemde locaties.
• Auth-provider: impossible-travel-logins, onbevoegde wachtwoordresets, nieuwe OAuth-apps.

Een treffer hier verandert dit van een rotatieoefen in een daadwerkelijk incident — escaleer en overweeg uw meldingsverplichtingen (AVG: 72 uur).

Wat "vibe-coders" missen: het verborgen aanvalsoppervlak

Als u heeft leren coderen met AI-tools — zoals Claude Code, Cursor of Copilot — heeft u waarschijnlijk uw eerste Vercel-app gedeployed voordat u ooit een beveiligingsdocument heeft gelezen. Dat is begrijpelijk. Maar er zijn vier verborgen valkuilen die vibe-coders harder treffen dan ervaren developers:

1. De NEXT_PUBLIC_-valkuil. Alles met het voorvoegsel NEXT_PUBLIC_ wordt gebundeld in de client-JavaScript. Als u daar "even ter test" een API-sleutel in heeft gezet, was die al publiek vóór het lek. Doorzoek uw builduitvoer: grep -rE "sk_|AKIA|eyJ" .next/static/.
2. Het Linear/Slack-lek. Als uw team secrets "even" in Linear-issues of Slack-threads plakt, liggen die secrets in derde-partijlogs. Controleer uw Linear-auditlog en zoek op dezelfde regexpatronen.
3. De aanname van .env.local in een privérepository. Privérepositories zijn niet privé als uw Vercel GitHub App is gecompromitteerd. Elk gecommit .env.*-bestand is in de gevarenzone.
4. Preview-deploys met productiesecrets. De meeste vibe-coders hergebruiken productie-env-vars voor previewomgevingen. Dat verdubbelt uw aanvalsoppervlak. Scheid deze.

Dit is het saaie infrastructuurwerk dat AI-codeertools overslaan. De oplossing is niet stoppen met AI — het is AI-snelheid combineren met een beveiligingsbasis. Als u nog uitzoekt waar uw app überhaupt draait, zijn onze Vercel vs. Netlify-vergelijking en Railway vs. Render vs. Fly.io-overzicht goede startpunten.

Hoe u uw stack beveiligt zodat het volgende lek u niet raakt

Platformlekken zijn een wanneer, geen of. Dit is de basis die elke productie-app voor maandag op orde moet hebben:

• Standaard elke nieuwe env-var op "Gevoelig" zetten in Vercel. Maak het een gewoonte van uw team.
• Kortlevende credentials gebruiken. Vervang langlevende AWS/GCP-sleutels door GitHub OIDC-federatie — uw cloudprovider vertrouwt de CI-identiteit direct, geen langlevend secret dat kan lekken.
• Pre-commit secretscanning installeren (gitleaks, Trufflehog). Voorkomt dat secrets überhaupt in de repository terechtkomen.
• Uw GitHub App beperken tot specifieke repositories, niet org-breed.
• Kwartaalreview van OAuth-apps voor Google Workspace, Microsoft 365, GitHub en Vercel. Verwijder alles wat u niet herkent.
• **Secretscans uitvoeren als **Claude Code-hook — deterministische pre-commit-handhaving ook als de AI het vergeet.
• Uw Next.js-versie pinnen en advisories bijhouden. Vercel is de primaire Next.js-beheerder, dus incidenten hier hebben een cascade-effect.
• Uw backend-secrets segmenteren. Als u Supabase of Firebase gebruikt, gebruik dan row-level security en service-rolesleutels spaarzaam — een gelekte service-sleutel is een volledige database-compromittering.

Hulp nodig bij het beveiligen? Zo past Techsy daarin

Dit is het eerlijke aanbod: de meeste kleine teams hebben geen security-engineer, en een 60-stappen incidentresponsplan lezen om 2 uur 's nachts is niet de manier waarop iemand zijn maandag wil doorbrengen.

Bij Techsy hebben we de afgelopen twee jaar incidentrespons en platformbeveiliging uitgevoerd voor meer dan 40 productie-Next.js- en Node.js-apps. Voor het Vercel-incident specifiek bieden we aan:

• 72-uur noodrespons — Wij voeren de Tier 0/Tier 1-rotatie uit, scannen uw env-vars tegen 200+ secrethandtekeningen en auditeren uw Vercel-, GitHub- en cloudlogs van begin tot eind. Typische doorlooptijd: één werkdag.
• Platformbeveiligingsaudit — Migratie naar gevoelige variabelen, OIDC-credentialrotatie, pre-commit secretscanning, scoping van de GitHub App en een geschreven runbook zodat uw toekomstige zelf weet wat te doen tijdens het volgende incident.
• Doorlopend DevSecOps — Kwartaalreview van OAuth, continue secretscanning en incidentoefeningen zodat "dat overkomt ons niet" een claim wordt die u daadwerkelijk kunt onderbouwen.

Wij zijn engineers, geen checkbox-beveiligingsleverancier. Als u nu in paniek bent, neem contact op voor een gratis triage-call van 30 minuten — we vertellen u eerlijk of u ons nodig heeft of dat u het met het bovenstaande plan zelf kunt afhandelen.

Veelgestelde vragen

Is de Vercel-hack bevestigd of alleen een gerucht?

Bevestigd. Vercel publiceerde op 19 april 2026 een officieel beveiligingsbulletin, waarbij ongeautoriseerde toegang via een gecompromitteerd derde-partij AI-tool (Context.ai) en een gekaapt Google Workspace-account van een medewerker werd erkend. Omgevingsvariabelen die niet als "gevoelig" waren gemarkeerd, zijn benaderd. Een apart BreachForums-bericht beweert de gegevens te verkopen voor 2 miljoen dollar; dat deel is niet geverifieerd.

Ik heb geen e-mail van Vercel ontvangen. Ben ik veilig?

Waarschijnlijk, maar "waarschijnlijk" is geen beveiligingshouding. Vercel zei contact te hebben opgenomen met de beperkte groep klanten met bevestigde impact. Als uw e-mail niet is aangekomen, is uw risico lager — maar alle niet-gevoelige env-vars op het Vercel-platform bevonden zich in de gevarenzone. Voer de triage van 10 minuten toch uit.

Wat is het verschil tussen "gevoelige" en gewone env-vars in Vercel?

"Gevoelige" omgevingsvariabelen gebruiken een apart versleuteld leespad en kunnen na aanmaak niet worden ingezien in het dashboard. Gewone env-vars zijn leesbaar voor iedereen met projecttoegang (inclusief, in dit incident, de aanvaller). De oplossing is gratis en kost één klik per variabele.

Moet ik ALLE secrets roteren, of alleen die op Vercel?

Roteer elk secret dat is opgeslagen in een niet-gevoelige Vercel-env-var. Als u dezelfde sleutel elders heeft gebruikt (een veelvoorkomend anti-patroon), roteer deze dan overal. Vergeet niet .env.local in preview-deployments, CI-systemen zoals GitHub Actions en eventuele geplakte verwijzingen in Linear of Slack.

Hoe scan ik mijn env-vars snel op echte secrets?

Voer vercel env pull .env.audit uit, dan ggshield secret scan path .env.audit. Als u GitGuardian niet kunt installeren, gebruik dan de grep-eenregel uit stap 2 van het plan — het detecteert AWS-sleutels, Stripe-sleutels, GitHub-tokens, npm-tokens, JWT's en PEM-blokken.

Moet ik na dit incident overstappen van Vercel?

Niet alleen vanwege dit incident. Vercel's reactie — publieke IoC, tijdlijn, rotatiebegeleiding — was redelijk transparant. Elk platform zal ooit een lek hebben. Wat telt, is of u erop bent ingericht: gevoelige variabelen als standaard, kortlevende credentials, gesegmenteerde omgevingen. Als u toch alternatieven overweegt, behandelen onze artikelen Vercel vs. Netlify en Railway vs. Render vs. Fly.io de afwegingen.

Hoelang heb ik om klanten te informeren als ik getroffen ben?

De AVG geeft u 72 uur vanaf het moment van bekendheid met een meldingsplichtig lek. Californië (CCPA) heeft dataklasspecifieke triggers. SOC 2/ISO 27001-contracten vereisen vaak vroegere melding dan toezichthouders. Als u betalende klanten heeft en exfiltratie van hun gegevens bevestigt, ga dan uit van een 72-uursklok en raadpleeg juridisch advies voordat u iets verstuurt.

Kunnen Next.js-apps via dit worden aangevallen, ook als ik niet op Vercel zit?

Het incident is Vercel-platformspecifiek. Next.js zelf, elders gehost, is niet getroffen door het aanvalsmechanisme. Maar als u dezelfde NEXT_PUBLIC_-env-varpatronen heeft gebruikt die per ongeluk secrets blootstellen, reizen die problemen mee met uw code, ongeacht de host. Auditeer uw builduitvoer hoe dan ook.

Wat is de eénklik-fix die het meeste schade had voorkomen?

Elke credential-bevattende env-var van dag één als "Gevoelig" markeren in Vercel. Het is een selectievakje in het dashboard. In dit incident zijn gevoelige variabelen NIET benaderd — alleen gewone. Dat is de oplossing, en het kost nul euro en ongeveer vijf minuten per project.

Hoe zorg ik ervoor dat mijn team nooit meer een ongemarkeerd secret aflevert?

Drie lagen: (1) pre-commit secretscanning met gitleaks, (2) een CI-check die faalt als een env-var wordt toegevoegd zonder de sensitive: true-vlag via de Vercel-API, en (3) een Claude Code-hook die de scanner bij elke bewerking uitvoert. Defense in depth — elk van de drie detecteert 80%, alle drie samen ~99%.

De conclusie

Het Vercel-lek van april 2026 is ernstig, maar te overleven — als u zich in de komende 60 minuten beweegt. Deployen bevriezen, env-vars ophalen, grep uitvoeren, in niveaus roteren, opnieuw toevoegen als gevoelig en downstream onderzoeken. Dat is het complete plan.

Platformlekken onthullen hoezeer we op standaardinstellingen vertrouwen. De meeste teams die hier zijn geraakt, hebben niets verkeerd gedaan — ze hebben gewoon de "Gevoelig"-schakelaar niet ingeschakeld omdat niemand ze had verteld dat het belangrijk was. Dat is de echte les voor vibe-coders: AI-gegenereerde code wordt snel geleverd, maar beveiligingsstandaarden komen niet mee met de generatie.

Als u een tweede paar ogen op uw stack wilt, of liever dit plan niet alleen om 2 uur 's nachts uitvoert, boek een gratis triage-call met het Techsy-team. Anders — veel succes, handel snel en markeer die variabelen als gevoelig.