Vercel gemte dine hemmeligheder i klartekst og kaldte det en funktion

Vercel blev brudt. Angriberen var inde i cirka to måneder, før det blev opdaget. Vedkommende opregnede og dekrypterede kundernes miljøvariabler — API-nøgler, databaseadgangskoder, signaturnøgler, tokens — for hvert projekt, der ikke brugte Vercels valgfri "sensitive"-markering.

Angrebskæden: et tredjeparts AI-værktøj ved navn Context.ai blev kompromitteret. Angriberen brugte det fodfæste til at overtage en Vercel-medarbejders Google Workspace-konto. Derfra bevægede vedkommende sig ind i Vercels interne systemer. Og så begyndte hemmelighederne at blive læst.

Dataene udbydes nu angiveligt på BreachForums for 2 millioner dollars.

Afkrydsningsfeltet "sensitive", der ikke var standard

Her kommer den del, der betyder noget.

Vercel har to typer miljøvariabler. Almindelige, som er "encrypted at rest", men som kan dekrypteres og læses af Vercels systemer. Og "sensitive", som bruger yderligere kryptering, der ifølge Vercel forhindrer selv intern adgang.

Angriberen kunne læse alle de almindelige. Kun de "sensitive" var beskyttet.

Problemet: "sensitive" var et tilvalg. Ikke standarden. Enhver udvikler, der satte DATABASE_URL eller STRIPE_SECRET_KEY eller JWT_SIGNING_KEY uden at sætte kryds i en boks — og det er de fleste — havde de værdier liggende i et format, som en angriber med intern adgang kunne dekryptere.

Vercels vejledning efter bruddet: "Enable the sensitive environment variable feature for encrypted storage." Omformuleret: den kryptering, du troede beskyttede dine hemmeligheder, beskyttede dem i praksis hverken mod os eller mod andre, der kom ind i vores systemer.

To måneder med opholdstid

Den indledende kompromittering skete i februar 2026. Vercel offentliggjorde sin første sikkerhedsmeddelelse den 19. april. Det er cirka to måneder, hvor en angriber havde adgang til interne systemer.

Vercels eget sikkerhedsteam beskrev angriberen som "highly sophisticated based on their operational velocity and in-depth understanding of Vercel's product API surface". Når det firma, der hoster din infrastruktur, siger, at angriberen forstod deres systemer bedre end forventet, bør det få dig til at stoppe op.

I de to måneder havde angriberen tid til at opregne hver eneste tilgængelige miljøvariabel på tværs af de berørte kundeprojekter. Tid til at eksfiltrere. Tid til at sælge.

OAuth-forsyningskæden

Indgangspunktet var ikke engang Vercels egen kode. En Vercel-medarbejder godkendte Context.ai — et AI-produktivitetsværktøj — via Google OAuth. Da Context.ai blev kompromitteret, arvede angriberen alle de tilladelser, det OAuth-godkendelse gav.

Det er et mønster, der bliver ved med at gentage sig. Organisationer låser omhyggeligt deres primære autentificering ned og deler så OAuth-tokens ud til tredjepartsværktøjer med deres egen, ofte svagere, sikkerhedsprofil. Én kompromitteret app i kæden, og angriberen arver din medarbejders adgang.

Det kompromitterede OAuth App ID er offentligt: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com. Hvis din organisation har godkendt denne app, så tilbagekald den nu.

Hvad du bør gøre

Hvis du deployer på Vercel:

• Rotér alle miljøvariabler med det samme — vent ikke på at få fastslået, om du var "berørt"
• Slå sensitive-markeringen til for alle miljøvariabler fremover
• Gennemgå dine Google Workspace OAuth-app-tilladelser og tilbagekald alt, du ikke aktivt bruger
• Gennemgå Vercels deploymentslogs for uventede ændringer i februar-april 2026
• Tjek downstream-tjenester (databaser, betalingsformidlere, API'er) for uautoriseret adgang med de credentials, der lå i Vercel

Den egentlige lære

Vercels arkitektur gemte kundernes hemmeligheder på en måde, så intern adgang kunne dekryptere dem. De tilbød en stærkere mulighed, men gjorde den ikke til standard. I to måneder lagde ingen mærke til, at en angriber læste de hemmeligheder.

Det er problemet med "stol på os"-sikkerhed. Vercel krypterede dine miljøvariabler i hvile — teknisk set korrekt. Men de havde dekrypteringsnøglerne. Da deres systemer blev kompromitteret, blev dine hemmeligheder det også.

Alternativet er zero-knowledge-arkitektur, hvor tjenesteudbyderen matematisk set ikke kan dekryptere dine data. Ikke "vælger ikke at" — kan ikke. Ingen mængde intern kompromittering, ingen medarbejder på afveje, ingen avanceret angriber, der ligger i din infrastruktur i to måneder, kan læse det, serveren aldrig har haft nøglerne til at dekryptere.

Vercel beder kunderne sætte kryds i en boks for at tilvælge rigtig kryptering. Spørgsmålet, der er værd at stille: hvorfor var det ikke den eneste mulighed fra starten?