Vercel blev hacket (april 2026): Den 60-minutters nødplan, som alle udviklere skal køre i dag

Vercel blev hacket (april 2026): Den 60-minutters nødplan, som alle udviklere skal køre i dag

Den 19. april 2026 bekræftede Vercel, at angribere havde kompromitteret et tredjeparts AI-værktøj (Context.ai), kapret en Vercel-ansats Google Workspace-konto og læst miljøvariabler, der ikke var markeret som "følsomme", på tværs af en begrænset delmængde af kundeprojekter. Hvis du har deployet noget til Vercel i løbet af de sidste 30 dage, skal du antage, at en af dine miljøvariabler allerede er på andres hænder, og du skal handle hurtigt.

Her er den ubehagelige sandhed: De fleste vibecoders sender .env-værdier direkte fra en skabelon uden nogensinde at røre ved "følsom"-kontakten. Det er netop den type variabel, angriberen læste. Denne plan guider dig gennem de næste 60 minutter, hvad du skal tjekke, hvad du skal rotere, og hvordan du hærdner din stack, så det næste platformbrud ikke nedbryder din app.

TL;DR: Hvad du skal gøre i de næste 60 minutter

Hvis du ikke læser andet, så gør disse seks ting lige nu:

1. Sæt auto-deployments på pause på dine produktionsgrene.
2. Kør vercel env pull og grep outputtet for mønstre for hemmeligheder (sk_live_, AKIA, ghp_, eyJ).
3. Rotér hver eneste API-nøgle, der er gemt som en ikke-følsom miljøvariabel, start med betalinger, database, auth og cloud-provider nøgler.
4. Tilføj de roterede hemmeligheder igen ved hjælp af Vercels "Sensitive" miljøvariabel-kontakt, og deploy derefter igen.
5. Åbn din Vercel-aktivitetslog for perioden 1.–20. april og flag enhver deployment, login eller token-hændelse, du ikke genkender.
6. Gennemgå din GitHub-org revisionslog for samme periode, nye PATs, deploy-nøgler eller workflow-ændringer.

Nedenfor finder du den fulde gennemgang med de kommandoer, mønstre og rotationsrækkefølge, du får brug for.

Hvad skete der egentlig i Vercel-bruddet i april 2026?

Vercel offentliggjorde den 19. april 2026, at en angriber havde kompromitteret Context.ai, et tredjeparts AI-produktivitetsværktøj brugt af en Vercel-ansat. Derfra overtog angriberen den ansattes Vercel Google Workspace-konto, bevægede sig ind i Vercels interne miljø og fik adgang til miljøvariabler, der ikke var markeret som "følsomme".

Variabler markeret som "følsomme" bruger en separat krypteret læsesti, og Vercel siger, at der ikke er beviser for, at disse blev eksponeret. Alt andet, almindelige miljøvariabler, der gemmer API-nøgler, database-URL'er, JWT-hemmeligheder, var læsbare. Et opslag på et cyberkriminel forum har siden hævdet at sælge Vercel-data for $2 millioner, selvom Vercel ikke har bekræftet dataudtrækning. Uanset hvad er det sikre træk at antage kompromittering med henblik på rotation, selv hvis Vercel ikke har mailt dig direkte.

Virksomheden vurderede angriberen som "meget sofistikeret baseret på deres operationelle hastighed og detaljerede forståelse af Vercels systemer." Oversat: Dette var ikke en script kiddie, tag tiden alvorligt.

Er du berørt? Sådan tjekker du det på 5 minutter

Kort svar: Hvis du bruger Vercel, og du ikke har været omhyggelig med "Sensitive"-kontakten, skal du betragte dig selv som berørt. Her er 5-minutters triagen:

• Åbn Vercels aktivitetslog og filtrer fra 1. april 2026 til nu. Kig efter ukendte logins, oprettelser af tokens eller deployments.
• Gå til Google Workspace Admin → Sikkerhed → API-kontrol og søg efter den offentliggjorte indikator for kompromittering: OAuth client ID 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com. Hvis den er autoriseret, skal du straks ophæve den.
• Tjek om nogen på dit hold nogensinde har logget ind på Context.ai ved hjælp af Google SSO. Hvis ja, skal deres konti behandles som højere risiko.
• Kig på fanen Miljøvariabler i dit Vercel-projekt. Tæl hvor mange der IKKE er markeret som "Følsomme". Hver enkelt af disse er omfattet.

