Vercel ble hacket (april 2026): Den 60-minutters nødplanen alle utviklere må kjøre i dag

1. april 2026 bekreftet Vercel at angripere kompromitterte et tredjeparts AI-verktøy (Context.ai), kapret en Vercel-ansatts Google Workspace-konto og leste miljøvariabler som ikke var merket som "sensitive" i et begrenset antall kundeprosjekter. Hvis du har deployet noe til Vercel de siste 30 dagene, må du anta at en av env-varene dine kanskje allerede er i feil hender — og du må handle raskt.

Den ubehagelige sannheten: de fleste vibe-codere setter inn .env-verdier direkte fra en mal uten å noen gang røre "Sensitiv"-knappen. Det er nøyaktig den kategorien variabler angriperen leste. Denne planen guider deg gjennom de neste 60 minuttene — hva du skal sjekke, hva du skal rotere og hvordan du herder stacken din så neste plattformsbrudd ikke slår ut appen din.

TL;DR: Hva du skal gjøre de neste 60 minuttene

Leser du ingenting annet, gjør disse seks tingene nå:

1. Sett automatiske deploys på pause på produksjonsgreinene dine.
2. Kjør vercel env pull og søk i utdataene etter hemmelighetsmønstre (sk_live_, AKIA, ghp_, eyJ).
3. Roter alle API-nøkler lagret som ikke-sensitive miljøvariabler — start med betalings-, database-, autentiserings- og skyleverandørnøkler.
4. Legg til roterte hemmeligheter på nytt med "Sensitiv"-knappen i Vercel, og redeploy deretter.
5. Åpne Vercel-aktivitetsloggen din for 1.–20. april og flagg eventuelle deploys, pålogginger eller tokenhendelser du ikke kjenner igjen.
6. Gjennomgå GitHub-organisasjonens revisjonslogg for samme periode — nye PAT-er, deploynøkler eller workflow-endringer.

Nedenfor finner du den fullstendige gjennomgangen med kommandoer, mønstre og rotasjonsrekkefølge du trenger.

Hva som faktisk skjedde i Vercel-bruddet i april 2026

Vercel offentliggjorde 19. april 2026 at en angriper kompromitterte Context.ai, et tredjeparts AI-produktivitetsverktøy brukt av en Vercel-ansatt. Derfra tok angriperen kontroll over den ansattes Google Workspace-konto, pivoterte inn i Vercels interne miljø og fikk tilgang til miljøvariabler som ikke var merket som "sensitive".

Variabler merket som "sensitive" bruker en separat kryptert lesebane, og Vercel sier at det ikke finnes bevis for at disse ble eksponert. Alt annet — vanlige env-vars som lagrer API-nøkler, database-URL-er, JWT-hemmeligheter — var lesbart. Et innlegg på et cyberkriminalitetsforum hevder å selge Vercel-data for 2 millioner dollar, men Vercel har ikke bekreftet eksfiltrering. Uansett er det trygge trekket å anta kompromittering for roteringsformål, selv om Vercel ikke har sendt deg en e-post direkte.

Selskapet vurderte angriperen som "svært sofistikert basert på operasjonell hastighet og detaljert forståelse av Vercels systemer." Oversettelse: dette var ingen script kiddie — ta klokken på alvor.

Er du berørt? Sjekk på 5 minutter

Kort svar: hvis du bruker Vercel og ikke har vært nøye med "Sensitiv"-knappen, behandle deg selv som berørt. Her er 5-minutters-triagen:

• Åpne Vercels aktivitetslogg og filtrer fra 1. april 2026 til nå. Se etter ukjente pålogginger, tokenopprettelser eller deploys.
• Gå til Google Workspace Admin → Sikkerhet → API-kontroller og søk etter den publiserte kompromissens indikatoren: OAuth-klient-ID 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com. Hvis den er autorisert, tilbakekall den umiddelbart.
• Sjekk om noen på teamet ditt noen gang har logget inn på Context.ai med Google SSO. Hvis ja, behandle kontoene deres som høyere risiko.
• Se på fanen Miljøvariabler i Vercel-prosjektet ditt. Tell opp hvor mange som IKKE er merket som "Sensitiv". Hver av dem er innenfor eksplosjonsradius.

