Vercel bewaarde je geheimen in platte tekst en noemde dat een feature

Vercel is gehackt. De aanvaller zat er ongeveer twee maanden voordat de inbraak werd ontdekt. Hij bracht de omgevingsvariabelen van klanten in kaart en ontcijferde ze — API-sleutels, databasewachtwoorden, signeersleutels, tokens — voor elk project dat geen gebruik maakte van Vercels optionele "sensitive"-vlag.

De aanvalsketen: een AI-tool van een derde partij, Context.ai, werd gecompromitteerd. De aanvaller gebruikte die voet aan de grond om het Google Workspace-account van een Vercel-medewerker over te nemen. Van daaruit klom hij door naar de interne systemen van Vercel. Daarna begon hij geheimen te lezen.

De data wordt nu naar verluidt aangeboden op BreachForums voor 2 miljoen dollar.

Het vinkje 'sensitive' dat niet standaard stond

Hier is het deel dat ertoe doet.

Vercel heeft twee soorten omgevingsvariabelen. Gewone, die "encrypted at rest" zijn maar die Vercels systemen kunnen ontcijferen en lezen. En "sensitive", met extra versleuteling waarvan Vercel zegt dat die zelfs interne toegang voorkomt.

De aanvaller kon alle gewone lezen. Alleen de "sensitive" waren beschermd.

Het probleem: "sensitive" was opt-in. Niet de standaard. Elke developer die DATABASE_URL of STRIPE_SECRET_KEY of JWT_SIGNING_KEY instelde zonder een vinkje te zetten — en dat zijn de meesten — had die waarden in een formaat staan dat een aanvaller met interne toegang kon ontcijferen.

Vercels advies na de inbraak: "Zet de sensitive-omgevingsvariabele-functie aan voor versleutelde opslag." Vertaling: de versleuteling waarvan je aannam dat die je geheimen beschermde, beschermde ze niet tegen ons, of tegen iemand die in onze systemen kwam.

Twee maanden dwell time

De eerste inbraak vond plaats in februari 2026. Vercel publiceerde op 19 april zijn eerste securitybulletin. Dat is ongeveer twee maanden waarin een aanvaller toegang had tot interne systemen.

Vercels eigen securityteam omschreef de aanvaller als "zeer geavanceerd, gezien hun operationele snelheid en hun diepgaande kennis van het API-oppervlak van Vercels product". Als het bedrijf dat je infrastructuur host zegt dat de aanvaller hun systemen beter begreep dan verwacht, zou je daar even stil bij moeten staan.

In die twee maanden had de aanvaller tijd om elke toegankelijke omgevingsvariabele in kaart te brengen in de getroffen klantprojecten. Tijd om data weg te sluizen. Tijd om te verkopen.

De OAuth-supplychain

Het toegangspunt was niet eens Vercels eigen code. Een Vercel-medewerker autoriseerde Context.ai — een AI-productiviteitstool — via Google OAuth. Toen Context.ai werd gecompromitteerd, erfde de aanvaller elke machtiging die die OAuth-verlening meegaf.

Dit is een patroon dat zich blijft herhalen. Organisaties beveiligen hun primaire authenticatie zorgvuldig, en delen daarna OAuth-tokens uit aan tools van derden met een eigen, vaak zwakkere, security-houding. Eén gecompromitteerde app in de keten en de aanvaller erft de toegang van je medewerker.

De gecompromitteerde OAuth App ID is openbaar: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com. Als jouw organisatie deze app heeft geautoriseerd, trek die autorisatie nu in.

Wat je moet doen

Als je op Vercel deployt:

• Draai elke omgevingsvariabele direct om — wacht niet tot je weet of je "getroffen" was
• Zet vanaf nu de sensitive-vlag aan op alle omgevingsvariabelen
• Controleer de OAuth-appmachtigingen in je Google Workspace en trek alles in wat je niet actief gebruikt
• Bekijk de deploymentlogs van Vercel op onverwachte wijzigingen tussen februari en april 2026
• Controleer downstream diensten (databases, betaalverwerkers, API's) op ongeautoriseerde toegang met de credentials die in Vercel stonden

De echte les

Vercels architectuur sloeg klantgeheimen zo op dat interne toegang ze kon ontcijferen. Ze boden een sterkere optie, maar maakten die niet de standaard. Twee maanden lang merkte niemand dat een aanvaller die geheimen las.

Dit is het probleem met "trust us"-security. Vercel versleutelde je omgevingsvariabelen at rest — technisch klopt dat. Maar zij hadden de ontcijferingssleutels. Toen hun systemen gecompromitteerd waren, waren je geheimen dat ook.

Het alternatief is zero-knowledge-architectuur, waarbij de dienstverlener je data wiskundig niet kan ontcijferen. Niet "ervoor kiezen om dat niet te doen" — kan niet. Geen enkele interne inbraak, geen malafide medewerker, geen geavanceerde aanvaller die twee maanden in je infrastructuur woont, kan lezen waarvoor de server nooit de sleutels had om te ontcijferen.

Vercel vraagt klanten een vinkje te zetten om op echte versleuteling over te schakelen. De vraag die ertoe doet: waarom was dat vanaf het begin niet de enige optie?