Guide de réponse aux incidents Vercel avril 2026
Dernière mise à jour : 20 avril 2026 @ 12.07 PM AEST/Brisbane - (v2 — intègre la mise à jour du PDG de Vercel du 20 avril)
Que s’est-il passé ?
Vercel a divulgué le 19 avril 2026 qu'un attaquant a obtenu un accès non autorisé à des systèmes internes. Voici l'annonce officielle :
Le 20 avril, le PDG de Vercel, Guillermo Rauch, a publié une mise à jour détaillée confirmant le vecteur d'accès initial : un employé de Vercel utilisait une plateforme d'IA appelée Context.ai, qui a elle-même été compromise ; à partir de là, l'attaquant a pivoté vers le compte Google Workspace de l'employé et a escaladé les privilèges dans les environnements Vercel. Les variables d'environnement sont chiffrées au repos, mais l'attaquant a pu énumérer les variables non marquées comme « sensibles ». Vercel qualifie l'attaquant de très sophistiqué et probablement accéléré par l'IA. Google Mandiant est impliqué dans la réponse. Vercel déclare que Next.js, Turbopack et leurs projets open source restent sûrs.
Voici la section importante des indicateurs de compromission de cet avis de sécurité :
Assez peu de détails. Ils ne disent même pas où vérifier cet unique IOC Google. En tant que client Vercel, je suis assez déçu par ce niveau de détail. Aidez-moi à comprendre quoi chercher ! Dites-moi où aller pour savoir si j’ai été compromis ou non !
En l’absence de détails de la part de Vercel, nous avons créé ce document
Si vous exécutez des charges de travail sur Vercel, supposez ce qui suit jusqu’à preuve du contraire :
- Les variables d’environnement non marquées comme « sensibles » sur tout projet Vercel dans la fenêtre d’exposition peuvent avoir été lisibles.
- Tout identifiant poussé sur Vercel via le tableau de bord ou la CLI
vercel env qui n’est pas tourné est un passif permanent.
- Les jetons dans les chemins d’intégration Vercel ↔ GitHub et Vercel ↔ Linear peuvent avoir été accessibles.
- Vous n’obtiendrez pas un signal net « vous êtes concerné / vous n’êtes pas concerné » rapidement. Tournez d’abord, enquêtez ensuite.
Connu vs. revendiqué : gardez ces éléments séparés dans vos briefings
Cette distinction est importante pour les communications avec la direction et pour éviter une sur-réaction (ou une sous-réaction).
Confirmé par Vercel (bulletin + mise à jour du PDG du 20 avril)
- Accès non autorisé à certains systèmes internes de Vercel.
- Vecteur d’accès initial : Context.ai, une plateforme d’IA utilisée par un employé de Vercel, a été compromise. L’attaquant a utilisé ce point d’appui pour compromettre le compte Google Workspace Vercel de l’employé, puis a escaladé à partir de là dans les environnements Vercel.
- Les variables d’environnement des clients sont chiffrées au repos. Les variables désignées comme « non sensibles » étaient néanmoins énumérables par l’attaquant une fois à l’intérieur.
- L’impact client est qualifié de « tout à fait limité » ; Vercel a directement contacté les clients pour lesquels il a des inquiétudes.
- Next.js, Turbopack et les projets open source de Vercel ont été analysés et sont considérés comme restant sûrs (c’est-à-dire, aucun artefact malveillant dans le chemin de publication de ces projets selon la déclaration de Vercel du 20 avril).
- L’attaquant est qualifié de très sophistiqué et probablement considérablement accéléré par l’IA.
- Partenaires de réponse : Google Mandiant est activement engagé ; des sociétés externes de réponse aux incidents, des pairs du secteur et les forces de l’ordre sont impliqués.
- Vercel a contacté Context.ai pour aider à comprendre la portée complète.
- Vercel a déployé des améliorations de l’interface utilisateur : page de vue d’ensemble des variables d’environnement, gestion améliorée des variables d’environnement sensibles.
Rapporté / attribué par des tiers et l’attaquant (non confirmé par Vercel)
- Intégrations Linear et GitHub impactées de manière disproportionnée (rapport de la communauté, notamment Theo Browne sur X).
- Données listées en vente sur BreachForums : base de données interne, comptes employés, jetons GitHub, jetons npm, fragments de code source, horodatages d’activité — proposés à ~2 M$.
- L’acteur s’identifie comme ShinyHunters ; d’autres acteurs historiquement liés à ce pseudonyme ont nié toute implication.
- Classes de données clients spécifiques exfiltrées au-delà de ce que Vercel a directement confirmé avec les clients.
Traitez les signalements non confirmés comme plausibles et exploitables pour votre propre triage, mais ne les citez pas comme des faits dans les communications avec les clients ou les régulateurs tant que Vercel ne les a pas corroborés ou que vous n’avez pas de preuves indépendantes. L’écart entre « variables d’environnement énumérables » (confirmé par Rauch) et « jetons npm + GitHub en vente sur BreachForums » (revendication de l’attaquant) est l’écart le plus important pour le risque lié à la chaîne d’approvisionnement — supposez le pire pour les rotations, tenez-vous-en à la version confirmée pour les communications.
Cadrage : qui doit exécuter ce guide
Urgence la plus élevée — vous avez reçu un contact direct de Vercel, ou l’un des éléments suivants s’applique :
- Vous avez (ou avez eu) une intégration Vercel ↔ GitHub avec périmètre d’écriture sur des dépôts.
- Vous avez (ou avez eu) une intégration Vercel ↔ Linear.
- Vous stockez des secrets non chiffrés (non marqués comme sensibles) en tant que variables d’environnement Vercel.
- Vous publiez des packages npm depuis un CI/CD qui s’exécute sur ou via l’infrastructure Vercel.
Urgence standard — toute équipe avec des projets Vercel actifs, même des sites marketing. Les sites marketing contiennent souvent des clés API CMS, des jetons d’analyse et des webhooks de gestionnaires de formulaires qui pivotent vers des systèmes plus sensibles.
À faire quand même — même si vos projets ont été supprimés avant l’incident. La question est de savoir si des secrets ont jamais résidé chez Vercel sous une forme lisible, pas si le projet existe toujours.
Question parallèle : votre organisation est-elle directement exposée à Context.ai ?
La mise à jour du 20 avril nomme Context.ai comme le fournisseur en amont compromis. Si quelqu’un dans votre organisation utilise Context.ai indépendamment de Vercel — pour l’intelligence de réunion, la gestion des connaissances, l’enrichissement CRM ou tout autre flux de travail — vous pouvez avoir votre propre fenêtre d’exposition directe distincte de l’incident Vercel.
Effectuez ces vérifications en parallèle :
- Interrogez votre SSO / IdP (Okta, Entra, Google Workspace) pour tout utilisateur qui s’est authentifié auprès de Context.ai ou d’une application OAuth liée à Context.
- Recherchez dans votre console d’administration Google Workspace → Sécurité → Accès et contrôle des données → Contrôles des API pour les journaux d’accès aux applications OAuth contenant
context.ai ou les ID d’applications associés.
- Vérifiez les outils de gestion des dépenses d’entreprise / SaaS pour les abonnements Context.ai.
- Examinez les périmètres OAuth accordés — les périmètres de lecture Gmail, Calendrier, Drive et répertoire Workspace ont un impact élevé.
Si vous trouvez une utilisation de Context.ai dans votre environnement, révoquez les autorisations OAuth, tournez les identifiants qui ont transité par les flux de travail Context.ai et surveillez les comptes Google Workspace des utilisateurs concernés pour les mêmes indicateurs de compromission que Vercel décrit avoir vus sur le compte de son employé. Contactez Context.ai directement pour obtenir vos propres détails sur l’incident ; Vercel a déclaré publiquement qu’il coordonne avec Context pour aider d’autres organisations touchées.
Phase 0 : Arrêter l’hémorragie (premières 60 minutes)
Deux objectifs : éviter de nouveaux dommages, préserver les preuves.
-
Geler les déploiements. Mettez en pause les déploiements automatiques sur les branches de production. Vous voulez empêcher un build modifié par l’attaquant d’être livré, et vous voulez empêcher le journal d’audit de tourner.
-
Désactiver l’application GitHub de Vercel. Si vous avez installé l’application GitHub de Vercel, ce qui est le cas si vous faites des déploiements automatiques vers Vercel lorsque vous poussez du nouveau code sur GitHub. Vous trouverez vos applications GitHub installées à l’adresse https://github.com/organizations/<GitHub-Organization>/settings/installations
-
Identifier les accès de l’application GitHub. Cliquez sur le bouton de configuration ci-dessus et auditez les dépôts auxquels l’application Vercel avait accès. Cela vous indique sur quoi vous devez vous concentrer maintenant. Allez dans GitHub → Organisation → Paramètres → Applications GitHub → Vercel. Vérifiez :
- Accès aux dépôts (tous les dépôts vs. sélectionnés)
- Autorisations accordées
- Date d’installation et qui l’a installée
- Capturer le journal d’audit Vercel de votre équipe. Exportez-le ou capturez-le d’écran immédiatement. La fenêtre de conservation est limitée et l’interface utilisateur n’expose pas tout. Obtenez-le avant de commencer à faire des modifications qui pollueront le journal. Vous le trouverez à l’adresse https://vercel.com/activity-log
- Activer « Observability Plus ». Il s’agit d’une fonctionnalité payante supplémentaire de Vercel, et il est dommage que je doive vous suggérer de l’activer et de PAYER pour cela, mais dans ce cas, je pense que c’est la meilleure chose à faire pendant la réponse à incident. Je ne suis certainement pas content de cela, mais je l’ai activé simplement parce qu’il conserve les journaux d’audit plus longtemps que la valeur par défaut qui est très courte.
- Inventorier l’étendue de l’exposition. Pour chaque équipe/compte Vercel que vous contrôlez, listez :
- Projets et leurs dépôts Git liés
- Intégrations connectées (application GitHub, Linear, Slack, intégrations marketplace)
- Membres de l’équipe et leurs rôles
- Jetons d’accès personnel / jetons API émis sous l’équipe
- Crochets de déploiement
- Vérifier le journal d’audit de l’organisation GitHub. Recherchez la fenêtre d’exposition (de manière prudente, du 1er au 15 avril 2026 jusqu’à aujourd’hui). Filtrez pour :
repo.add_member, repo.add_topicorg.invite_member, org.add_memberintegration_installation, integration_installation.repositories_addedprotected_branch.destroy,
Ne faites pas encore d’annonces et ne tournez pas les secrets. Vous voulez d’abord la capture.
Phase 1 : Vérifier les indicateurs de compromission (IOC)
Les détails de l’annonce de Vercel sont assez légers :
Au mieux de ce que nous pouvons dire, ils suggèrent d’aller dans votre console d’administration Google Workspace et de rechercher cette application googleusercontent.com. Voici comment la trouver dans la console :
-
Dans la console d’administration de votre espace de travail, allez dans Sécurité > Accès et contrôle des données > Contrôles des API et trouvez les applications consultées et en attente.
-
Ensuite, recherchez dans les différentes listes l’IOC qui est apparemment une application OAuth : 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
-
Si vous la trouvez, retirez-la immédiatement et consultez un partenaire en réponse aux incidents. Cela dépasse mes compétences.
Phase 2 : Rotation des identifiants
La rotation est l’action la plus importante. Faites-la par ordre de priorité afin que, si vous êtes interrompu, les éléments les plus dangereux aient été traités.
Ce que vous devez tourner dépend de ce que vos environnements GitHub et Vercel ont exposé. Commencez par les PAT GitHub, etc., et élargissez à partir de là en utilisant ce guide.
Niveaux de priorité
Niveau 0 — À tourner aujourd’hui, avant tout le reste :
- Tournez immédiatement tous les PAT GitHub et tuez toutes les sessions existantes. Les jetons d’accès personnel, ou PAT. Il existe deux types de PAT :
- Tournez immédiatement toutes les variables d’environnement Vercel qui sont sensibles : http://vercel.com/all-env-vars
Niveau 1 — À tourner aujourd’hui, selon ce que vous avez exposé dans vos applications :
- Clés secrètes de processeur de paiement (Stripe, Adyen, Braintree, etc.)
- Secrets de signature d’authentification (NextAuth
AUTH_SECRET / NEXTAUTH_SECRET, clés de signature JWT, clés de cookie de session, jetons CSRF)
- Chaînes de connexion à la base de données avec accès en écriture (DATABASE_URL, URL directes Postgres/MySQL, URI Mongo, Redis avec authentification)
- Clés racines ou à large périmètre du fournisseur cloud (clés d’accès IAM AWS, JSON de compte de service GCP, secrets clients Azure)
- Secrets de signature de webhook (Stripe, GitHub, Slack — tournez et mettez à jour la configuration de l’expéditeur)
Niveau 2 — À tourner cette semaine :
- Clés API SaaS tierces (analytiques, fournisseurs de messagerie, SMS, CRM)
- Secrets clients OAuth pour les applications que vous possédez
- Identifiants SMTP
- Clés de chiffrement pour la cryptographie au niveau applicatif (tournez avec augmentation de version de clé, pas un remplacement direct)
- Clés de purge CDN, clés de service d’images
- Clés de fournisseur de feature flag
Niveau 3 — À tourner quand c’est pratique, mais tournez quand même :
- Jetons d’analyse en lecture seule
- DSN Sentry / logging (note : la rotation du DSN n’est pas critique si vous acceptez une petite fenêtre d’événements perdus)
- Clés publiques et clés anonymes (tournez quand même — elles peuvent révéler l’existence du projet et parfois permettre l’énumération)
Pièges dans l’ordre des opérations
- Les clés de signature de session invalident toutes les sessions actives lors de la rotation. Prévoyez un événement de déconnexion forcée. Communiquez-le.
- Les secrets de webhook doivent être tournés aux deux extrémités. Mettez à jour l’expéditeur en premier (Stripe, GitHub) pour envoyer avec le nouveau secret, puis votre récepteur pour vérifier avec celui-ci. Ou supportez les deux temporairement.
- Identifiants de base de données — créez d’abord le nouvel utilisateur, déployez, puis révoquez l’ancien. Ne remplacez pas directement ou vous provoquerez une interruption.
- Clés AWS — si vous tournez les clés d’accès d’un utilisateur IAM, créez la deuxième clé, déployez, puis supprimez la première. Ne faites pas de « désactiver » et espérez.
- Redéployez après les modifications de variables d’environnement. Les variables d’environnement Vercel sont intégrées au moment du build pour de nombreuses configurations de framework. Un changement de variable d’environnement sans nouveau déploiement n’est pas totalement appliqué.
- Vérifiez aussi vos secrets CI. Si un secret a été miroité vers GitHub Actions, CircleCI, ou similaire, tournez le miroir.
N’oubliez pas ces oublis courants
.env.local commitée dans un dépôt privé (toujours un problème — le code source a peut-être été exfiltré)- Secrets dans les environnements preview/développement Vercel, pas seulement la production
- Secrets stockés en tant que variables d’environnement partagées au niveau de l’équipe Vercel
- Crochets de déploiement (tournez-les ; ce sont des déclencheurs de déploiement complets)
- Jetons d’accès personnel Vercel émis sous votre compte
- Jetons d’accès personnel GitHub qui ont autorisé l’installation de l’application GitHub Vercel (séparés de l’application elle-même)
Phase 3 : Chasse au niveau des dépôts
Pour les dépôts qui étaient connectés à Vercel :
- Diff
main/master HEAD par rapport au tag/commit que vous savez être bon avant la fenêtre de l’incident.
- Recherchez des modifications dans :
package.json → scripts (en particulier postinstall, prepare, preinstall)package-lock.json / pnpm-lock.yaml / yarn.lock — ajouts inattendus de dépendances ou mises à jour de versions.github/workflows/*.yml — nouveaux workflows, nouvelles étapes run:, nouveaux uses: avec SHA non épinglésvercel.json — modifications de la commande de build, nouvelles réécritures/redirections qui pourraient exfiltrer du trafic
Si vous publiez des packages npm à partir de ces dépôts
C’est là qu’une compromission initiale de Vercel pourrait devenir un événement de chaîne d’approvisionnement. Même si vous n’utilisez pas Vercel pour publier, si un attaquant a obtenu votre jeton GitHub et que votre workflow de publication utilise ce jeton :
- Vérifiez l’historique de publication npm :
npm view <pkg> time --json pour des versions inattendues.
- Comparez l’archive tar de chaque version récente avec le tag git dont elle est censée provenir. Les attaquants publient à partir d’un tag qui ne correspond pas à ce qui est dans le registre.
- Auditez l’utilisation de
NPM_TOKEN dans les workflows — tournez le jeton, révisez qui y avait accès.
- Vérifiez si de nouveaux mainteneurs ont été ajoutés à vos packages :
npm owner ls <pkg>.
- Si vous maintenez quelque chose d’important, surveillez l’exécution de scripts post-install dans l’archive tar — décompressez-la et inspectez-la.
Si vous trouvez la preuve d’une publication non autorisée, signalez-la à la sécurité npm ([email protected]) et envisagez de la soumettre à OSV.dev. Dépréciez la mauvaise version ; ne la supprimez pas (la suppression est limitée dans le temps et casse les consommateurs en aval).
Note sur les packages appartenant à Vercel en particulier : La mise à jour du 20 avril de Vercel indique que Next.js, Turbopack et leurs projets open source ont été analysés et sont considérés comme sûrs. C’est l’affirmation de Vercel concernant leur chemin de publication — vous devez quand même auditer vos packages comme ci-dessus. Si vous consommez Next.js ou Turbopack, vous n’avez pas besoin de vous épingler à une version pré-incident par précaution sur la base des informations actuelles, mais surveillez le bulletin Vercel pour des changements dans cette posture.
Phase 4 : Examen de l’intégration Linear
Si votre équipe utilise l’intégration Vercel ↔ Linear :
- Examinez le journal d’audit Linear (Paramètres de l’espace de travail → Sécurité → Journal d’audit) pour la fenêtre d’exposition.
- Recherchez :
- Nouvelles clés API émises
- Nouvelles intégrations ajoutées
- Commentaires postés par des comptes de service
- Modifications des destinations de webhook
- Invitations de membres
- Vues/exportations des données de problème (l’intégration a un accès en lecture aux problèmes, qui contiennent souvent des noms de clients, des détails de bugs et parfois des identifiants collés dans les tickets)
- Préoccupation spécifique : les problèmes Linear contiennent fréquemment des identifiants collés issus du débogage des développeurs. Recherchez dans votre espace de travail Linear les motifs de fuite courants (
AKIA, sk_live_, ghp_, ghs_, npm_, eyJ, ----BEGIN). Tout ce qui est trouvé doit être tourné.
Phase 5 : Examen des journaux des systèmes en aval
La rotation des identifiants invalide la persistance de l’attaquant dans la plupart des cas, mais il a peut-être déjà utilisé l’accès. Vérifiez les consommateurs de vos secrets tournés pour des signes d’utilisation pendant la fenêtre d’exposition.
Fenêtres à vérifier
Utilisez 1er avril 2026 jusqu’à aujourd’hui comme limite inférieure prudente. L’incident a été divulgué le 19 avril mais l’accès initial est antérieur à la divulgation. Si Vercel publie une date plus spécifique, nous affinerons en conséquence.
Que rechercher
- AWS CloudTrail — appels API inhabituels à partir de clés IAM compromises, en particulier des rafales
GetObject contre des buckets S3, CreateUser, AttachUserPolicy, connexions à la console depuis de nouveaux ASN/pays.
- Journaux d’audit de base de données —
SELECT * inhabituels sur des tables sensibles, exportations volumineuses, connexions depuis des adresses IP sources inattendues.
- Journaux de paiement Stripe — création inhabituelle de clients, création de transferts, création de clés API.
- Journaux du fournisseur d’authentification (Auth0, Clerk, Cognito, Firebase) — connexions à distance impossible, réinitialisations de mot de passe déclenchées pour des utilisateurs administrateurs, nouvelles inscriptions d’application.
- Fournisseur de messagerie (SendGrid, Postmark, etc.) — campagnes sortantes inattendues, nouvelles clés API, modifications d’identité de l’expéditeur.
- GitHub — clones, créations de forks, nouvelles clés SSH sur les comptes utilisateur avec accès aux dépôts.
Primitives utiles pour la chasse aux IOC
Collez les noms d’hôtes ou adresses IP contrôlés par l’attaquant publiés par Vercel ou les partenaires IR dans :
- Journaux d’accès HTTP de votre frontend (les attaquants sondent parfois avant d’agir).
- Journaux DNS — résolution sortante de domaines inhabituels depuis vos serveurs.
- Journaux de flux proxy / VPC sortants.
À la date de publication, aucun IOC n’a été publié par Vercel. Surveillez le bulletin Vercel et les analyses des sociétés IR réputées pour les mises à jour.
Phase 6 : Détection de compromission persistante
La persistance d’un attaquant après une compromission au niveau de la plateforme prend généralement ces formes. Chassez activement pour chacune :1. Nouveaux membres de l'équipe ou collaborateurs sur votre équipe Vercel, organisation GitHub, espace de travail Linear, ou comptes cloud. Datés dans la fenêtre d'exposition.
2. Nouvelles autorisations OAuth sur les fournisseurs SSO connectés (Google Workspace, Okta, Entra ID) pour les comptes de vos développeurs.
3. Configuration CI/CD modifiée — workflows qui téléphonent maintenant à la maison, nouveaux runners auto-hébergés, nouveaux secrets avec des noms anodins.
4. Déploiements inattendus dans Vercel — vérifiez l'historique des déploiements pour les déploiements que vous ne pouvez pas associer à un commit connu d'un auteur connu.
5. Indicateurs de reverse shell dans les logs de fonctions serverless — blobs base64 écrits/exécutés, connexions sortantes inhabituelles depuis les fonctions Edge/Serverless.
6. Dérive DNS — nouveaux sous-domaines, modifications CNAME, redirections ajoutées via vercel.json ou la configuration du framework.
7. Modifications d'authentification — MFA désactivé, codes de récupération régénérés, mot de passe modifié sans action de l'utilisateur.
Communications
Interne
Désignez un commandant d'incident. Standup quotidien minimum pendant la rotation. Document unique de vérité pour « ce que nous avons fait pivoter, ce qui est en attente, ce que nous avons trouvé ». Sortez de Linear si Linear est dans le périmètre de l'incident — utilisez un canal secondaire.
Face aux clients
Consultez un conseiller juridique. Les seuils de notification varient, mais :
- RGPD : 72 heures pour les violations notifiables affectant les résidents de l'UE.
- Australie (régime des Notifiable Data Breaches, OAIC) : notifier dès que possible lorsque des dommages graves sont probables.
- États-Unis : état par état ; certains états ont des fenêtres de 30 à 60 jours, d'autres exigent une notification immédiate pour des classes de données spécifiques.
- Californie (CCPA) : des obligations spécifiques si les informations personnelles des résidents de Californie sont dans le périmètre.
- Clients SOC 2 / ISO 27001 : les clauses de notification contractuelles exigent souvent un préavis plus précoce que les minimums réglementaires. Lisez vos MSAs.
Si vous n'avez aucune preuve de sortie de données de vos systèmes, vous n'avez peut-être pas encore d'obligation de notification — mais « nous utilisons Vercel et Vercel a eu un incident » seul ne suffit généralement pas pour déclencher une notification, sauf si des données sensibles étaient matériellement à risque. Documentez votre raisonnement.
Déclarations préparées
Rédigez-les avant d'en avoir besoin :
- Réunion interne générale
- Avis destiné aux clients
- Modèle de notification pour les régulateurs
- Mise à jour de la page de statut (si publique)
Hygiène d'attribution publique
Ne répétez pas publiquement les affirmations de l'attaquant comme des faits. Liez-vous au bulletin de Vercel comme source principale. Laissez Vercel caractériser son propre incident — vous êtes dans votre couloir en caractérisant votre propre exposition.
Renforcement à moyen terme (post-incident)
Cet incident met en évidence des problèmes structurels qu'il vaut la peine de corriger, même si vous vous avérez être non affecté.
- Migrez tous les secrets vers la fonctionnalité de variables d'environnement sensibles de Vercel. Faites-en la valeur par défaut de l'équipe. Formez les développeurs à signaler dès la création.
- Adoptez des identifiants à courte durée de vie lorsque c'est possible. Utilisez la fédération GitHub OIDC vers AWS/GCP/Azure au lieu de clés d'accès à longue durée de vie reflétées dans les variables d'environnement Vercel. Utilisez des gestionnaires de secrets natifs du cloud (AWS Secrets Manager, GCP Secret Manager) accessibles au moment de l'exécution au lieu de variables d'environnement intégrées.
- Inventoriez les applications OAuth tierces connectées à votre Google Workspace, Microsoft 365, organisation GitHub et équipe Vercel. L'IAV de Vercel était Context.ai — une plateforme IA intégrée via OAuth dans le Google Workspace d'un employé. La même classe de risque existe dans chaque organisation qui a approuvé libéralement les intégrations SaaS et d'outils IA, et la barre pour « ce qui est approuvé » a considérablement baissé lors de la ruée vers les outils IA des 18 derniers mois. Actions concrètes :
- Extrayez votre rapport d'applications OAuth Google Workspace (Console d'administration → Sécurité → Contrôles API → Contrôle d'accès aux applications). Examinez chaque application avec des scopes sensibles (
gmail.readonly, calendar, drive, admin.directory).
- Faites de même pour Microsoft 365 (Entra ID → Applications d'entreprise).
- Instaurez une revue trimestrielle. Exigez une validation de sécurité pour les nouvelles autorisations OAuth qui portent des scopes sensibles.
- Envisagez de restreindre l'installation d'applications OAuth à une liste blanche plutôt qu'à une approbation pilotée par l'utilisateur.
- Principe du moindre privilège sur le périmètre de l'application GitHub. Si Vercel n'a pas besoin d'un accès à tous les dépôts de l'organisation, limitez aux dépôts qu'il déploie réellement.
- Rotation des hooks de déploiement en routine. Trimestrielle.
- Intégrez une analyse de secrets dans votre pré-commit et CI. Trufflehog, gitleaks, ou équivalent. Scannez rétroactivement l'historique du dépôt pour tout ce qui a pu être commité puis pivoté — supposez que ce qui a été commité une fois est toujours dans un clone quelque part.
Références
Journal des modifications
- 2026-04-20 (v2) — Mis à jour suite à la déclaration du PDG de Vercel, Guillermo Rauch, du 20 avril. Plusieurs éléments sont passés de « signalé » à « confirmé » : Context.ai nommé comme fournisseur en amont compromis, compte Google Workspace d'un employé de Vercel comme pivot, énumération des variables d'environnement non sensibles comme mouvement latéral dans la plateforme. Ajout d'une mise en parallèle pour l'exposition directe à Context.ai. Ajout de la déclaration de Vercel selon laquelle Next.js, Turbopack et les projets OSS restent sûrs. Ajout de l'engagement de Mandiant. Renforcement de la recommandation d'inventaire des applications OAuth.
- 2026-04-20 (v1) — Version initiale. Basée sur le bulletin de Vercel du 19 avril 2026 et les rapports publics contemporains. À mettre à jour au fur et à mesure que Vercel publie des détails supplémentaires, des IOCs, ou une fenêtre d'exposition plus étroite.
opensourcemalware/vercel-april2026-incident-response
