Rotation, redéploiement, révocation : la réponse webvise à l'incident Vercel

Le 19 avril 2026, Vercel a divulgué un incident de sécurité attribué à une application OAuth tierce compromise au sein de leur Google Workspace. La réponse a été appliquée à chaque projet Vercel géré par webvise avant la fin du week-end, et les journaux d'audit côté Vercel comme côté Google Workspace sont revenus sans anomalie. Il ne s'agissait pas d'une vulnérabilité dans le code de Vercel. C'était une compromission SaaS-to-SaaS via une limite de confiance OAuth, et la nature de cet incident change ce à quoi doit ressembler une réponse adéquate.

La rotation des secrets dans votre tableau de bord Vercel représente peut-être la moitié de la réponse. L'autre moitié se trouve dans Google Workspace, et la plupart des analyses publiées ne la couvrent pas.

Vous avez lu la divulgation et renouvelé chaque clé que vous avez pu trouver. C'est le bon premier réflexe. Cet article décrit ce qui a réellement été exécuté de bout en bout, le point technique qui conditionne l'efficacité de la rotation sur les fonctions en cours d'exécution, et pourquoi la nature de cet incident doit changer la forme de votre plan de réponse pour la prochaine fois.

• La rotation des variables d'environnement Vercel met à jour la configuration, pas les instances de fonctions en cours d'exécution ; un redéploiement est nécessaire pour propager les modifications. Les valeurs ne prennent effet qu'au déploiement suivant.
• L'audit OAuth Google Workspace est la moitié à peine abordée. C'est le chemin de confiance qu'a emprunté l'attaquant pour atteindre Vercel.
• Il ne s'agissait pas d'une vulnérabilité Vercel. C'était une compromission SaaS-to-SaaS via un grant OAuth, et une réponse standard de type CVE ne ferme pas la boucle.
• À long terme, sortez les secrets des variables d'environnement et placez-les dans un gestionnaire de secrets à l'exécution. Exigez un MFA résistant au phishing pour toute personne autorisée à installer des applications OAuth.
• Des audits mensuels des grants OAuth tiers dans votre fournisseur d'identité font désormais partie de la référence de base, pas d'une amélioration de maturité.

Ce que Vercel a réellement divulgué

En résumé : une application SaaS tierce disposant d'un accès OAuth au sein du Google Workspace de Vercel a été compromise, et l'attaquant a exploité cette limite de confiance pour accéder aux valeurs des variables d'environnement sur un sous-ensemble de projets clients. Vercel a publié un identifiant de client OAuth comme indicateur de compromission et a demandé à chaque client de renouveler tout secret stocké sous forme de variable d'environnement. Rien dans cet incident n'implique une vulnérabilité dans le propre code de Vercel. La surface d'attaque était le graphe de confiance entre deux outils SaaS.

Cela importe pour la façon dont vous répondez. Si la vulnérabilité se trouve dans le code de la plateforme elle-même, vous corrigez, renouvelez ce qui a fui, et passez à autre chose. Si elle se trouve dans le chemin de confiance entre plateformes, la rotation est nécessaire mais ne ferme pas la faille. Vous devez également révoquer le grant emprunté par l'attaquant : sans cela, la prochaine compromission de ce même outil reproduira le même périmètre d'impact.

Si vous souhaitez une seconde revue de votre configuration Vercel avant le prochain incident, webvise effectue des audits de sécurité sur les équipes Vercel, les Google Workspaces et les grants SaaS-to-SaaS.

Étape 1 : renouveler les secrets qui comptent vraiment

Chaque variable d'environnement susceptible d'accorder un accès à quoi que ce soit a été traitée comme compromise par défaut. C'est l'hypothèse qu'impose la divulgation. Voici les catégories de secrets réémis sur les projets gérés.

• Identifiants de base de données. Chaînes de connexion, mots de passe des réplicas en lecture seule et clés de rôle administrateur sur chaque projet avec un backend de base de données.
• Clés API Resend pour les e-mails transactionnels sur chaque projet envoyant des messages de vérification, de notification ou d'inscription.
• Identifiants Google API pour les intégrations Workspace, Calendar, Drive et Analytics exécutées côté serveur.
• Clés AI Gateway incluant les jetons d'accès aux modèles, les identifiants fournisseurs et les jetons de limitation de débit pour tout ce qui transite par la passerelle.
• Identifiants d'intégration d'ingestion pour les endpoints webhook, les pipelines d'événements et tout ce qui extrait des données dans le projet depuis l'extérieur.

Deux catégories méritent une vérification approfondie : les variables se terminant par `_URL` qui intègrent des identifiants dans des chaînes de connexion, et tout ce qui est étiqueté `_TEST` ou `_DEV` mais qui pointe en réalité vers la production. Renouvelez-les avec le reste. Un attaquant lisant des variables d'environnement ne se soucie pas du flag choisi ni de ce que le nom de la variable suggère.

Étape 2 : redéployer (le point technique qui rend la rotation effective)

C'est l'étape que la plupart des listes de contrôle de réponse traitent insuffisamment. Vercel applique les modifications de variables d'environnement au moment de la construction et du déploiement, pas à l'exécution. Un projet mis à jour et laissé tel quel continue d'exécuter la construction livrée la veille, avec l'ancien secret toujours intégré dans son environnement d'exécution. Vous avez renouvelé la valeur dans le tableau de bord, pas dans le système.