Hvis du har modtaget en e-mail fra Vercel, der starter med "Vi har identificeret en sikkerhedshændelse, der påvirker din konto", er du i gruppen af bekræftet berørte. Spring til rotationssektionen og start NU.

Den 60-minutters nødresponsplan

Dette er ordnet efter skadesomfang. Spring ikke trin over, hvert trin låser op for det næste.

Trin 1: Frys miljøet (første 10 minutter)

Stop blødningen, før du starter forensikken:

• Sæt auto-deployments på pause på main / production grene (Vercel Dashboard → Projekt → Indstillinger → Git).
• Deaktiver midlertidigt Vercel GitHub App på github.com/organizations/<din-org>/settings/installations, hvis du mistænker dybere kompromittering.
• Eksporter din Vercel-revisionslog til en CSV-fil og gem den lokalt. Du får brug for den, hvis dette udvikler sig til en GDPR-anmeldelsespligtig hændelse senere.
• Aktiver Observability Plus (selv en prøveuge), så du beholder udvidede logs.

Dette er trinnet "bevar beviserne". Rotation før du tager et snapshot af loggen ødelægger din tidslinje.

Trin 2: Hent miljøvariabler og scan dem for hemmeligheder

Åbn din terminal og kør:

vercel link
vercel env pull .env.vercel-audit

Scan derefter outputtet. Den hurtigste måde er GitGuardians CLI:

ggshield secret scan path .env.vercel-audit

Hvis du ikke vil installere noget, kan du greppe efter disse mønstre, de fanger 80 % af lækagede hemmeligheder i env-filer:

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

