Une application OAuth tierce, un compte Google Workspace compromis, une poignée de variables d’environnement mal classifiées. Il n’en a pas fallu davantage pour que Vercel, pilier de l’écosystème de déploiement moderne et maison mère de Next.js, confirme en avril 2026 un incident de sécurité ayant exposé un sous-ensemble restreint de ses clients. L’épisode n’a interrompu aucun service, mais il agit comme un révélateur brutal : le périmètre de sécurité du cloud contemporain ne se dessine plus autour de l’infrastructure ni du code, mais au niveau des chaînes de confiance SaaS qui irriguent silencieusement chaque organisation.

La société dirigée par Guillermo Rauch a communiqué avec une transparence inhabituelle dans le secteur : indicateurs de compromission publiés, vecteur initial détaillé, reconnaissance explicite que l’attaquant a progressé plus loin que prévu grâce à des secrets non classés comme sensibles. Cette franchise contraste avec les silences fréquents du secteur et alimente un débat qui concerne l’ensemble des plateformes PaaS, des équipes DevOps et des responsables sécurité : comment contenir une menace qui ne passe plus par la porte d’entrée, mais par les dizaines d’intégrations OAuth autorisées au fil de l’eau ?

Ce que Vercel a confirmé officiellement

Dans son bulletin de sécurité daté d’avril 2026, Vercel confirme un accès non autorisé à une partie de ses systèmes internes, affectant « un sous-ensemble limité » de clients. L’entreprise insiste sur trois points : la plateforme publique n’a pas été exploitée par une vulnérabilité classique, les services de production sont restés opérationnels durant toute la fenêtre d’incident, et les projets open source du groupe — Next.js, Turbopack, la collection d’outils front-end — n’ont pas été compromis.

L’enquête est menée en collaboration avec des experts externes en réponse à incident, et les autorités compétentes ont été notifiées. Vercel précise que les variables d’environnement marquées comme sensibles étaient correctement chiffrées au repos, conformément à ses engagements contractuels. En revanche, l’attaquant a exploité une faiblesse de classification : toutes les variables n’étaient pas étiquetées « sensible », et une fraction suffisante pour permettre une escalade a pu être énumérée depuis le compte compromis.

Périmètre de l’accès non autorisé : systèmes internes et clients touchés

Le point d’entrée n’est pas Vercel, mais un outil d’intelligence artificielle tiers : Context.ai, utilisé par un employé via une intégration OAuth dans Google Workspace. Une fois cette application compromise, l’attaquant a pris le contrôle du compte professionnel de l’employé et s’est appuyé sur les permissions déléguées pour pivoter vers certains environnements internes de Vercel. De là, il a énuméré des variables d’environnement et accédé à des informations opérationnelles qui, prises isolément, ne semblaient pas critiques.

Le périmètre exact des clients affectés n’a pas été rendu public, mais Vercel a procédé à des notifications individuelles et publie des indicateurs de compromission (IoC) destinés aux administrateurs Google Workspace. L’entreprise recommande à ses utilisateurs de vérifier les applications OAuth autorisées dans leurs propres tenants, de faire pivoter les secrets suspects et d’auditer les activités récentes sur les comptes ayant des permissions de déploiement. Aucune donnée client de production — bases de données, code source, artefacts de build — n’a été signalée comme exfiltrée à ce stade de l’enquête.

Chronologie de l’incident Vercel

Vercel n’a pas publié d’horodatage précis pour chaque étape, mais les éléments connus permettent de reconstruire la séquence. Le compromis initial de Context.ai est antérieur de plusieurs jours à la détection par Vercel — un délai classique dans ce type d’attaque, où l’exploitation d’une intégration OAuth peut rester invisible plusieurs semaines. Lorsque l’activité anormale est repérée sur le compte Google Workspace de l’employé, les équipes de sécurité révoquent l’accès, rotent les identifiants et déclenchent une réponse à incident formelle.

Dans les jours suivants, Vercel mobilise des experts externes, étend l’investigation à l’ensemble de ses environnements internes et cartographie les variables potentiellement exposées. Le tableau de bord d’administration est mis à jour pour améliorer la visibilité sur les variables d’environnement et leur classification — un aveu implicite que l’interface précédente n’aidait pas suffisamment les équipes clientes à distinguer ce qui devait être chiffré de ce qui ne l’était pas. La publication du bulletin public et des IoC intervient ensuite, accompagnée de recommandations concrètes à destination des clients.

