Vercel hackades (april 2026): Den 60-minuters nödplan varje utvecklare måste köra idag

Den 19 april 2026 bekräftade Vercel att angripare komprometterade ett tredjepartsverktyg för AI (Context.ai), kapade en Vercel-anställds Google Workspace-konto och läste miljövariabler som inte var markerade som "känsliga" i ett begränsat antal kundprojekt. Om du har deployat något till Vercel de senaste 30 dagarna måste du utgå från att en av dina env-vars kanske redan befinner sig i fel händer — och du behöver agera snabbt.

Den obehagliga sanningen: de flesta vibe-coders skjuter in .env-värden direkt från en mall utan att någonsin röra "Känslig"-knappen. Det är exakt den kategorin av variabler som angriparen läste. Den här planen guidar dig genom de närmaste 60 minuterna — vad du ska kontrollera, vad du ska rotera och hur du härdar din stack så att nästa plattformsintrång inte sänker din app.

TL;DR: Vad du ska göra de närmaste 60 minuterna

Läser du inget annat, gör de här sex sakerna nu:

1. Pausa automatiska deploys på dina produktionsbranchar.
2. Kör vercel env pull och sök i utmatningen efter hemlighetsmönster (sk_live_, AKIA, ghp_, eyJ).
3. Rotera varje API-nyckel som lagras som en icke-känslig miljövariabel — börja med betalnings-, databas-, autentiserings- och molnleverantörsnycklar.
4. Lägg tillbaka roterade hemligheter med "Känslig"-knappen i Vercel, och redeploya sedan.
5. Öppna din Vercel-aktivitetslogg för 1–20 april och flagga alla deploys, inloggningar eller tokenhändelser du inte känner igen.
6. Granska din GitHub-organisations granskningslogg för samma period — nya PATs, deploynycklar eller workflow-ändringar.

Nedan finns den fullständiga genomgången med kommandon, mönster och rotationsordning du behöver.

Vad som faktiskt hände i Vercel-intrånget i april 2026

Vercel offentliggjorde den 19 april 2026 att en angripare komprometterade Context.ai, ett tredjepartsverktyg för AI-produktivitet som användes av en Vercel-anställd. Därifrån tog angriparen kontroll över den anställdas Google Workspace-konto, tog sig in i Vercels interna miljö och fick åtkomst till miljövariabler som inte var markerade som "känsliga".

Variabler markerade som "känsliga" använder en separat krypterad läsväg, och Vercel uppger att det inte finns några bevis för att dessa exponerades. Allt annat — vanliga env-vars som lagrar API-nycklar, databas-URL:er, JWT-hemligheter — var läsbart. Ett inlägg på ett cyberbrottsforum påstår sig sälja Vercel-data för 2 miljoner dollar, men Vercel har inte bekräftat exfiltrering. Oavsett är det säkra draget att anta kompromittering för rotationsändamål, även om Vercel inte mailat dig direkt.

Företaget bedömde angriparen som "mycket sofistikerad baserat på operativ hastighet och detaljerad förståelse av Vercels system." Översättning: det var ingen script kiddie — ta klockan på allvar.

Är du drabbad? Kontrollera på 5 minuter

Kort svar: om du använder Vercel och inte har varit noggrann med "Känslig"-knappen, behandla dig själv som drabbad. Här är 5-minuters-triagen:

• Öppna Vercels aktivitetslogg och filtrera från 1 april 2026 till nu. Leta efter okända inloggningar, tokenskapanden eller deploys.
• Gå till Google Workspace Admin → Säkerhet → API-kontroller och sök efter den publicerade kompromissindikationen: OAuth-klient-ID 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com. Om den är auktoriserad, återkalla den omedelbart.
• Kontrollera om någon i ditt team någonsin loggat in på Context.ai via Google SSO. Om ja, behandla deras konton som högre risk.
• Titta på fliken Miljövariabler i ditt Vercel-projekt. Räkna hur många som INTE är markerade som "Känslig". Var och en av dem befinner sig i riskzonen.