Hvis du fikk en e-post fra Vercel som starter med "We identified a security incident affecting your account" — du er i gruppen med bekreftet påvirkning. Hopp direkte til rotasjonsdelen og start NÅ.

Den 60-minutters nødresponsplanen

Rekkefølgen er bestemt av eksplosjonsradius. Ikke hopp over trinn — hvert trinn låser opp det neste.

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

Stopp blødningen før du starter kriminalteknisk analyse:

• Sett automatiske deploys på pause på main/production-greinene (Vercel Dashboard → Prosjekt → Innstillinger → Git).
• Deaktiver midlertidig Vercel GitHub-appen på github.com/organizations/<din-org>/settings/installations hvis du mistenker et dypere kompromiss.
• Eksporter Vercel-revisjonsloggen til en CSV og lagre den lokalt. Du trenger den hvis dette blir en GDPR-varslingspliktig hendelse.
• Aktiver Observability Plus (selv en prøveuke) for å beholde utvidede logger.

Dette er "bevare bevis"-trinnet. Å rotere før du tar et logg-snapshot ødelegger tidslinjen din.

Trinn 2: Hent env-varene og skann dem for hemmeligheter

Åpne terminalen og kjør:

vercel link
vercel env pull .env.vercel-audit

Skann deretter utdataene. Den raskeste måten er GitGuardians CLI:

ggshield secret scan path .env.vercel-audit

Hvis du ikke vil installere noe, bruk grep med disse mønstrene — de fanger 80 % av lekkede hemmeligheter 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 treff er en roteringskandidat. Hver ikke-matchende hemmelighet som fremdeles er en legitimasjon (database-URL-er, Redis-passord, webhook-signeringsnøkler) er OGSÅ en roteringskandidat — grep fanger bare det åpenbare.

Trinn 3: Roter hemmeligheter i prioritetsrekkefølge (ikke alfabetisk)

Her er der de fleste team gjør feil. De roterer 40 hemmeligheter i tilfeldig rekkefølge, en sesjonsnøkkel ugyldiggjør alle aktive pålogginger og supportbilletter eksploderer. Gjør det i nivåer:

Tier 0 — Roter innen de neste 30 minuttene:

• Alle GitHub Personal Access Tokens (finkornet og klassisk)
• Alle eksisterende Vercel sensitive env-var-tokens
• Deployment Protection-tokens

Tier 1 — Roter i dag:

• Hemmelige nøkler fra betalingsprosessorer (Stripe sk_live_, Adyen, Braintree)
• AUTH_SECRET, NEXTAUTH_SECRET, JWT-signeringsnøkler, sesjonskaker
• Databasetilkoblingsstrenger med skrivetilgang (DATABASE_URL, Mongo, Redis)
• Skyleverandørnøkler (AWS IAM, GCP-tjenestekontoer, Azure-klienthemmeligheter)
• Webhook-signeringshemmeligheter (oppdater hos avsender OG mottaker)

Tier 2 — Roter denne uken:

• Tredjeparts SaaS-nøkler (e-post, SMS, analyse, CRM)
• OAuth-klienthemmeligheter
• SMTP-legitimasjon, CDN-nøkler

Tier 3 — Roter når det passer:

• Skrivebeskyttede analysetoken, Sentry-DSN-er, offentlige/anonyme nøkler

Kritisk operasjonsrekkefølge:

• For databaser: opprett den nye brukeren før du tilbakekaller den gamle, ellers tar du ned nettstedet under rotering.
• For sesjonsnøkler: planlegg en utloggingshendelse — alle aktive sesjoner ugyldiggjøres.
• For webhooks: oppdater begge sider i samme deployvinduer.
• Redeploy etter hver env-var-endring. Vercel baker inn verdier på byggtidspunktet, ikke ved kjøretid.

Trinn 4: Legg alt til på nytt som "Sensitivt"