Hvert match er en rotationskandidat. Hver umatchet hemmelighed, der stadig er en legitimationsoplysning (DB-URL'er, Redis-adgangskoder, webhook-signeringsnøgler), er OGSÅ en rotationskandidat; greppet fanger bare de åbenlyse ting.

Trin 3: Rotér hemmeligheder i prioritetsorden (ikke alfabetisk)

Her laver de fleste teams fejl. De roterer 40 hemmeligheder i tilfældig rækkefølge, en sessionsnøgle invalidierer alle aktive logins, og supportbilletterne eksploderer. Gør det i niveauer:

Niveau 0 — Rotér inden for de næste 30 minutter:

• Alle GitHub Personal Access Tokens (fin-granulære og klassiske)
• Alle eksisterende Vercel følsomme env-var tokens
• Deployment Protection tokens

Niveau 1 — Rotér i dag:

• Betalingsprocessor hemmelige nøgler (Stripe sk_live_, Adyen, Braintree)
• AUTH_SECRET, NEXTAUTH_SECRET, JWT-signeringsnøgler, session cookies
• Database-forbindelsesstrenge med skriveadgang (DATABASE_URL, Mongo, Redis)
• Cloud-provider nøgler (AWS IAM, GCP service accounts, Azure client secrets)
• Webhook-signeringshemmeligheder (opdater både hos afsender OG modtager)

Niveau 2 — Rotér i denne uge:

• Tredjeparts SaaS-nøgler (e-mail, SMS, analytics, CRM)
• OAuth client secrets
• SMTP-legitimationsoplysninger, CDN-nøgler

Niveau 3 — Rotér når det passer:

• Read-only analytics tokens, Sentry DSNs, offentlige/anonyme nøgler

Kritisk rækkefølge for operationer:

• For databaser: Opret den nye bruger før du inddrager den gamle, ellers tager du sitet ned midt i rotationen.
• For sessionsnøgler: Planlæg en logout-hændelse, hver aktiv session dør.
• For webhooks: Opdater begge sider i samme deploy-vindue.
• Deploy igen efter hver ændring af miljøvariabler. Vercel bager værdier ind ved build-tid, ikke runtime.

Trin 4: Tilføj alt igen som "Følsomt"

Når du putter de nye værdier tilbage, skal du slå "Sensitive"-kontakten til for hver enkelt. Følsomme værdier bruger en separat krypteret sti og blev, ifølge Vercels egen bulletin, ikke eksponeret i denne hændelse. Dette er one-click-ændringen, der ville have reddet de fleste berørte kunder.

Trin 5: Revider dit repo for uønskede ændringer

Sammenlign HEAD på din main-gren med en kendt-good commit fra før 1. april. Fokusér på:

• package.json scripts, især postinstall, prepare, preinstall
• Lockfiles (package-lock.json, pnpm-lock.yaml) for uventede nye dependencies
• .github/workflows/*.yml for nye workflows eller upinned actions
• vercel.json for ændringer i build-kommandoer eller mistænkelige rewrites
• next.config.js for nye headers eller redirects, der peger på ukendte domæner

Hvis du publicerer npm-pakker, skal du også køre npm view <pkg> time --json og verificere, at der ikke er shipped noget, du ikke har authoriseret.

Trin 6: Jagt downstream

Angribere stopper ikke ved miljøvariabler, de bruger dem. Query dine downstream-systemer for vinduet 1. april–nu:

• AWS CloudTrail: Uventede CreateUser, AttachUserPolicy, S3 GetObject bursts, logins fra nye IPs.
• Database revisionslogs: Store SELECT * queries, exports, forbindelser fra usædvanlige regioner.
• Stripe / Adyen: Nye API-nøgler, mistænkelige refunderinger, oprettelse af kunder fra underlige lokationer.
• Auth provider: Umulige rejse-logins, uautoriserede nulstillinger af adgangskode, nye OAuth apps.

Ethver hit her vender dette fra en rotationsøvelse til en faktisk hændelse, eskaler og overvej anmeldelsespligt (GDPR: 72 timer).

Hvad "Vibecoders" overser: Den skjulte angrebsflade

Hvis du er kommet ind i kodning via AI-assisterede værktøjer, som Claude Code, Cursor eller Copilot, har du sandsynligvis shipped din første Vercel-app, før du nogensinde læste en sikkerhedsdokumentation. Det er fint. Men der er fire faldgruber, der rammer vibecoders hårdere end erfarne udviklere:

1. NEXT_PUBLIC_ foden. Alt med præfikset NEXT_PUBLIC_ bliver bundlet ind i klientens JavaScript. Hvis du stak en API-nøgle derind "bare for at teste", var den allerede offentlig før bruddet. Grep dit build-output: grep -rE "sk_|AKIA|eyJ" .next/static/.
2. Linear / Slack-lækaget. Hvis dit team indsætter hemmeligheder i Linear-issues eller Slack-tråde "bare for et sekund", sidder disse hemmeligheder i tredjeparts logs. Gennemgå din Linear revisionslog og søg efter de samme regex-mønstre som ovenfor.
3. Antagelsen om .env.local i private repos. Private repos er ikke private, hvis din Vercel GitHub App blev kompromitteret. Hver committet .env.* fil er omfattet.
4. Preview deployments med prod-hemmeligheder. De fleste vibecoders genbruger produktions-env-vars til preview-miljøer. Det fordobler din angrebsflade. Adskil dem.

Dette er det kedelige infrastrukturarbejde, som AI-kodningsværktøjer springer over. Løsningen er ikke at stoppe med at bruge AI, det er at parre AI-hastighed med et sikkerhedsbaseline. Hvis du stadig finder ud af, hvor din app overhovedet lever, er vores Vercel vs Netlify sammenligning og Railway vs Render vs Fly.io gennemgang gode startpunkter.

Sådan hærdner du din stack, så det næste brud ikke brænder dig

Platformbrud er et når, ikke et hvis. Her er baseline, som enhver produktionsapp bør have på plads inden mandag:

• Sæt standarden for hver ny env-var til "Følsom" i Vercel. Gør det til dit teams muskelhukommelse.
• Brug kortlivede legitimationsoplysninger. Byt langlivede AWS/GCP-nøgler ud med GitHub OIDC federation, din cloud-provider stoler direkte på CI-identiteten, ingen langlivet hemmelighed at lække.
• Installer pre-commit hemmelighedsscanning (gitleaks, Trufflehog). Stopper hemmeligheder fra at komme ind i repoet i første omgang.
• Begræns din GitHub App til specifikke repos, ikke org-wide.
• Kvartalsvis OAuth app-gennemgang på tværs af Google Workspace, Microsoft 365, GitHub og Vercel. Dræb alt, du ikke genkender.
• Kør hemmelighedsscans som en Claude Code hook, deterministisk pre-commit håndhævelse, selv når AI'en glemmer det.
• Pin din Next.js version og overvåg advisories. Vercel er den primære Next.js steward, så hændelser her kaskaderer.
• Segmentér dine backend-hemmeligheder. Hvis du bruger Supabase eller Firebase, brug row-level security og service-role nøgler sparsomt, en lækket service-nøgle er en fuld DB-kompromittering.

Brug for hjælp til at låse dette ned? Sådan passer Techsy ind

Her er det ærlige pitch: De fleste små teams har ikke en security engineer, og at læse en 60-trins hændelsesresponsplan kl. 2 om natten er ikke sådan, nogen ønsker at bruge deres mandag.

Hos Techsy har vi kørt hændelsesrespons og platformhærdning for 40+ produktions Next.js og Node.js apps over de sidste to år. Specifikt for Vercel-hændelsen tilbyder vi:

• 72-timers nødrespons, Vi eksekverer Niveau 0 / Niveau 1 rotation, scanner dine env-vars mod 200+ hemmelighedssignaturer og reviderer dine Vercel + GitHub + cloud logs end-to-end. Typisk turnaround: én arbejdsdag.
• Platformhærdningsaudit, Migration af følsomme variabler, OIDC credential rotation, pre-commit hemmelighedsscanning, GitHub App scoping og en skriftlig runbook, så dit fremtidige jeg ved, hvad der skal gøres under det næste brud.
• Løbende DevSecOps, Kvartalsvise OAuth-gennemgange, kontinuerlig hemmelighedsscanning og hændelsesdrills, så "det sker ikke for os" bliver en påstand, du faktisk kan bakke op.

Vi er ingeniører, ikke en checkbox-sikkerhedsleverandør. Hvis du panikker lige nu, kontakt os for en gratis 30-minutters triage-opkald, vi vil ærligt fortælle dig, om du har brug for os, eller om du kan håndtere det med planen ovenfor.

Ofte stillede spørgsmål

Er Vercel-hacket bekræftet som ægte eller bare et rygte?

Bekræftet. Vercel publicerede en officiel sikkerhedsbulletin den 19. april 2026, hvor de anerkendte uautoriseret adgang via et kompromitteret tredjeparts AI-værktøj (Context.ai) og en kapret medarbejder Google Workspace-konto. Miljøvariabler, der ikke var markeret som "følsomme", blev tilgået. Et separat BreachForums-opslag hævder at sælge dataene for $2M; den del er ubekræftet.

Jeg fik ikke en e-mail fra Vercel. Er jeg sikker?

Sandsynligvis, men "sandsynligvis" er ikke en sikkerhedsstrategi. Vercel sagde, at de kontaktede den begrænsede delmængde af kunder med bekræftet impact. Hvis din e-mail ikke ankom, er din risiko lavere, men hver ikke-følsom env-var på tværs af Vercels platform var i skadesområdet. Gør alligevel 10-minutters triagen ovenfor.

Hvad er forskellen mellem "følsomme" og almindelige env-vars i Vercel?

"Følsomme" miljøvariabler bruger en separat krypteret læsesti og kan ikke ses i dashboardet efter oprettelse. Almindelige env-vars er læsbare for alle med projektadgang (herunder, i denne hændelse, angriberen). Løsningen er gratis og tager ét klik per variabel.

Skal jeg rotere ALLE mine hemmeligheder, eller kun dem på Vercel?

Rotér hver hemmelighed, der er gemt i en ikke-følsom Vercel env-var. Hvis du brugte den samme nøgle andre steder (en almindelig anti-pattern), skal du rotere den overalt. Glem ikke .env.local i preview deployments, CI-systemer som GitHub Actions og eventuelle indsatte referencer i Linear eller Slack.

Hvordan scanner jeg mine env-vars for faktiske hemmeligheder hurtigt?

Kør vercel env pull .env.audit og derefter ggshield secret scan path .env.audit. Hvis du ikke kan installere GitGuardian, brug grep-one-lineren i Trin 2 i planen, den fanger AWS-nøgler, Stripe-nøgler, GitHub tokens, npm tokens, JWTs og PEM-blokke.

Bør jeg skifte væk fra Vercel efter dette?

Ikke på grund af denne hændelse alene. Vercels respons, offentlige IoC, tidslinje, rotationsvejledning, har været rimeligt transparent. Enhver platform vil opleve et brud på et tidspunkt. Det, der betyder noget, er, om du har designet til det: standardindstillinger for følsomme variabler, kortlivede legitimationsoplysninger, segmenterede miljøer. Hvis du alligevel vejer alternativer, breaker vores Vercel vs Netlify og Railway vs Render vs Fly.io indlæg tradeoffs ned.

Hvor lang tid har jeg til at underrette kunder, hvis jeg er berørt?

GDPR giver dig 72 timer fra awareness af en anmeldelsespligtig hændelse. Californien (CCPA) har dataklasse-specifikke triggers. SOC 2 / ISO 27001 kontrakter kræver ofte tidligere varsling end regulatorer. Hvis du har betalende kunder, og du bekræfter udtrækning af deres data, skal du antage, at du er på en 72-timers ur og konsultere juridisk rådgivning, før du sender noget.

Kan Next.js apps angribes gennem dette, selvom jeg ikke er på Vercel?

Hændelsen er Vercel-platformspecifik. Next.js selv, hostet andetsteds, er ikke påvirket af brudmekanismen. Men hvis du brugte de samme NEXT_PUBLIC_ env-var mønstre, der utilsigtet eksponerer hemmeligheder, rejser disse problemer med din kode uanset host. Revider dit build-output under alle omstændigheder.

Hvad er the one-click fix, der ville have forhindret mest skade?

At markere hver credential-indeholdende env-var som "Følsom" i Vercel fra dag ét. Det er en checkbox i dashboardet. I denne hændelse blev følsomme variabler IKKE tilgået, kun almindelige blev det. Det er løsningen, og det koster nul dollars og cirka fem minutter per projekt.

Hvordan sikrer jeg, at mit team aldrig shipper en umarkeret hemmelighed igen?

Tre lag: (1) pre-commit hemmelighedsscanning med gitleaks, (2) et CI-tjek, der fejler, hvis en env-var tilføjes uden sensitive: true flaget via Vercel API, og (3) en Claude Code hook, der kører scanneren ved hver edit. Defense in depth, ethvert af de tre fanger 80 %, alle tre fanger ~99 %.

Bundlinjen

Vercel-april 2026 bruddet er slemt, men det er overlevelsesdygtigt, hvis du handler i de næste 60 minutter. Frys deployments, hent dine env-vars, kør greppet, rotér i niveauer, tilføj igen som følsomme, og jagt downstream. Det er hele planen.

Platformbrud afslører, hvor meget vi stole på standardindstillinger. De fleste teams, der blev såret her, gjorde intet forkert, de efterlod bare "Sensitive"-kontakten unchecked, fordi ingen fortalte dem, at det betød noget. Det er den virkelige lektie for vibecoders: AI-genereret kode shipper hurtigt, men sikkerhedsstandarder kommer ikke med generationen.

Hvis du vil have et ekstra sæt øjne på din stack, eller du hellere vil undgå at eksekvere denne plan alene kl. 2 om natten, book et gratis triage-opkald med Techsy-teamet. Ellers, held og lykke, handl hurtigt, og markér de variabler som følsomme.