Vercel a confirmé un incident de sécurité qui a touché « un sous-ensemble restreint » de clients suite à un accès non autorisé à certains systèmes internes. La société, largement reconnue pour son rôle dans l’écosystème de déploiement web, Next.js, edge et fonctions serverless, a assuré que ses services sont restés opérationnels et que l’enquête est toujours en cours, avec le soutien d’experts externes et la notification des autorités compétentes.

Ce qui est particulièrement intéressant dans cette affaire, ce n’est pas seulement la compromission de Vercel, mais aussi le vecteur d’attaque. Selon leur propre bulletin, l’accès initial n’a pas résulté d’une vulnérabilité classique de leur plateforme publique, mais du compromis de Context.ai, un outil d’intelligence artificielle tierce utilisé par un employé. À partir de là, l’attaquant a pris le contrôle du compte Google Workspace de cet employé et a réussi à accéder à certains environnements internes ainsi qu’à des variables d’environnement non marquées comme « sensibles ».

Ce détail modifie considérablement la lecture technique de l’incident. Il ne s’agit pas simplement d’un « piratage de Vercel », mais d’un exemple très actuel d’attaque à la chaîne de confiance dans les solutions SaaS : une application OAuth tierce, une identité d’entreprise compromise et une escalade interne exploitant des secrets et des métadonnées opérationnelles. Guillermo Rauch, CEO de la société, a également indiqué que les variables marquées « sensibles » étaient bien chiffrées au repos, mais a reconnu que l’attaquant a avancé en énumérant des variables non étiquetées comme sensibles.

Pour les acteurs du secteur technologique, cette partie est particulièrement essentielle. Pendant des années, la sécurité du cloud s’est concentrée sur l’exposition incorrecte des buckets, les identifiants codés en dur ou les défaillances dans les pipelines. Ce cas indique une réalité différente : le périmètre de sécurité ne se limite plus à l’infrastructure ou au code, mais englobe la complexité des applications connectées via OAuth, les identités fédérées et les permissions octroyées à des outils « productifs » qui intègrent l’organisation avec beaucoup moins de friction qu’un agent traditionnel.

Vercel a réagi en publiant des indicateurs de compromission pour les administrateurs Google Workspace, en recommandant de vérifier l’application OAuth concernée, de faire pivoter les secrets si nécessaire et d’utiliser la fonction de variables sensibles pour assurer leur chiffrement au repos. La société a également mis à jour son tableau de bord pour améliorer la visibilité sur les variables d’environnement et leur classification. En outre, elle précise que Next.js, Turbopack et ses projets open source n’ont pas été compromis.

Ce que révèle l’incident : SaaS, OAuth et secrets restent des points faibles

Le constat principal est embarrassant : de nombreuses organisations continuent de percevoir OAuth comme une simple commodité d’intégration, plutôt que comme une extension directe de leur surface d’attaque. Lorsqu’une application tierce obtient des permissions étendues sur Google Workspace, Salesforce ou GitHub, elle passe du rôle d’outil à celui d’infrastructure critique. Si cette application est compromise, l’impact peut rapidement se propager vers des environnements qui semblaient bien protégés.

Dans le cas de Vercel, un autre schéma classique des environnements de développement modernes apparaît : la sous-estimation des informations « non sensibles ». En environnement cloud, une variable non identifiée comme critique peut contenir des noms de services, chemins internes, endpoints, identifiants de comptes ou suffisamment d’informations pour permettre une seconde étape d’attaque. Cela rappelle que la classification des secrets ne peut pas simplement dépendre de si une chaîne « ressemble » à une clé API. Le contexte est tout aussi important.

Tableau : Autres incidents récents et concrets liés

Ce tableau montre une tendance claire : ces incidents, bien qu’issus de contextes différents, partagent une idée centrale : les attaquants n’ont plus besoin d’attaquer directement l’infrastructure. Il leur suffit de compromettre un élément intermédiaire à haut privilège — une application OAuth, une intégration CRM, ou une action CI/CD — et de laisser la confiance accumulée faire le reste.

Le problème n’est plus seulement de sécurité, mais aussi de gouvernance technique

Pour les équipes DevOps, SRE, plateforme et sécurité, l’incident Vercel souligne une conclusion claire : la gestion des secrets, des scopes et des dépendances SaaS doit être traitée avec la même rigueur que l’exposition d’une API publique ou la segmentation d’un réseau privé virtuel (VPC). Il ne suffit pas de chiffrer les données « évidentes » ni de vérifier les permissions une fois par an. Un inventaire précis des applications connectées, une revue continue des scopes, des politiques de moindre privilège, et une observabilité robuste sont indispensables pour détecter quand une identité commence à accéder à des environnements qu’elle ne devrait pas toucher.

Vercel a agi de manière responsable : fournir les vecteurs d’attaque, partager des indicateurs de compromission, recommander des actions concrètes, et reconnaître que l’attaquant a progressé plus que prévu. Mais cet incident illustre également une tendance plus large : le cloud moderne ne se compromet pas uniquement par une erreur de configuration ou une faille de code. La majorité du risque réside dans la confiance excessive accordée à des services intégrés trop facilement, rapidement, avec trop de permissions. Et cette problématique n’est pas propre à Vercel : elle traverse tout le cycle de développement moderne.

Questions fréquentes

Que confirme exactement Vercel ?
Il y a eu un accès non autorisé à certains systèmes internes, affectant un sous-ensemble limité de clients, et l’origine provient du compromis de Context.ai, un outil externe utilisé par un employé.

Next.js ou Turbopack ont-ils été affectés ?
Non, selon la société. Vercel assure que ses projets open source, y compris Next.js et Turbopack, n’ont pas été compromis.

Pourquoi cet incident inquiète-t-il autant l’écosystème ?
Parce qu’il combine trois risques majeurs actuels : applications OAuth tierces, identités d’entreprise avec permissions excessives, et variables d’environnement pouvant servir de tremplins pour des escalades dans le cloud.

Quels points les équipes techniques doivent-elles vérifier ?
Les applications OAuth connectées à Google Workspace et autres SaaS critiques, les scopes octroyés, l’inventaire des variables d’environnement, et tout secret ou métadonnée opérationnelle stockée en dehors des mécanismes de chiffrement ou de classification renforcée.

Source : Vercel