Les enseignements pour l’écosystème cloud moderne

Cet incident n’est pas un accident isolé : il condense en un seul scénario plusieurs angles morts récurrents des architectures cloud contemporaines. Pour les équipes DevOps, SRE et sécurité, la lecture technique doit dépasser la simple analyse des faits bruts et interroger les pratiques en profondeur.

Supply chain SaaS : la confiance déléguée n’est pas gratuite

Chaque application OAuth approuvée dans Google Workspace, Microsoft 365 ou Slack étend mécaniquement la surface d’attaque de l’organisation. Une application SaaS qui obtient des permissions de lecture sur les e-mails, les fichiers ou les calendriers devient, en pratique, une extension critique de l’infrastructure d’entreprise. Si ce tiers est compromis, les permissions déléguées deviennent immédiatement exploitables. Le cas Vercel illustre ce que des travaux comme le rapport d’IBM X-Force 2026 décrivent depuis des mois : les attaquants ne changent pas de scénario, ils accélèrent sur les maillons faibles de la chaîne de confiance.

Tokens OAuth : le nouveau périmètre d’authentification

Les jetons OAuth sont devenus le Graal des attaquants modernes. Contrairement à un mot de passe, un token n’est pas protégé par un second facteur d’authentification lorsqu’il est réutilisé par une application déjà autorisée. Les scopes accordés — souvent trop larges par facilité — permettent à un attaquant qui dérobe ces tokens d’accéder à des ressources sans déclencher les alertes classiques de connexion suspecte. La rotation régulière des tokens, la limitation stricte des scopes et l’audit continu des applications autorisées deviennent des pratiques non négociables.

Secrets et variables d’environnement : ce qui n’est pas classé existe quand même

L’épisode Vercel met le doigt sur une pratique encore très répandue : la classification binaire entre variables « sensibles » et « non sensibles ». Or, une variable qui ne contient ni clé API ni mot de passe peut révéler l’architecture interne, les chemins de services, les endpoints privés, les noms de comptes ou les suffixes de domaines qui, agrégés, construisent une carte exploitable pour l’étape suivante de l’attaque. La sécurité moderne doit considérer toute métadonnée opérationnelle comme potentiellement sensible par défaut, et non par exception.

CI/CD : la chaîne qui déploie est la chaîne qui trahit

Les pipelines d’intégration et de déploiement continus concentrent l’ensemble des secrets nécessaires pour pousser du code en production. Une action GitHub compromise, une dépendance malveillante ou une intégration SaaS détournée peuvent exfiltrer ces secrets en temps réel. Les initiatives comme Signing Transparency de Microsoft vont dans le bon sens en introduisant un notaire cryptographique sur la chaîne logicielle, mais elles ne résolvent pas à elles seules le problème de la confiance excessive accordée aux intégrations tierces.

Comparaison avec d’autres incidents récents

Le cas Vercel s’inscrit dans une série d’incidents qui partagent un même ADN : la compromission d’un maillon intermédiaire à haut privilège plutôt que l’attaque frontale d’une infrastructure cible. Trois épisodes majeurs des dix-huit derniers mois méritent d’être relus à la lumière de cet événement.

En août 2025, Salesloft Drift a été victime d’un vol massif de jetons OAuth liés à son intégration avec Salesforce. L’attaque a débouché sur une campagne de vol de données chez de nombreux clients, dont Cloudflare, qui a publiquement reconnu l’exposition partielle de certaines données. Salesforce a fini par désactiver l’ensemble des intégrations Drift en urgence. Le parallèle avec Vercel est frappant : dans les deux cas, un SaaS tiers approuvé sert de tremplin vers l’environnement interne de la victime. L’article détaillé sur Cloudflare et Salesloft Drift documente la mécanique complète.

En mars 2025, la GitHub Action tj-actions/changed-files, utilisée par plus de 23 000 dépôts, a été compromise. Les secrets présents dans les workflows CI/CD ont potentiellement été exfiltrés via les logs. Quelques jours plus tard, reviewdog/action-setup subissait un scénario similaire. Ces deux incidents démontrent que la chaîne d’approvisionnement logicielle ne se limite pas aux bibliothèques npm ou PyPI : chaque composant réutilisable du pipeline — actions, images Docker, templates Terraform — constitue un vecteur potentiel.