Om du fick ett mail från Vercel som börjar med "We identified a security incident affecting your account" — du är i den bekräftade påverkade gruppen. Hoppa direkt till rotationsavsnittet och börja NU.

Den 60-minuters nödresponsplanen

Ordningen bestäms av explosionsradien. Hoppa inte över steg — varje steg låser upp nästa.

Steg 1: Frys miljön (första 10 minuterna)

Stoppa blödningen innan du börjar med kriminaltekniken:

• Pausa automatiska deploys på main/production-branchar (Vercel Dashboard → Projekt → Inställningar → Git).
• Inaktivera tillfälligt Vercel GitHub-appen på github.com/organizations/<din-org>/settings/installations om du misstänker ett djupare intrång.
• Exportera din Vercel-granskningslogg till en CSV och spara den lokalt. Du behöver den om detta blir en GDPR-anmälningspliktig incident senare.
• Aktivera Observability Plus (även en provvecka) för att behålla utökade loggar.

Det här är steget "bevara bevis". Att rotera innan du tar en logg-snapshot förstör din tidslinje.

Steg 2: Hämta env-vars och skanna dem efter hemligheter

Öppna din terminal och kör:

vercel link
vercel env pull .env.vercel-audit

Skanna sedan utmatningen. Det snabbaste sättet är GitGuardians CLI:

ggshield secret scan path .env.vercel-audit

Om du inte vill installera något, använd grep med dessa mönster — de fångar 80 % av läckta hemligheter 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

Varje träff är en rotationskandidat. Varje icke-matchande hemlighet som ändå är en autentiseringsuppgift (databas-URL:er, Redis-lösenord, webhook-signeringsnycklar) är OCKSÅ en rotationskandidat — grep fångar bara det uppenbara.

Steg 3: Rotera hemligheter i prioritetsordning (inte alfabetisk)

Det är här de flesta team gör fel. De roterar 40 hemligheter i slumpmässig ordning, en sessionsnyckel ogiltigförklarar alla aktiva inloggningar och supportärenden exploderar. Gör det i nivåer:

Tier 0 — Rotera inom de närmaste 30 minuterna:

• Alla GitHub Personal Access Tokens (detaljerade och klassiska)
• Alla befintliga Vercel känsliga env-var-tokens
• Deployment Protection-tokens

Tier 1 — Rotera idag:

• Hemliga nycklar hos betalningsprocessorer (Stripe sk_live_, Adyen, Braintree)
• AUTH_SECRET, NEXTAUTH_SECRET, JWT-signeringsnycklar, sessionscookies
• Databaskopplingsstringar med skrivåtkomst (DATABASE_URL, Mongo, Redis)
• Molnleverantörsnycklar (AWS IAM, GCP-tjänstkonton, Azure-klienthemligheter)
• Webhook-signeringshemligheter (uppdatera hos avsändaren OCH mottagaren)

Tier 2 — Rotera den här veckan:

• Tredjepartssaas-nycklar (e-post, SMS, analys, CRM)
• OAuth-klienthemligheter
• SMTP-uppgifter, CDN-nycklar

Tier 3 — Rotera när det passar:

• Skrivskyddade analystoken, Sentry-DSN:er, offentliga/anonyma nycklar

Kritisk operationsordning:

• För databaser: skapa den nya användaren innan du återkallar den gamla, annars tar du ner sajten under rotationen.
• För sessionsnycklar: planera en utloggningshändelse — alla aktiva sessioner ogiltigförklaras.
• För webhooks: uppdatera båda sidor i samma deployningsfönster.
• Redeploya efter varje env-var-ändring. Vercel bakar in värden vid byggtid, inte vid körning.

Steg 4: Lägg tillbaka allt som "Känsligt"

