Vercel piraté : l'OAuth d'un preneur de notes IA a suffi

Vercel n’a pas été piraté le 19 avril. C’est un assistant de prise de notes qui l’a été — et l’attaquant n’a jamais eu besoin de forcer une seule porte. Pas de CVE, pas d’exploit zero-day : juste un token OAuth accordé un jour à un outil IA qui simplifiait les réunions d’un employé.

Si votre PME utilise un assistant de réunion IA ou un outil de prospection email, ce scénario vous concerne. Même si vous n’hébergez rien chez Vercel.

Une chronologie en six étapes, sans exploit technique

L’incident est documenté par le bulletin officiel Vercel et les reconstitutions de BleepingComputer et CyberScoop.

1. Février 2026 — l’infection initiale. Un employé de Context.ai, une startup qui édite un assistant IA de prise de notes, télécharge un “auto-farm” Roblox depuis une source non officielle. Le fichier contient Lumma Stealer, un infostealer commodité qui circule largement sur le marché gris.

2. L’aspiration des tokens. Le malware récupère cookies, sessions et tokens du poste. Parmi eux, le token OAuth Google Workspace que Context.ai utilise pour lire les emails de ses clients — avec un scope “full access” sur Gmail, Calendar et Drive.

3. Le pivot OAuth. L’attaquant se connecte aux boîtes Gmail de plusieurs clients Context.ai avec ce token. Aucun mot de passe demandé : l’OAuth est techniquement légitime. Google Workspace voit une requête signée par une application approuvée par l’utilisateur. Aucune alerte.

4. L’accès au compte Vercel. Dans la boîte Gmail d’un employé Vercel (client de Context.ai), l’attaquant trouve de quoi pivoter vers le compte Google Workspace pro, puis vers l’interface d’administration Vercel.

5. L’exfiltration. Via ce compte, il accède aux variables d’environnement “plaintext” d’un sous-ensemble de projets clients : clés API, chaînes de connexion BDD, tokens tiers. Les variables “sensitive” et les paquets npm publiés par Vercel n’ont pas été touchés.

6. La mise en vente. Les 19 et 20 avril, un acteur utilisant le pseudo ShinyHunters met les données à 2 millions de dollars sur BreachForums. Vercel publie son bulletin le 19 avril à 11h04 PST et nomme Context.ai le soir même.

Entre l’infection initiale et la détection publique : environ deux mois.

Le quatrième épisode d’une série, mais avec un twist

En six semaines, c’est le quatrième incident de supply chain IA majeur. Flowise et sa CVE critique, Mercor via la bibliothèque LiteLLM compromise, Axios après un incident OpenAI — nous avions analysé cette série la semaine dernière en en tirant une règle : chaque composant IA tiers est un vecteur d’entrée potentiel.

Mais Vercel introduit une variante différente. Les trois cas précédents reposaient sur une vulnérabilité technique : code non patché, dépendance compromise, certificat rotaté trop tard. Un DSI pouvait se dire “je patche, je scanne, je surveille mes CVE, je suis couvert”.

Ici, rien de tout ça. Context.ai n’avait pas de faille. L’OAuth accordé par ses clients était correct, signé, révocable. Le pivot s’est fait sur une autorisation légitime qui n’aurait déclenché aucune alerte. Le réflexe “patcher plus vite” ne change rien. La seule défense, c’est de savoir quelles clés sont en circulation — et de les révoquer quand elles ne servent plus.

Ce n’est pas un incident Vercel, c’est un incident d’autorisation

Ce qui rend ce cas instructif, c’est que Vercel est accessoire. Le même scénario fonctionne avec n’importe quelle entreprise utilisant un outil IA avec un scope OAuth large. Et ces outils se multiplient.