Plus ancienne mais toujours pertinente, l’affaire Okta / Lapsus$ de 2022 puis la compromission répétée du support Okta en 2023 ont montré comment un fournisseur d’identité peut devenir le point d’entrée ultime. Heroku et CircleCI ont également subi des vols d’identifiants clients en 2022-2023, avec un schéma récurrent : l’attaquant ne cherche plus la faille zero-day, il cherche l’intégration oubliée.

Bonnes pratiques pour les clients Vercel et autres plateformes PaaS

Pour les équipes utilisant Vercel, Netlify, Railway, Render ou toute autre plateforme de déploiement moderne, l’incident fournit une check-list opérationnelle immédiatement applicable. La première mesure consiste à auditer l’ensemble des applications OAuth autorisées dans les tenants Google Workspace et Microsoft 365 liés au développement : chaque application inutilisée ou au scope excessif doit être révoquée sans délai.

La deuxième priorité concerne la classification systématique des variables d’environnement. Le principe doit être inversé : toute variable est sensible par défaut, sauf preuve explicite du contraire. Les plateformes comme Vercel proposent désormais un flag « sensitive » qui active le chiffrement au repos et masque la valeur dans l’interface ; il doit être appliqué sans exception aux clés API, tokens, chaînes de connexion, webhooks signés et identifiants de services.

La troisième mesure consiste à segmenter les permissions CI/CD. Aucun compte de déploiement ne devrait disposer de scopes administrateur globaux. Les tokens de déploiement doivent être limités à un projet, à une branche ou à un environnement, et leur durée de vie doit être la plus courte possible. L’usage d’identités fédérées OIDC entre GitHub Actions et les plateformes cloud élimine le besoin de stocker des secrets longue durée et réduit considérablement l’impact d’une exfiltration.

Enfin, l’observabilité des identités doit être traitée avec le même sérieux que l’observabilité applicative. Les alertes sur les connexions depuis des IP inhabituelles, les élévations de privilèges, les créations de tokens OAuth ou les modifications de scopes doivent être routées vers le SIEM et déclencher des revues humaines rapides. Des acteurs comme Palo Alto Networks, dont l’acquisition récente de Koi cible précisément la sécurité des agents d’IA, industrialisent cette approche pour les environnements où les identités se multiplient plus vite que les contrôles manuels.

Questions fréquentes

Quelle est l’ampleur réelle de l’incident Vercel ?

Vercel parle d’un « sous-ensemble limité » de clients affectés, sans chiffre public précis. L’accès non autorisé a concerné certains systèmes internes et des variables d’environnement non classées comme sensibles. Les projets open source (Next.js, Turbopack) n’ont pas été compromis, et aucune exfiltration massive de données de production n’a été signalée à ce jour.

Faut-il quitter Vercel après cet incident ?

Non. La réaction de Vercel — transparence, publication d’IoC, mises à jour du tableau de bord — correspond aux standards attendus d’un fournisseur mature. Le vecteur d’attaque (OAuth tiers compromis) peut toucher n’importe quelle plateforme utilisant Google Workspace ou Microsoft 365. La bonne réaction consiste à auditer ses propres intégrations et à appliquer les recommandations publiées plutôt qu’à changer de fournisseur.

Comment savoir si mon tenant Google Workspace est à risque ?

Consultez la liste des applications OAuth autorisées dans la console d’administration Google Workspace. Vérifiez la présence d’applications comme Context.ai ou d’autres outils d’IA récemment ajoutés avec des scopes étendus. Examinez les logs d’audit des 90 derniers jours pour détecter des connexions inhabituelles, puis appliquez les indicateurs de compromission publiés par Vercel dans son bulletin officiel.

Quelle différence entre une variable « sensible » et « non sensible » chez Vercel ?

Les variables marquées « sensible » sont chiffrées au repos et masquées dans l’interface d’administration. Les variables non marquées restent accessibles en clair aux utilisateurs disposant de permissions sur le projet. L’incident a démontré que l’attaquant a pu énumérer les variables non classées, récupérant des informations opérationnelles exploitables. La recommandation actuelle est de marquer comme sensible toute variable qui n’est pas strictement publique.

Les autres plateformes PaaS sont-elles exposées au même risque ?

Oui. Toute plateforme qui s’appuie sur Google Workspace, Microsoft 365, Slack ou GitHub pour l’authentification de ses équipes internes partage la même surface d’attaque OAuth. Netlify, Railway, Render, Fly.io et les services équivalents sont exposés au même vecteur. La question n’est pas la plateforme cible, mais la maturité des contrôles d’identité et de classification des secrets dans l’organisation cliente.

Source : Vercel Security Bulletin