Vercel lagrade dina hemligheter i klartext och kallade det en funktion
En angripare pivoterade från ett komprometterat AI-verktyg via ett Google-konto in i Vercels infrastruktur och dekrypterade sedan alla miljövariabler som inte manuellt markerats som "sensitive". Intrången pågick i två månader innan någon märkte den.
Vercel blev komprometterat. Angriparen var inne i ungefär två månader innan intrången upptäcktes. De listar och dekrypterade kunders miljövariabler — API-nycklar, databaslösenord, signaturnycklar, tokens — för alla projekt som inte använde Vercels valfria "sensitive"-flagga.
Attackkedjan: ett tredjeparts-AI-verktyg vid namn Context.ai komprometterades. Angriparen använde den fotfästet för att ta över ett Vercel-anställds Google Workspace-konto. Därifrån pivoterade de vidare in i Vercels interna system. Sedan började de läsa hemligheter.
Uppgifterna erbjuds nu på BreachForums för 2 miljoner dollar.
"Sensitive"-kryssrutan som inte var standard
Här är den del som spelar roll.
Vercel har två typer av miljövariabler. Vanliga, som är "encrypted at rest" men kan dekrypteras och läsas av Vercels system. Och "sensitive", som använder ytterligare kryptering som Vercel säger förhindrar till och med intern åtkomst.
Angriparen kunde läsa alla de vanliga. Bara de "sensitive" var skyddade.
Problemet: "sensitive" var frivilligt. Inte standard. Varje utvecklare som satte DATABASE_URL eller STRIPE_SECRET_KEY eller JWT_SIGNING_KEY utan att kryssa i en ruta — och det är de flesta — hade de värdena liggande i ett format som en angripare med intern åtkomst kunde dekryptera.
Vercels vägledning efter intrången: "Enable the sensitive environment variable feature for encrypted storage." Översatt: krypteringen du antog skyddade dina hemligheter skyddade dem alltså inte från oss, eller från någon som tog sig in i våra system.
Två månaders dwell time
Det initiala intrånget skedde i februari 2026. Vercel publicerade sitt första säkerhetsmeddelande den 19 april. Det är ungefär två månader där en angripare hade åtkomst till interna system.
Vercels eget säkerhetsteam beskrev angriparen som "highly sophisticated based on their operational velocity and in-depth understanding of Vercel's product API surface". När företaget som driftar din infrastruktur säger att angriparen förstod deras system bättre än väntat, bör det få dig att fundera.
Under de två månaderna hade angriparen tid att lista varje tillgänglig miljövariabel över berörda kundprojekt. Tid att exfiltrera. Tid att sälja.
OAuth-leverantörskedjan
Ingången var inte ens Vercels egen kod. En Vercel-anställd godkände Context.ai — ett AI-produktivitetsverktyg — via Google OAuth. När Context.ai komprometterades ärvde angriparen varje behörighet som OAuth-godkändet gav.
Det här är ett mönster som upprepar sig. Organisationer låser noga ner sin primära autentifiering och delar sedan ut OAuth-tokens till tredjepartsverktyg som har sin egen, ofta svagare, säkerhetsprofil. Ett komprometterat app i kedjan och angriparen ärvs din anställdes åtkomst.
Det komprometterade OAuth App ID:t är offentligt: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com. Om din organisation godkänt den här appen, dra tillbaka den nu.
Vad du bör göra
Om du driftar på Vercel:
- Rotera varje miljövariabel omedelbart — vänta inte med att avgöra om du var "berörd"
- Slå på sensitive-flaggan för alla miljövariabler framåt
- Granska dina OAuth-appbehörigheter i Google Workspace och dra tillbaka allt du inte aktivt använder
- Granska Vercels driftloggar för oväntade ändringar under februari–april 2026
- Kontrollera underliggande tjänster (databaser, betalningsleverantörer:er, API:er) för obehörig åtkomst med de uppgifter som lagrades i Vercel
Den verkliga lärdomen
Vercels arkitektur lagrade kundernas hemligheter på ett sätt som intern åtkomst kunde dekryptera. De erbjöd ett starkare alternativ, men gjorde det inte till standard. I två månader märkte ingen att en angripare läste de hemligheterna.
Det är problemet med "lit på oss"-säkerhet. Vercel krypterade dina miljövariabler at rest — tekniskt sant. Men de höll dekrypteringsnycklarna. När deras system komprometterades, blev dina hemligheter det också.
Alternativet är zero-knowledge-arkitektur, där tjänsteleverantören matematiskt inte kan dekryptera dina data. Inte "väljer att inte" — kan inte. Ingen mängd intern kompromettering, ingen illasinnad anställd, ingen sofistikerad angripare som lever i din infrastruktur i två månader kan läsa det som servern aldrig hade nycklar att dekryptera.
Vercel ber kunder att kryssa i en ruta för att välja in sig i riktig kryptering. Frågan värd att ställa: varför var inte det det enda alternativet från början?