Vercel lagret hemmelighetene dine i klartekst og kalte det en funksjon

Vercel ble hacket. Angriperen var inne i omtrent to måneder før det ble oppdaget. Vedkommende enumererte og dekrypterte kundenes miljøvariabler — API-nøkler, databasepassord, signaturnøkler, tokens — for hvert prosjekt som ikke brukte Vercels valgfrie «sensitive»-flagg.

Angrepskjeden: et tredjeparts AI-verktøy kalt Context.ai ble kompromittert. Angriperen brukte dette fotfestet til å overta en Vercel-ansatts Google Workspace-konto. Derfra gikk veien inn i Vercels interne systemer. Så begynte de å lese hemmeligheter.

Dataene tilbys nå angivelig på BreachForums for 2 millioner dollar.

«Sensitive»-avmerkingsboksen som ikke var standard

Her er den delen som betyr noe.

Vercel har to typer miljøvariabler. Vanlige, som er «encrypted at rest», men som kan dekrypteres og leses av Vercels systemer. Og «sensitive», som bruker ekstra kryptering som Vercel sier hindrer til og med intern tilgang.

Angriperen kunne lese alle de vanlige. Bare de «sensitive» var beskyttet.

Problemet: «sensitive» var valgfritt. Ikke standard. Hver utvikler som satte DATABASE_URL eller STRIPE_SECRET_KEY eller JWT_SIGNING_KEY uten å krysse av i en boks — og det er de fleste — hadde disse verdiene liggende i et format som en angriper med intern tilgang kunne dekryptere.

Vercels veiledning etter bruddet: «Enable the sensitive environment variable feature for encrypted storage.» Oversettelse: krypteringen du antok beskyttet hemmelighetene dine, beskyttet dem ikke egentlig fra oss, eller fra noen som kom seg inn i systemene våre.

To måneder med oppholdstid

Den første kompromitteringen skjedde i februar 2026. Vercel publiserte sin første sikkerhetsbulletin 19. april. Det er omtrent to måneder der en angriper hadde tilgang til interne systemer.

Vercels eget sikkerhetsteam beskrev angriperen som «highly sophisticated based on their operational velocity and in-depth understanding of Vercel's product API surface». Når selskapet som drifter infrastrukturen din sier at angriperen forsto systemene deres bedre enn forventet, bør det få deg til å tenke deg om.

I løpet av de to månedene hadde angriperen tid til å enumerere hver tilgjengelig miljøvariabel på tvers av berørte kundeprosjekter. Tid til å eksfiltrere. Tid til å selge.

OAuth-leverandørkjeden

Inngangspunktet var ikke engang Vercels egen kode. En Vercel-ansatt autoriserte Context.ai — et AI-produktivitetsverktøy — via Google OAuth. Da Context.ai ble kompromittert, arvet angriperen hver tillatelse det OAuth-godet ga.

Dette er et mønster som gjentar seg. Organisasjoner låser nøye ned primær autentiseringen sin, og deler så ut OAuth-tokens til tredjepartsverktøy som har sin egen, ofte svakere, sikkerhetsprofil. Ett kompromittert app i kjeden, og angriperen arver den ansattes tilgang.

Det kompromitterte OAuth App-ID-et er offentlig: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com. Hvis organisasjonen din autoriserte denne appen, trekk tilbake tilgangen nå.

Hva du bør gjøre

Hvis du kjører på Vercel:

• Roter alle miljøvariabler umiddelbart — ikke vent med å finne ut om du var «berørt»
• Slå på sensitive-flagget for alle miljøvariabler fremover
• Gjennomgå OAuth-apptillatelsene i Google Workspace og trekk tilbake alt du ikke aktivt bruker
• Se gjennom Vercel-utviklingsloggene for uventede endringer i perioden februar–april 2026
• Sjekk underliggende tjenester (databaser, betalingsformidlere, API-er) for uautorisert tilgang med påleggene som ble lagret i Vercel

Den egentlige lærdommen

Vercels arkitektur lagret kundenes hemmeligheter på en måte som gjorde at intern tilgang kunne dekryptere dem. De tilbød et sterkere alternativ, men gjorde det ikke til standard. I to måneder merket ingen at en angriper leste disse hemmelighetene.

Dette er problemet med «stol på oss»-sikkerhet. Vercel krypterte miljøvariablene dine i hvile — teknisk sett sant. Men de satt på dekrypteringsnøklene. Da systemene deres ble kompromittert, ble hemmelighetene dine det også.

Alternativet er zero-knowledge-arkitektur, der tjenesteleverandøren matematisk sett ikke kan dekryptere dataene dine. Ikke «velger å la være» — kan ikke. Uansett hvor mye intern kompromittering, uansett uærlig ansatt, uansett sofistikert angriper som bor i infrastrukturen din i to måneder, kan ikke noen lese det serveren aldri hadde nøkler til å dekryptere.

Vercel ber kundene krysse av i en boks for å velge ekte kryptering. Spørsmålet verdt å stille: hvorfor var ikke det det eneste alternativet fra starten?