Vercel piraté via Context.ai : OAuth volé, Google compromis

Ce qui s'est passé

Vercel, hébergeur de référence des frameworks frontend modernes, a publié le 27 avril 2026 un bulletin reconnaissant un incident de sécurité dont l'origine se situe chez Context.ai, un outil d'intelligence artificielle tiers utilisé par l'un de ses employés. La chaîne d'attaque Vercel Context.ai OAuth illustre les risques des applications connectées : après avoir compromis Context.ai, l'attaquant a récupéré les jetons OAuth émis pour cette intégration, puis les a rejoués pour accéder au compte Google professionnel de l'employé concerné. Ce rebond lui a ouvert la messagerie et les documents associés, sans jamais déclencher d'authentification multifacteur, les tokens contournant par nature cette barrière. Vercel affirme que ses systèmes de production, son infrastructure et les données clients n'ont pas été touchés. L'incident rappelle qu'une autorisation OAuth accordée à un service SaaS tiers devient un point d'entrée permanent.

Cette divulgation s'inscrit dans une vague d'incidents touchant les chaînes d'intégration SaaS-vers-SaaS où l'attaquant exploite la confiance qu'un éditeur principal accorde à un outil tiers via OAuth. Les principes décrits dans l'abus du consentement OAuth/OIDC trouvent ici un exemple concret : la compromission de l'émetteur secondaire suffit à compromettre l'émetteur principal sans toucher directement à son infrastructure.

Pourquoi c'est important

Vercel sert des dizaines de milliers d'applications React, Next.js et Svelte en production, dont nombre de marques cotées. Une compromission de l'hébergeur lui-même aurait constitué un événement supply chain de premier ordre ; l'éditeur a contenu l'incident à un compte employé et à des secrets non sensibles, mais le vecteur — un outil IA connecté en OAuth — devient un schéma récurrent. Les équipes plateformes doivent désormais traiter chaque application OAuth installée comme une extension de leur surface d'attaque, au même titre que les attaques sur les identity providers Okta et Entra ou les compromis détaillés dans les attaques sur les pipelines CI/CD GitHub. La leçon vaut aussi pour les politiques de durcissement des accès Microsoft 365 où le consentement utilisateur final reste souvent permissif par défaut.

Ce qu'il faut retenir

• Inventoriez les applications OAuth tierces connectées à votre Google Workspace et à vos comptes Vercel ou GitHub.
• Révoquez les autorisations OAuth pour tout outil IA expérimental ou abandonné, et exigez l'approbation d'un admin pour tout nouveau scope.
• Surveillez les actions inattendues sur les variables d'environnement de production : énumération massive ou déchiffrement par un compte employé constitue un signal fort.

Cet incident rappelle plusieurs compromissions récentes bâties sur le même schéma de « confused deputy » OAuth. En mars 2025, la campagne Salesloft Drift avait permis à un attaquant de siphonner des tokens OAuth d'intégration Salesforce pour atteindre des dizaines de clients, dont Cloudflare, Palo Alto Networks et Google lui-même côté Workspace. En 2023, la compromission de l'infrastructure de support Okta avait de la même façon servi de tremplin vers des clients tiers via des sessions et tokens de session volés. Dans les trois cas, l'attaquant ne cible jamais frontalement l'éditeur principal : il vise le maillon le plus faible de sa chaîne d'outils connectés — un CRM, un agent conversationnel, une plateforme de support — puis capitalise sur la confiance OAuth accordée par des employés pour rebondir vers des environnements plus sensibles. Selon les données compilées par Verizon dans son DBIR, la part des brèches impliquant un tiers de la chaîne d'approvisionnement logicielle a doublé en trois ans, passant d'environ 15 % à plus de 30 % des incidents analysés, une tendance que confirme le rythme des divulgations 2026.

Le choix de Context.ai comme point d'entrée illustre un angle mort spécifique à l'essor des outils d'IA générative en entreprise : ces applications demandent fréquemment des scopes OAuth larges (accès Gmail, Drive, Calendar, dépôts de code) pour fonctionner, sans que les équipes sécurité disposent toujours d'un inventaire à jour des connecteurs autorisés ni d'une politique de révocation automatique en cas d'inactivité. Plusieurs éditeurs de CASB et de gestion des identités, dont Push Security et Wing Security, ont documenté courant 2026 une explosion du nombre d'applications tierces connectées en OAuth dans les organisations utilisant des outils d'IA, souvent approuvées par un employé isolé sans validation centralisée — un phénomène parfois qualifié de « shadow AI » par extension du shadow IT classique. Pour un hébergeur comme Vercel, dont le modèle économique repose entièrement sur la confiance accordée par des développeurs déployant du code en production, la vitesse de détection et de confinement (révocation du compte, invalidation des tokens, rotation des secrets) a probablement évité un scénario bien plus grave, comparable à l'incident CodeCov de 2021 où un script de build compromis avait exfiltré des secrets chez des centaines de clients pendant des mois avant détection.

Mon application Vercel est-elle directement à risque ?

Vercel affirme qu'aucun build client n'a été altéré et qu'aucune signature de déploiement n'a été détournée, ce qui exclut à ce stade une compromission de type supply chain sur le code livré aux utilisateurs finaux. Le risque résiduel porte sur les variables d'environnement non sensibles qui auraient pu transiter par les environnements internes consultés par l'attaquant : les équipes techniques restent invitées à vérifier, via le dashboard Vercel, l'historique de rotation de leurs secrets et à activer si ce n'est pas déjà fait l'authentification à double facteur sur les comptes disposant de droits d'administration sur leurs projets.