Version concrète : vous renouvelez votre clé API Resend à 10 h 14 et ouvrez un nouvel onglet pour vérifier autre chose. Une fonction tente d'envoyer un e-mail de vérification à 10 h 17, appelle Resend avec l'ancienne clé encore intégrée dans son environnement déployé, et Resend rejette la requête. L'utilisateur ne reçoit pas son e-mail. Multipliez cela par chaque fonction, chaque tâche planifiée et chaque gestionnaire de webhook tournant sur l'ancienne construction.

Pour vérifier votre réponse, ouvrez l'onglet Deployments sur chaque projet et repérez un déploiement horodaté après votre rotation. Si la première ligne affiche un horodatage antérieur à la rotation, celle-ci n'a été intégrée dans aucun processus en cours d'exécution. La deuxième étape explicite de la réponse a été un redéploiement forcé en production sur chaque projet géré après la rotation, avant de passer à la suite.

Étape 3 : révoquer le grant OAuth Google Workspace

C'est la moitié de la réponse qui a à peine été abordée dans les discussions du week-end. L'incident a pris naissance dans Google Workspace. L'attaquant est entré via une application OAuth tierce disposant d'une portée accordée dans Workspace, puis a pivoté vers Vercel via un chemin de confiance SaaS-to-SaaS. Si vous n'avez effectué la rotation que du côté Vercel, la même application OAuth est toujours présente avec la même portée, prête à être exploitée lors de sa prochaine compromission.

Le chemin dans votre console d'administration : admin.google.com, sécurité, contrôles API, contrôle d'accès des applications, applications tierces. Recherchez l'identifiant de client OAuth publié par Vercel comme indicateur de compromission. Révoquez-le s'il est présent. Puis faites la chose plus difficile : passez en revue chaque autre grant OAuth dans la liste, confirmez que chaque portée était intentionnelle, et révoquez tout ce que vous n'avez pas de raison valable de conserver.

Cet audit a été effectué sur chaque Workspace administré. L'indicateur était absent, et la plupart des grants avaient une finalité commerciale légitime. Quelques-uns n'en avaient pas, et ont été révoqués. La cadence est désormais mensuelle : auditer les grants OAuth au début de chaque mois, révoquer tout ce qui n'a pas été utilisé depuis 30 jours.

Étape 4 : les mesures à long terme

La rotation et la révocation ont traité l'exposition immédiate. Les mesures à plus long terme sont ce qui empêche le prochain incident de se transformer en course contre la montre un week-end. Elles sont déployées sur les projets gérés au cours des prochaines semaines, et constituent la recommandation pour toute équipe exploitant une infrastructure fortement orientée SaaS.

• Récupérer les secrets à l'exécution depuis un gestionnaire de secrets plutôt que de les intégrer dans des variables d'environnement. La rotation devient une mise à jour centralisée, pas un redéploiement.
• Des identifiants à courte durée de vie pour les bases de données et les API partout où le fournisseur les prend en charge. Une validité de quelques minutes, pas de plusieurs mois.
• Une rotation planifiée pour les identifiants qui ne peuvent pas être rendus éphémères. Pilotée par le calendrier, pas par les incidents.
• Un MFA résistant au phishing sur chaque compte administrateur pouvant installer des applications OAuth dans votre fournisseur d'identité. Passkeys ou jetons matériels, rien de basé sur SMS.
• Des audits mensuels des grants OAuth dans Workspace, Microsoft 365, ou quel que soit le fournisseur d'identité utilisé. Le chemin de l'attaquant cette fois était un grant OAuth ; il le sera aussi la prochaine fois.

De nombreuses équipes n'ont pas de responsable désigné pour ces tâches ; cet écart revient régulièrement dans les post-mortems d'incidents. Prenez contact pour voir comment webvise intègre ces éléments dans le contrat de maintenance de chaque projet géré.

Pourquoi cet incident est différent

Le modèle défensif doit correspondre au modèle d'attaque. Cela signifie traiter les grants OAuth comme des dépendances de production, les auditer selon un calendrier, et sortir les secrets des variables d'environnement où un attaquant disposant de ce grant peut les lire. Les journaux d'audit sont revenus sans anomalie ce week-end : c'est le bénéfice propre à cet incident, même si le modèle de réponse doit encore être planifié de façon récurrente.

Un attaquant compromet un outil SaaS autorisé par votre équipe, puis exploite la relation de confiance entre cet outil et vos autres outils SaaS pour accéder à des données qu'aucun des deux n'aurait données à un inconnu. Votre compte Vercel n'a pas été compromis, votre Google Workspace non plus. Un outil tiers connecté des mois auparavant a été compromis, et les portées accordées à cet outil ont propagé la compromission en aval.

Traitez cela comme un rythme opérationnel, pas comme un nettoyage ponctuel.

Les audits de sécurité sur les équipes Vercel, les Google Workspaces et les graphes d'identité SaaS-to-SaaS font partie de chaque engagement géré chez webvise. Si vous souhaitez une seconde revue de votre configuration Vercel avant le prochain incident, prenez contact.