Vercel stockait vos secrets en clair et en faisait une fonctionnalité

Vercel a subi une intrusion. L'attaquant est resté présent environ deux mois avant la détection. Il a énuméré et déchiffré les variables d'environnement des clients — clés API, mots de passe de bases de données, clés de signature, jetons — pour chaque projet n'utilisant pas le marqueur optionnel « sensitive » de Vercel.

La chaîne d'attaque : un outil IA tiers appelé Context.ai a été compromis. L'attaquant a utilisé ce point d'appui pour prendre le contrôle du compte Google Workspace d'un employé de Vercel. Depuis là, il a pivoté vers les systèmes internes de Vercel. Puis il a commencé à lire les secrets.

Les données sont désormais, selon toute vraisemblance, proposées sur BreachForums pour 2 millions de dollars.

La case à cocher « sensitive » qui n'était pas activée par défaut

Voici la partie qui compte.

Vercel distingue deux types de variables d'environnement. Les variables ordinaires, qui sont « chiffrées au repos » mais peuvent être déchiffrées et lues par les systèmes de Vercel. Et les variables « sensibles », qui utilisent un chiffrement supplémentaire que Vercel présente comme empêchant même l'accès interne.

L'attaquant pouvait lire toutes les variables ordinaires. Seules les variables « sensibles » étaient protégées.

Le problème : « sensitive » était une option à activer. Pas le réglage par défaut. Tout développeur ayant défini DATABASE_URL ou STRIPE_SECRET_KEY ou JWT_SIGNING_KEY sans cocher une case — et c'est la majorité — laissait ces valeurs dans un format qu'un attaquant disposant d'un accès interne pouvait déchiffrer.

Les recommandations de Vercel après l'incident : « Enable the sensitive environment variable feature for encrypted storage. » Traduction : le chiffrement que vous supposiez protéger vos secrets ne les protégeait en réalité ni de nous, ni de quiconque pénétrait dans nos systèmes.

Deux mois de présence

Le compromis initial a eu lieu en février 2026. Vercel a publié son premier bulletin de sécurité le 19 avril. Cela représente environ deux mois durant lesquels un attaquant a eu accès aux systèmes internes.

La propre équipe de sécurité de Vercel a décrit l'attaquant comme « hautement sophistiqué, au vu de sa vélocité opérationnelle et de sa compréhension approfondie de la surface d'API produit de Vercel ». Lorsque l'entreprise qui héberge votre infrastructure indique que l'attaquant comprenait ses systèmes mieux que prévu, cela devrait vous amener à la réflexion.

Durant ces deux mois, l'attaquant a eu le temps d'énumérer chaque variable d'environnement accessible sur les projets clients affectés. Le temps d'exfiltrer. Le temps de vendre.

La chaîne d'approvisionnement OAuth

Le point d'entrée n'était même pas le code de Vercel lui-même. Un employé de Vercel avait autorisé Context.ai — un outil de productivité IA — via Google OAuth. Lorsque Context.ai a été compromis, l'attaquant a hérité de toutes les permissions accordées par cette autorisation OAuth.

C'est un schéma qui se répète sans cesse. Les organisations verrouillent soigneusement leur authentification principale, puis distribuent des jetons OAuth à des outils tiers qui ont leur propre posture de sécurité, souvent plus faible. Une seule application compromise dans la chaîne, et l'attaquant hérite de l'accès de votre employé.

L'identifiant de l'application OAuth compromise est public : 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com. Si votre organisation a autorisé cette application, révoquez-la immédiatement.

Ce que vous devez faire

Si vous déployez sur Vercel :

• Faites tourner toutes les variables d'environnement immédiatement — n'attendez pas de déterminer si vous étiez « affecté »
• Activez le marqueur sensitive sur toutes les variables d'environnement à l'avenir
• Auditez les permissions des applications OAuth de votre Google Workspace et révoquez tout ce que vous n'utilisez pas activement
• Examinez les journaux de déploiement Vercel à la recherche de modifications inattendues entre février et avril 2026
• Vérifiez les services en aval (bases de données, processeurs de paiement, API) pour détecter tout accès non autorisé utilisant les identifiants stockés dans Vercel

La vraie leçon

L'architecture de Vercel stockait les secrets des clients dans un format qu'un accès interne pouvait déchiffrer. Une option plus forte existait, mais elle n'était pas le réglage par défaut. Pendant deux mois, personne n'a remarqué qu'un attaquant lisait ces secrets.

C'est le problème de la sécurité du type « faites-nous confiance ». Vercel chiffrait vos variables d'environnement au repos — techniquement vrai. Mais il détenait les clés de déchiffrement. Lorsque ses systèmes ont été compromis, vos secrets l'ont été aussi.

L'alternative est l'architecture à divulgation nulle de connaissance (zero-knowledge), dans laquelle le fournisseur de service ne peut mathématiquement pas déchiffrer vos données. Pas « choisit de ne pas » — ne peut pas. Aucun compromis interne, aucun employé malveillant, aucun attaquant sophistiqué résidant dans votre infrastructure pendant deux mois ne peut lire ce dont le serveur n'a jamais détenu les clés de déchiffrement.

Vercel demande aux clients de cocher une case pour accéder à un chiffrement réel. La question qui mérite d'être posée : pourquoi n'était-ce pas la seule option dès le départ ?