När du lägger tillbaka de nya värdena, aktivera "Känslig"-knappen på var och en av dem. Känsliga värden använder en separat krypterad väg och, enligt Vercels eget säkerhetsbulletin, exponerades inte i den här incidenten. Det är den en-klick-ändring som skulle ha räddat de flesta påverkade kunder.

Steg 5: Granska ditt repo efter oönskade ändringar

Jämför HEAD på din huvudbranch mot en känd god commit från innan 1 april. Fokusera på:

• package.json-skript — särskilt postinstall, prepare, preinstall
• Låsfiler (package-lock.json, pnpm-lock.yaml) efter oväntade nya beroenden
• .github/workflows/*.yml efter nya workflows eller opinnade actions
• vercel.json efter ändringar i byggkommandon eller misstänkta omdirigeringar
• next.config.js efter nya headers eller omdirigeringar som pekar på okända domäner

Om du publicerar npm-paket, kör även npm view <pkg> time --json och verifiera att ingenting publicerats utan din författarskap.

Steg 6: Jaga nedströms

Angripare stannar inte vid env-vars — de använder dem. Fråga dina nedströmssystem för perioden 1 april och framåt:

• AWS CloudTrail: oväntad CreateUser, AttachUserPolicy, S3 GetObject-burstar, inloggningar från nya IP-adresser.
• Databasens granskningsloggar: stora SELECT *-frågor, exporter, anslutningar från ovanliga regioner.
• Stripe / Adyen: nya API-nycklar, misstänkta återbetalningar, kundskapanden från konstiga platser.
• Auth-leverantör: impossible-travel-inloggningar, obehöriga lösenordsåterställningar, nya OAuth-appar.

En träff här förvandlar detta från en rotationsövning till en faktisk incident — eskalera och överväg notifieringsskyldigheterna (GDPR: 72 timmar).

Vad "vibe-coders" missar: den dolda attackytan

Om du lärt dig koda med AI-verktyg — som Claude Code, Cursor eller Copilot — deploydade du förmodligen din första Vercel-app innan du någonsin läst ett säkerhetsdokument. Det är förståeligt. Men det finns fyra dolda fällor som slår vibe-coders hårdare än erfarna utvecklare:

1. NEXT_PUBLIC_****-fällan. Allt med prefixet NEXT_PUBLIC_ buntas in i klient-JavaScriptet. Om du stoppade in en API-nyckel där "bara för att testa" var den redan offentlig innan intrånget. Granska din byggutmatning: grep -rE "sk_|AKIA|eyJ" .next/static/.
2. Linear/Slack-läckan. Om ditt team klistrar in hemligheter i Linear-ärenden eller Slack-trådar "för ett ögonblick", sitter de hemligheterna i tredjepartsloggar. Granska din Linear-granskningslogg och sök efter samma regex-mönster.
3. Antagandet om .env.local i privat repo. Privata repos är inte privata om din Vercel GitHub-app komprometterades. Varje committad .env.*-fil befinner sig i riskzonen.
4. Förhandsvisningsdeploys med produktionshemligheter. De flesta vibe-coders återanvänder produktionens env-vars för förhandsvisningsmiljöer. Det fördubblar din attackyta. Separera dem.

Det är det tråkiga infrastrukturarbete som AI-kodningsverktyg hoppar över. Lösningen är inte att sluta använda AI — det är att kombinera AI-hastighet med en säkerhetsgrund. Om du fortfarande räknar ut var din app ens bor är vår Vercel vs. Netlify-jämförelse och Railway vs. Render vs. Fly.io-analys bra utgångspunkter.

Hur du härdar din stack så att nästa intrång inte bränner dig

Plattformsintrång är ett när, inte ett om. Det här är grundläggandet som varje produktionsapp borde ha på plats till måndag:

• Sätt varje ny env-var som standard till "Känslig" i Vercel. Gör det till en vana för ditt team.
• Använd kortlivade uppgifter. Byt ut långlivade AWS/GCP-nycklar mot GitHub OIDC-federation — din molnleverantör litar direkt på CI-identiteten, ingen långlivad hemlighet att läcka.
• Installera hemlighetsskanning pre-commit (gitleaks, Trufflehog). Förhindrar att hemligheter hamnar i repot från första början.
• Begränsa din GitHub-app till specifika repos, inte organisations-brett.
• Kvartalsvis OAuth-appgranskning över Google Workspace, Microsoft 365, GitHub och Vercel. Ta bort allt du inte känner igen.
• **Kör hemlighetsskanningar som en **Claude Code-hook — deterministisk pre-commit-tillämpning även när AI:n glömmer.
• Fäst din Next.js-version och bevaka råd. Vercel är den primära Next.js-ansvariga, så incidenter här eskalerar.
• Segmentera dina backend-hemligheter. Om du använder Supabase eller Firebase, använd säkerhet på radnivå och tjänsterollsnycklar sparsamt — en läckt tjänstnyckel är ett fullständigt databaskompromiss.

Behöver du hjälp med att låsa ner det här? Så passar Techsy in

Det ärliga erbjudandet: de flesta små team har ingen säkerhetsingenjör, och att läsa en 60-stegs incidentresponsplan klockan 2 på natten är inte hur någon vill tillbringa sin måndag.

På Techsy har vi under de senaste två åren kört incidentrespons och plattformshärdning för mer än 40 produktions-Next.js- och Node.js-appar. För Vercel-incidenten specifikt erbjuder vi:

• 72-timmars nödrespons — Vi kör Tier 0/Tier 1-rotationen, skannar dina env-vars mot 200+ hemlighetssignaturer och granskar dina Vercel-, GitHub- och molnloggar från början till slut. Typisk genomloppstid: en arbetsdag.
• Plattformshärdningsrevision — Migrering till känsliga variabler, OIDC-uppgiftsrotation, hemlighetsskanning pre-commit, GitHub-app-scoping och en skriven runbook så att ditt framtida jag vet vad du ska göra vid nästa intrång.
• Löpande DevSecOps — Kvartalsvisa OAuth-granskningar, kontinuerlig hemlighetsskanning och incidentövningar så att "det händer inte oss" blir ett påstående du faktiskt kan backa upp.

Vi är ingenjörer, inte en checkbox-säkerhetsleverantör. Om du panikerar just nu, hör av dig för ett gratis 30-minuters triagesamtal — vi berättar ärligt om du behöver oss eller om du kan hantera det med planen ovan.

Vanliga frågor

Är Vercel-hacket bekräftat eller bara ett rykte?

Bekräftat. Vercel publicerade ett officiellt säkerhetsbulletin den 19 april 2026, där man erkände obehörig åtkomst via ett komprometterat tredjepartsverktyg för AI (Context.ai) och ett kapat Google Workspace-konto för en anställd. Miljövariabler som inte markerats som "känsliga" nåddes. Ett separat inlägg på BreachForums påstår sig sälja data för 2 miljoner dollar; den delen är overifierad.

Jag fick inget mail från Vercel. Är jag säker?

Förmodligen, men "förmodligen" är inte en säkerhetsposition. Vercel sa att de kontaktade det begränsade underurvalet av kunder med bekräftad påverkan. Om ditt mail inte kom är din risk lägre — men alla icke-känsliga env-vars på Vercels plattform befann sig i explosionsradien. Gör 10-minuters-triagen ändå.

Vad är skillnaden mellan "känsliga" och vanliga env-vars i Vercel?

"Känsliga" miljövariabler använder en separat krypterad läsväg och kan inte visas i dashboarden efter att de skapats. Vanliga env-vars är läsbara av alla med projektåtkomst (inklusive, i den här incidenten, angriparen). Lösningen är gratis och kräver ett klick per variabel.

Behöver jag rotera ALLA mina hemligheter, eller bara de på Vercel?

Rotera varje hemlighet lagrad i en icke-känslig Vercel env-var. Om du använde samma nyckel någon annanstans (ett vanligt antimönster), rotera den överallt. Glöm inte .env.local i förhandsvisningsdeploys, CI-system som GitHub Actions och eventuella inklistrade referenser i Linear eller Slack.

Hur skannar jag mina env-vars snabbt efter riktiga hemligheter?

Kör vercel env pull .env.audit sedan ggshield secret scan path .env.audit. Om du inte kan installera GitGuardian, använd grep-enraden från Steg 2 i planen — den fångar AWS-nycklar, Stripe-nycklar, GitHub-tokens, npm-tokens, JWT:er och PEM-block.

Borde jag byta från Vercel efter den här incidenten?

Inte på grund av den här incidenten ensam. Vercels svar — offentlig IoC, tidslinje, rotationsvägledning — har varit rimligt transparent. Varje plattform kommer att ha ett intrång så småningom. Det som spelar roll är om du har designat för det: känsliga variabler som standard, kortlivade uppgifter, segmenterade miljöer. Om du ändå väger alternativ analyserar våra artiklar Vercel vs. Netlify och Railway vs. Render vs. Fly.io avvägningarna.

Hur lång tid har jag på mig att meddela kunder om jag är drabbad?

GDPR ger dig 72 timmar från kännedom om ett anmälningspliktigt intrång. Kalifornien (CCPA) har dataklassspecifika utlösare. SOC 2/ISO 27001-kontrakt kräver ofta tidigare meddelande än regulatorer. Om du har betalande kunder och bekräftar exfiltrering av deras data, anta att du är på en 72-timmars klocka och konsultera juridisk rådgivning innan du skickar något.

Kan Next.js-appar attackeras genom detta även om jag inte är på Vercel?

Incidenten är Vercel-plattformsspecifik. Next.js självt, hostat någon annanstans, påverkas inte av intrångsmekanismen. Men om du använde samma NEXT_PUBLIC_ env-var-mönster som av misstag exponerar hemligheter, reser de problemen med din kod oavsett host. Granska din byggutmatning oavsett.

Vad är en-klick-lösningen som skulle ha förhindrat det mesta av skadan?

Att markera varje uppgiftsbärande env-var som "Känslig" i Vercel från dag ett. Det är en kryssruta i dashboarden. I den här incidenten nåddes INTE känsliga variabler — bara vanliga. Det är lösningen, och den kostar noll kronor och ungefär fem minuter per projekt.

Hur ser jag till att mitt team aldrig levererar en omärkt hemlighet igen?

Tre lager: (1) hemlighetsskanning pre-commit med gitleaks, (2) en CI-kontroll som misslyckas om en env-var läggs till utan sensitive: true-flaggan via Vercel API, och (3) en Claude Code-hook som kör skannern vid varje redigering. Djupförsvar — vart och ett av de tre fångar 80 %, alla tre tillsammans ~99 %.

Slutsats

Vercel-intrånget i april 2026 är allvarligt, men överlever — om du rör dig under de närmaste 60 minuterna. Frys deploys, hämta dina env-vars, kör grep, rotera i nivåer, lägg tillbaka som känsliga och jaga nedströms. Det är hela planen.

Plattformsintrång avslöjar hur mycket vi förlitar oss på standardinställningar. De flesta team som drabbades här gjorde ingenting fel — de lämnade bara "Känslig"-knappen okryssad för att ingen berättade för dem att det spelade roll. Det är den verkliga lärdomen för vibe-coders: AI-genererad kod levereras snabbt, men säkerhetsstandarder följer inte med genereringen.

Om du vill ha ett andra par ögon på din stack, eller hellre inte kör den här planen ensam klockan 2 på natten, boka ett gratis triagesamtal med Techsy-teamet. Annars — lycka till, agera snabbt och markera de variablerna som känsliga.