Når du legger de nye verdiene tilbake, aktiver "Sensitiv"-knappen på hver enkelt. Sensitive verdier bruker en separat kryptert bane og, ifølge Vercels eget sikkerhetsbulletin, ble ikke eksponert i denne hendelsen. Dette er enklicks-endringen som ville ha spart de fleste berørte kunder.

Trinn 5: Revidér repoet ditt for uønskede endringer

Sammenlign HEAD på hovedgreinen din med en kjent god commit fra før 1. april. Fokuser på:

• package.json-skript — spesielt postinstall, prepare, preinstall
• Låsfiler (package-lock.json, pnpm-lock.yaml) for uventede nye avhengigheter
• .github/workflows/*.yml for nye workflows eller ikke-pinnede actions
• vercel.json for byggkommandoendringer eller mistenkelige omdirigeringer
• next.config.js for nye headere eller omdirigeringer som peker til ukjente domener

Hvis du publiserer npm-pakker, kjør også npm view <pkg> time --json og verifiser at ingenting er publisert uten din forfatterskap.

Trinn 6: Jakt nedstrøms

Angripere stopper ikke ved env-vars — de bruker dem. Spør nedstrømssystemene dine for perioden fra 1. april:

• AWS CloudTrail: uventede CreateUser, AttachUserPolicy, S3 GetObject-burster, pålogginger fra nye IP-adresser.
• Databaserevisjonslogger: store SELECT *-spørringer, eksporter, tilkoblinger fra uvanlige regioner.
• Stripe / Adyen: nye API-nøkler, mistenkelige refusjoner, kundeopprettelser fra rare steder.
• Auth-leverandør: impossible-travel-pålogginger, uautoriserte passordtilbakestillinger, nye OAuth-apper.

Et treff her gjør dette om fra en rotasjonsøvelse til en faktisk hendelse — eskaler og vurder varslingsplikter (GDPR: 72 timer).

Hva "vibe-codere" går glipp av: den skjulte angrepsflaten

Hvis du lærte å kode med AI-verktøy — som Claude Code, Cursor eller Copilot — deploydde du sannsynligvis den første Vercel-appen din før du noen gang leste et sikkerhetsdokument. Det er forståelig. Men det er fire skjulte feller som treffer vibe-codere hardere enn erfarne utviklere:

1. NEXT_PUBLIC_****-fellen. Alt med prefikset NEXT_PUBLIC_ buntes inn i klient-JavaScriptet. Hvis du puttet en API-nøkkel der "bare for å teste", var den allerede offentlig før bruddet. Skann byggutdataene dine: grep -rE "sk_|AKIA|eyJ" .next/static/.
2. Linear/Slack-lekkasjen. Hvis teamet ditt limer inn hemmeligheter i Linear-saker eller Slack-tråder "bare et øyeblikk", sitter de hemmeligheter i tredjeparts logger. Gjennomgå Linear-revisjonsloggen din og søk etter de samme regex-mønstrene.
3. .env.local****-antagelsen i privat repo. Private repos er ikke private hvis Vercel GitHub-appen din ble kompromittert. Hver committede .env.*-fil er innenfor eksplosjonsradius.
4. Forhåndsvisningsdeploys med produksjonshemmeligheter. De fleste vibe-codere gjenbruker produksjons-env-vars for forhåndsvisningsmiljøer. Det fordobler angrepsflaten din. Skill dem.

Dette er det kjedelige infrastrukturarbeidet som AI-kodingsverktøy hopper over. Løsningen er ikke å slutte å bruke AI — det er å kombinere AI-hastighet med et sikkerhetsgrunnlag. Hvis du fremdeles finner ut hvor appen din faktisk bor, er vår Vercel vs. Netlify-sammenligning og Railway vs. Render vs. Fly.io-analyse gode utgangspunkter.

Hvordan du herder stacken slik at neste brudd ikke brenner deg

Plattformsbrudd er et når, ikke et om. Dette er grunnlaget alle produksjonsapper bør ha på plass innen mandag:

• Sett som standard alle nye env-vars til "Sensitiv" i Vercel. Gjør det til en vane for teamet ditt.
• Bruk kortlivede legitimasjoner. Bytt ut langlivede AWS/GCP-nøkler med GitHub OIDC-federasjon — skyleverandøren din stoler direkte på CI-identiteten, ingen langlivet hemmelighet å lekke.
• Installer hemmelighetsscanning pre-commit (gitleaks, Trufflehog). Forhindrer at hemmeligheter kommer inn i repoen fra starten av.
• Begrens GitHub-appen din til spesifikke repoer, ikke organisasjonsomfattende.
• Kvartalsvis gjennomgang av OAuth-apper på tvers av Google Workspace, Microsoft 365, GitHub og Vercel. Fjern alt du ikke kjenner igjen.
• **Kjør hemmelighetsscanning som en **Claude Code-hook — deterministisk pre-commit-håndheving selv når AI-en glemmer.
• Fest Next.js-versjonen din og overvåk sikkerhetsvarsler. Vercel er primær Next.js-ansvarlig, så hendelser her eskalerer.
• Segmenter backend-hemmeligheter. Hvis du bruker Supabase eller Firebase, bruk radsikkerhet og tjenesterollenøkler sparsomt — en lekket tjenestenøkkel er et fullstendig databasekompromiss.

Trenger du hjelp til å sikre dette? Slik passer Techsy inn

Det ærlige tilbudet: de fleste små team har ingen sikkerhetsigeniør, og å lese en 60-trinns hendelsesresponsplan klokken 2 om natten er ikke slik noen ønsker å tilbringe mandagen sin.

Hos Techsy har vi de siste to årene kjørt hendelsesrespons og plattformsherdning for mer enn 40 produksjonsprogrammer i Next.js og Node.js. For Vercel-hendelsen spesifikt tilbyr vi:

• 72-timers nødrespons — Vi kjører Tier 0/Tier 1-rotering, skanner env-varene dine mot 200+ hemmelighetssignaturer og reviderer Vercel-, GitHub- og skyloggene dine fra ende til annen. Typisk gjennomløpstid: én arbeidsdag.
• Plattformsherdningsrevisjon — Migrering til sensitive variabler, OIDC-legitimasjonsrotering, hemmelighetsscanning pre-commit, GitHub-app-scoping og en skriftlig runbook slik at fremtidig deg vet hva du skal gjøre under neste brudd.
• Løpende DevSecOps — Kvartalsvise OAuth-gjennomganger, kontinuerlig hemmelighetsscanning og hendelsesøvelser slik at "det skjer ikke oss" blir et krav du faktisk kan støtte opp om.

Vi er ingeniører, ikke en avkrysningsliste-sikkerhetsleverandør. Hvis du panikkerer akkurat nå, ta kontakt for en gratis 30-minutters triagesamtale — vi forteller deg ærlig om du trenger oss eller om du kan håndtere det med planen ovenfor.

Vanlige spørsmål

Er Vercel-hackingen bekreftet eller bare et rykte?

Bekreftet. Vercel publiserte et offisielt sikkerhetsbulletin 19. april 2026 som anerkjente uautorisert tilgang via et kompromittert tredjeparts AI-verktøy (Context.ai) og en kapret Google Workspace-konto for en ansatt. Miljøvariabler som ikke var merket som "sensitive" ble åpnet. Et separat BreachForums-innlegg hevder å selge dataene for 2 millioner dollar; den delen er ubekreftet.

Jeg fikk ingen e-post fra Vercel. Er jeg trygg?

Sannsynligvis, men "sannsynligvis" er ikke en sikkerhetsposisjon. Vercel sa at de kontaktet det begrensede underutvalget av kunder med bekreftet påvirkning. Hvis e-posten din ikke kom, er risikoen din lavere — men alle ikke-sensitive env-vars på Vercels plattform var innenfor eksplosjonsradius. Gjør 10-minutters-triagen uansett.

Hva er forskjellen mellom "sensitive" og vanlige env-vars i Vercel?

"Sensitive" miljøvariabler bruker en separat kryptert lesebane og kan ikke vises i dashbordet etter opprettelse. Vanlige env-vars er lesbare for alle med prosjekttilgang (inkludert, i denne hendelsen, angriperen). Løsningen er gratis og tar ett klikk per variabel.

Må jeg rotere ALLE hemmelighetene mine, eller bare de på Vercel?

Roter alle hemmeligheter lagret i en ikke-sensitiv Vercel env-var. Hvis du brukte den samme nøkkelen et annet sted (et vanlig antimønster), roter den overalt. Ikke glem .env.local i forhåndsvisningsdeploys, CI-systemer som GitHub Actions og eventuelle innlimte referanser i Linear eller Slack.

Hvordan skanner jeg env-varene mine raskt for faktiske hemmeligheter?

Kjør vercel env pull .env.audit deretter ggshield secret scan path .env.audit. Hvis du ikke kan installere GitGuardian, bruk grep-enlinjen fra Trinn 2 i planen — den fanger AWS-nøkler, Stripe-nøkler, GitHub-tokens, npm-tokens, JWT-er og PEM-blokker.

Bør jeg bytte fra Vercel etter denne hendelsen?

Ikke på grunn av denne hendelsen alene. Vercels respons — offentlig IoC, tidslinje, rotsjonsveiledning — har vært rimelig transparent. Alle plattformer vil ha et brudd til slutt. Det som betyr noe er om du har designet for det: sensitive variabler som standard, kortlivede legitimasjoner, segmenterte miljøer. Hvis du uansett vurderer alternativer, analyserer artiklene våre Vercel vs. Netlify og Railway vs. Render vs. Fly.io avveiningene.

Hvor lang tid har jeg på å varsle kunder hvis jeg er berørt?

GDPR gir deg 72 timer fra kjennskap til et varslingspliktig brudd. California (CCPA) har dataklassespesifikke utløsere. SOC 2/ISO 27001-kontrakter krever ofte tidligere varsling enn regulatorer. Hvis du har betalende kunder og bekrefter eksfiltrering av dataene deres, anta at du er på en 72-timers klokke og konsultér juridisk rådgivning før du sender noe.

Kan Next.js-apper angripes gjennom dette selv om jeg ikke er på Vercel?

Hendelsen er Vercel-plattformspesifikk. Next.js selv, hostet andre steder, er ikke berørt av bruddmekanismen. Men hvis du brukte de samme NEXT_PUBLIC_ env-var-mønstrene som ved et uhell eksponerer hemmeligheter, reiser de problemene med koden din uavhengig av vert. Revider byggutdataene uansett.

Hva er enklicks-rettelsen som ville ha forhindret det meste av skaden?

Å merke alle legitimasjonsbærende env-vars som "Sensitiv" i Vercel fra dag én. Det er en avkrysningsboks i dashbordet. I denne hendelsen ble IKKE sensitive variabler åpnet — bare de vanlige. Det er rettelsen, og det koster null kroner og omtrent fem minutter per prosjekt.

Hvordan sikrer jeg at teamet mitt aldri leverer en umerkede hemmelighet igjen?

Tre lag: (1) hemmelighetsscanning pre-commit med gitleaks, (2) en CI-sjekk som mislykkes hvis en env-var legges til uten sensitive: true-flagget via Vercel API, og (3) en Claude Code-hook som kjører skanneren ved hver redigering. Dybdeforsvar — hvert av de tre fanger 80 %, alle tre sammen ~99 %.

Konklusjon

Vercel-bruddet i april 2026 er alvorlig, men overkommelig — hvis du beveger deg de neste 60 minuttene. Frys deploys, hent env-varene dine, kjør grep, roter i nivåer, legg til på nytt som sensitive og jakt nedstrøms. Det er hele planen.

Plattformsbrudd avslører hvor mye vi stoler på standardinnstillinger. De fleste team som ble skadet her gjorde ingenting galt — de lot bare "Sensitiv"-knappen være ukrysset fordi ingen fortalte dem at det hadde noe å si. Det er den virkelige lærdommen for vibe-codere: AI-generert kode leveres raskt, men sikkerhetsinnstillinger følger ikke med genereringen.

Hvis du ønsker et ekstra øyenpar på stacken din, eller heller ikke kjøre denne planen alene klokken 2 om natten, bestill en gratis triagesamtale med Techsy-teamet. Ellers — lykke til, handle raskt og merk de variablene som sensitive.