Les assistants de réunion — Otter.ai, Fireflies.ai, Fathom, Read.ai, Grain, Circleback, Context.ai — demandent typiquement un accès lecture au Calendar et aux emails. Les outils de prospection commerciale type Lavender, Amplemarket ou Clay demandent un accès écriture à Gmail. Les gestionnaires d’emails IA comme Superhuman AI ou Shortwave demandent les deux.

Chaque scope est une clé réutilisable pendant des mois sans qu’un administrateur s’en rende compte. VentureBeat parle d’une “OAuth gap” que la plupart des équipes sécurité ne détectent pas : le SIEM voit l’application comme “approuvée” une fois pour toutes. C’est aussi l’angle mort du Shadow AI, où les employés ajoutent des outils sans passer par l’IT. Pour une discussion plus large sur la gouvernance des agents IA en PME, le cas Vercel confirme que la couche d’autorisation mérite autant d’attention que la couche réseau.

La checklist 7 points à appliquer ce soir

Voici ce qu’un dirigeant de PME peut faire en 2 heures sur son tenant Google Workspace ou Microsoft 365. La démarche est identique sur les deux plateformes, seuls les chemins d’administration diffèrent.

1. Lister toutes les applications OAuth connectées. Dans Google Workspace Admin : Sécurité > Contrôles des applications > App access control. Dans Microsoft 365 : Entra ID > Applications d’entreprise. Exportez la liste. Faites l’inventaire en équipe.

2. Révoquer les applications inutilisées. Toute application non utilisée depuis 90 jours est un candidat à la révocation. Si un employé revient dessus, il réaccordera le scope en 30 secondes. Le coût d’une révocation excessive est minuscule ; le coût d’un token dormant exploité est majeur.

3. Auditer les scopes pour chaque application active. Posez la question : pourquoi cet outil a-t-il besoin de lire tous mes emails ? Un assistant de réunion n’a pas besoin d’un scope gmail.readonly général — un accès au Calendar suffit. Imposez le scope le plus restreint disponible.

4. Activer les alertes de nouvelle autorisation OAuth. Google Workspace : Security Center > Alert Center, activer “Nouvelle application OAuth autorisée”. Microsoft 365 : Defender > Incident rules. L’objectif : être notifié à chaque nouvelle approbation d’outil, avec le scope demandé.

5. Imposer la MFA sur tous les comptes administrateurs. Le bulletin Vercel insiste sur ce point. La MFA ne bloque pas un OAuth déjà accordé, mais elle bloque la compromission initiale du compte admin.

6. Préférer les tokens de session courts. Quand l’outil le propose, choisissez la ré-authentification tous les 7 jours plutôt que le token longue durée. Un peu plus de friction utilisateur, beaucoup moins de fenêtre d’exploitation.

7. Planifier un audit trimestriel dans le calendrier. Bloquez une heure tous les trois mois dans l’agenda du responsable IT ou du dirigeant. À chaque passage : rejouer les étapes 1 à 4. C’est cette discipline, pas un outil, qui fait la différence.

Pour les PME concernées par NIS2, ces sept points recoupent directement l’exigence “gestion des tiers” de la directive. L’audit OAuth n’est plus une bonne pratique — c’est une obligation de conformité qui arrive.

Ce que Vercel change pour les dirigeants PME

Vous ne pouvez pas empêcher un infostealer de circuler chez l’éditeur d’un outil tiers. Ce qui est dans votre périmètre, c’est la liste des autorisations accordées par vos collaborateurs et la discipline avec laquelle vous la relisez.

Chaque intégration IA qui lit vos emails ou vos documents est un point d’entrée qui survit à la compromission de son éditeur. À l’inverse des CVE complexes, l’audit OAuth ne demande pas d’expertise technique pointue : une heure par trimestre et une décision claire sur ce que votre entreprise accepte de laisser voir, à qui, et pour combien de temps.

C’est le type d’audit que LeCollectif accompagne pour les PME qui déploient des outils IA. Si vous voulez un état des lieux de vos autorisations OAuth avant que le prochain Context.ai ne fasse parler de lui, parlons-en.