Violation chez Vercel : une attaque OAuth révèle les risques cachés des variables d’environnement de la plateforme

• Une compromission de la supply chain OAuth a conduit à un accès aux systèmes internes de Vercel et à une exposition de variables d’environnement sur un nombre limité de projets clients
• Le point de départ a été l’infection par Lumma Stealer d’un employé de Context.ai, et les jetons OAuth Google Workspace dérobés ont été utilisés pour accéder au compte d’un employé de Vercel ainsi qu’aux systèmes internes
• Les attaquants ont obtenu des autorisations leur permettant d’énumérer les variables d’environnement des projets clients, en particulier via des variables marquées comme non sensibles, augmentant le risque d’exposition d’identifiants de services en aval
• D’après les éléments rendus publics, dans au moins un cas, une clé API divulguée a été détectée avant la communication de Vercel, et l’écart entre détection et notification est apparu comme un facteur de risque majeur
• Cette compromission montre que les relations de confiance OAuth et la manière dont une plateforme stocke les variables d’environnement peuvent ensemble favoriser la propagation d’identifiants à l’échelle de toute la supply chain

---

Implications clés

• Confirmation de l’effet amplificateur d’OAuth
  • La compromission d’une seule relation de confiance OAuth s’est propagée en chaîne, du fournisseur jusqu’aux systèmes internes de Vercel
  • Même les variables d’environnement de projets clients n’ayant pas de lien direct avec le fournisseur compromis ont été exposées de façon limitée
• Possibilité d’opérations offensives accélérées par l’IA
  • Le CEO a publiquement associé la rapidité inhabituelle de l’attaquant à un renforcement par l’IA
  • Cette appréciation reste toutefois une déclaration publique, et non une conclusion officielle de l’analyse forensique
• Mise en lumière du délai entre détection et divulgation
  • Dans au moins un rapport public de client, des indices suggèrent la détection d’une clé divulguée 9 jours avant la communication de Vercel
  • Dans une compromission de plateforme, le délai entre détection et notification est désigné comme un facteur de risque important
• Lien avec une tendance plus large en 2026
  • Aux côtés de LiteLLM, Axios, Codecov et CircleCI, l’incident s’inscrit dans une dynamique de supply chain visant les identifiants stockés par les développeurs

Chronologie de l’incident

• Vers février 2026, un employé de Context.ai est infecté par Lumma Stealer, entraînant la fuite d’identifiants d’entreprise, de jetons de session et de jetons OAuth
• Vers mars 2026, les attaquants accèdent à l’environnement AWS de Context.ai et dérobent des jetons OAuth destinés aux utilisateurs grand public
  • Parmi eux figuraient des jetons Google Workspace d’un employé de Vercel
• En mars 2026, les jetons OAuth volés permettent d’accéder au compte Google Workspace d’un employé de Vercel
• De mars à avril 2026, après un déplacement vers les systèmes internes de Vercel, l’énumération des variables d’environnement des clients commence
• Vers avril 2026, des allégations émergent selon lesquelles un acteur lié à ShinyHunters aurait commencé à vendre des données Vercel
• Le 10 avril 2026, un client de Vercel mentionne publiquement avoir reçu d’OpenAI une alerte concernant une clé API divulguée
• Le 19 avril 2026, Vercel publie son avis de sécurité et un thread sur X
• Après le 19 avril 2026, notifications aux clients, consignes de rotation des identifiants et déploiement de modifications du tableau de bord se poursuivent
• Malgré une durée de présence relativement courte d’environ 2 mois, la vitesse de propagation entre l’infection chez un fournisseur tiers et la fuite de variables d’environnement clients est confirmée
• La durée de conservation par défaut des journaux d’audit OAuth de Google Workspace est de 6 mois sur de nombreuses offres
  • Cette présence d’environ 2 mois a donc des chances d’être encore visible dans la fenêtre de conservation
  • Il est également souligné que des compromissions similaires plus longues pourraient dépasser cette durée de conservation par défaut

Chaîne d’attaque

• Étape 1 : compromission OAuth chez un tiers

  • Context.ai disposait d’une application OAuth Google Workspace approuvée par un employé de Vercel
  • La compromission de cette application remonte à l’infection par Lumma Stealer d’un employé de Context.ai vers février 2026
  • Selon Hudson Rock et CyberScoop, cet employé aurait été infecté après avoir téléchargé un script d’exploit pour un jeu Roblox
  • Avec les identifiants volés, les attaquants ont accédé à l’environnement AWS de Context.ai et exfiltré des jetons OAuth d’utilisateurs grand public de Context AI Office Suite, lancé en juin 2025
  • Context.ai a indiqué avoir détecté et interrompu un accès non autorisé à son environnement AWS en mars 2026
  • Il est toutefois précisé que la fuite des jetons OAuth elle-même n’a pas été identifiée avant l’enquête de Vercel
  • Les applications OAuth approuvées présentent les caractéristiques suivantes
    • ne nécessitent pas le mot de passe de l’utilisateur
    • peuvent rester valides même après un changement de mot de passe
    • disposent fréquemment de larges périmètres d’autorisation sur les e-mails, Drive, Calendar, etc.
    • font rarement l’objet d’un audit après l’approbation initiale

• Étape 2 : compromission du compte Workspace

  • L’accès à l’application OAuth compromise a permis de pivoter vers le compte Google Workspace d’un employé de Vercel
  • Cela a rendu possible l’accès aux e-mails, aux documents internes sur Google Drive, à la visibilité sur le calendrier et les ressources associées, ainsi qu’à d’autres services reliés via OAuth

• Étape 3 : accès aux systèmes internes

  • Depuis le compte Workspace compromis, les attaquants ont progressé vers les systèmes internes de Vercel
  • Rauch a mentionné que l’escalade s’était produite au fil d’une série de manipulations amorcées depuis le compte Google Workspace Vercel compromis d’un collègue
  • Les techniques précises de mouvement latéral n’ont pas été divulguées
    • intégration SSO
    • identifiants collectés dans les e-mails ou sur Drive
    • autres outils internes reliés via OAuth
    • aucun de ces éléments n’a été confirmé publiquement

• Étape 4 : énumération des variables d’environnement

  • Les attaquants ont accédé aux systèmes internes de Vercel avec des droits suffisants pour énumérer les variables d’environnement des projets clients
  • Vercel permet de marquer les variables d’environnement clients comme « non-sensitive »
  • D’après les déclarations publiques, toutes les variables d’environnement clients n’étaient pas protégées de la même manière, et l’énumération des variables non marquées comme sensibles a permis d’obtenir des accès supplémentaires

• Étape 5 : possibilité d’abus sur les services en aval

  • Les variables d’environnement exposées contiennent généralement des identifiants de services en aval
  • Selon le rapport public d’Andrey Zagoruiko du 19 avril 2026, il a reçu le 10 avril une alerte d’OpenAI concernant une clé divulguée
  • Selon l’auteur du signalement, cette clé n’existait nulle part ailleurs que chez Vercel
  • Ces éléments suggèrent qu’au moins un identifiant exposé pourrait avoir été détecté à l’extérieur avant la communication de Vercel

Un écart de 9 jours au moment de la divulgation

• Dans une réponse de Guillermo Rauch sur X le 19 avril, le client Andrey Zagoruiko a publiquement indiqué avoir reçu le 10 avril 2026 une alerte d’OpenAI sur une clé divulguée
• La détection par OpenAI d’identifiants divulgués s’active généralement lorsqu’ils sont trouvés dans des emplacements publics, comme GitHub ou des sites de paste
• L’article juge non trivial le chemin menant des variables d’environnement Vercel à une alerte OpenAI
• Sur le plan des dates, il existe une fenêtre de 9 jours entre la première preuve publique d’exposition et la communication de Vercel

• Ce que signifie et ne signifie pas cet écart de 9 jours

  • Il s’agit d’un unique signalement public et non d’un résultat forensique confirmé
  • Il ne faut pas l’interpréter comme une preuve que Vercel avait déjà connaissance de la compromission le 10 avril
  • En revanche, cela indique qu’au moins un identifiant a pu être détecté à l’extérieur avant que les clients ne soient invités à remplacer leurs secrets

• Enseignements pour les parties prenantes

  • Régulateurs
    • En vertu du RGPD, le délai de notification de 72 heures commence à partir du moment où le responsable du traitement a connaissance de la violation
    • La question de savoir quand Vercel a eu connaissance de l’incident émerge comme un point public majeur
  • Auditeurs
    • Les évaluateurs SOC 2 et ISO 27001 peuvent examiner le délai entre détection et notification comme preuve du niveau de surveillance continue
  • Clients
    • On ne peut pas supposer que la fenêtre d’exposition a commencé le 19 avril
    • L’article avance qu’une exploitation active a pu commencer avant cette date
  • Les alertes sur identifiants divulgués envoyées par les fournisseurs gagnent en importance comme canal d’alerte précoce
  • Exemples cités : OpenAI, Anthropic, GitHub, AWS et Stripe

Activité d’attaque accélérée par l’IA

• Guillermo Rauch a déclaré sur X, le 19 avril 2026, qu’il soupçonnait fortement que le groupe attaquant était hautement sophistiqué et considérablement accéléré par l’IA
• L’article traite cette déclaration comme une évaluation figurant au dossier public du CEO de la plateforme touchée et mentionne la nécessité d’un examen prudent

• Indices que l’on pourrait attendre de preuves forensiques

  • Vitesse d’énumération au-delà du rythme humain
    • Peut s’expliquer en partie par du scripting seul
    • Une reconnaissance basée sur des LLM peut paralléliser l’exploration de schéma, le sondage des endpoints et la reconnaissance des formats d’identifiants
  • Construction de requêtes contextuelle
    • Des requêtes qui semblent connaître la terminologie propre à Vercel, les slugs de projet, les noms de cibles de déploiement et les conventions de nommage des env vars, même sans reconnaissance préalable évidente
  • Adaptabilité dans la réponse aux erreurs
    • Changement de stratégie après des erreurs API et des rate limits, avec plus de souplesse qu’un script statique
  • Produits de social engineering à l’apparence localisée
    • Des accroches de phishing, messages de commit et tickets de support d’une qualité plus proche du contexte local que d’une simple traduction ou d’un template

• Une importance qui dépasse l’incident Vercel

  • Que cette évaluation soit ou non confirmée par la forensique formelle, la catégorie des opérations d’attaque augmentées par l’IA ne relève plus de la pure spéculation
  • Dans sa publication d’avril 2026, Microsoft a documenté des cas de device-code phishing piloté par IA, de génération de code dynamique, de leurres hyperpersonnalisés et d’orchestration automatisée côté backend
  • Il est souligné que des baselines de télémétrie calibrées sur des vitesses humaines peuvent produire des false negatives face à des opérateurs accélérés par l’IA

• Implications pour l’ingénierie de détection

  • Si l’énumération et la compression du déplacement latéral se produisent, les règles existantes basées sur le temps de présence et les seuils de vitesse peuvent sous-alerter
  • Cela amène à réexaminer les points suivants
    • vitesse d’énumération des ressources uniques par session
    • courbe de récupération du succès par rapport aux erreurs
    • diversité des patterns de requêtes sur une courte période

Vulnérabilité clé dans la conception des variables d’environnement

• L’aspect le plus critique de l’article n’est pas tant le vecteur d’accès initial lui-même que le modèle de sensibilité des variables d’environnement de Vercel

• Fonctionnement des variables d’environnement Vercel à l’époque

  • Les projets injectent des variables d’environnement dans les fonctions serverless et le processus de build
  • Il existe un flag sensitive par variable
  • La valeur par défaut est non-sensitive
  • sensitive doit être activé explicitement
  • Les variables non-sensitive s’affichent dans le tableau de bord
  • Les variables sensitive sont masquées après leur création
  • L’accès via l’API interne est possible pour les non-sensitive, tandis qu’il est restreint pour les sensitive
  • D’après les déclarations publiques internes, le stockage chiffré ne s’appliquait pas aux non-sensitive, mais s’appliquait aux sensitive avec des restrictions supplémentaires
  • Dans cette compromission, les éléments accessibles à l’attaquant étaient marqués non-sensitive

• Choix de conception déterminant

  • Le flag sensitive est désactivé par défaut
  • Tout DATABASE_URL, API_KEY, STRIPE_SECRET_KEY ou AWS_SECRET_ACCESS_KEY que le développeur n’a pas explicitement activé est stocké sous une forme non chiffrée dans le modèle d’accès interne de Vercel
  • Un contrôle de sécurité qui exige un opt-in explicite pour chaque secret individuel et qui ne fournit ni protection par défaut ni garde-fous est jugé avoir un faible taux d’adoption réel

• Réponse de Vercel

  • Il a été confirmé que des améliorations ont été déployées sur la page de vue d’ensemble des variables d’environnement ainsi que sur l’UI de création et de gestion des variables sensibles
  • Il y a eu des améliorations sur le plan de la visibilité, mais au moment de la rédaction, la valeur par défaut n’a pas changé
  • Un opt-in reste nécessaire pour chaque variable
  • La question d’un basculement du paramétrage par défaut reste ouverte publiquement

• Comparaison sectorielle

  • Le secteur se tourne vers des coffres-forts à secrets dédiés comme Vault, AWS Secrets Manager, Doppler et Infisical
  • L’incident est présenté comme un argument en faveur du choix d’une architecture de gestion des secrets dédiée plutôt que de l’approche fondée sur les variables d’environnement de Vercel
  • D’après le tableau comparatif
    • Vercel a une valeur par défaut non-sensitive, sans détection automatique
    • AWS SSM Parameter Store prend en charge SecureString
    • HashiCorp Vault fournit le chiffrement de tous les secrets et des ACL
    • GitHub Actions masque dans les logs tous les secrets
    • Netlify utilise une approche par variables d’environnement avec un toggle secret

Fan-out des identifiants et risque aval

• Le credential fan-out désigne le phénomène par lequel la compromission d’une plateforme entraîne une exposition en chaîne à tous les services aval authentifiés avec les identifiants stockés sur cette plateforme
• Éléments souvent présents dans les variables d’environnement de projets Vercel et leurs impacts aval
  • Base de données
    • DATABASE_URL, POSTGRES_PASSWORD
    • Possibilité d’accès complet aux données
  • Cloud
    • AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY
    • Possibilité de compromission du compte cloud
  • Paiement
    • STRIPE_SECRET_KEY, STRIPE_WEBHOOK_SECRET
    • Risques sur les données financières et de fraude au remboursement
  • Authentification
    • AUTH0_SECRET, NEXTAUTH_SECRET
    • Possibilité de falsification de session et de prise de contrôle de compte
  • Envoi d’e-mails
    • SENDGRID_API_KEY, POSTMARK_TOKEN
    • Possibilité de phishing via des domaines de confiance
  • Monitoring
    • DATADOG_API_KEY, SENTRY_DSN
    • Possibilité de manipulation de la télémétrie
  • Code source et packages
    • GITHUB_TOKEN, NPM_TOKEN
    • Possibilité d’injection dans la supply chain
  • IA/ML
    • OPENAI_API_KEY, ANTHROPIC_API_KEY
    • Possibilité d’abus d’API et de génération de coûts
• Un projet Vercel unique contient généralement 10 à 30 variables d’environnement
• À l’échelle d’une organisation, un portefeuille de 50 projets peut représenter 500 à 1 500 identifiants présents sur la plateforme
• Bien qu’il soit indiqué que seuls certains projets clients limités ont été consultés dans cet incident, chaque identifiant exposé peut devenir un point de pivot vers un système distinct
• L’article qualifie ce point non pas comme un simple incident de confidentialité de plateforme, mais comme un effet multiplicateur qui se propage à l’ensemble de la supply chain logicielle

Relations de confiance OAuth et contournement des défenses périmétriques

• Une intrusion fondée sur OAuth contourne de nombreux contrôles conçus pour détecter et bloquer les attaques traditionnelles basées sur des identifiants
• L’article contient une mention d’environ 22 mois, mais la correction en tête indique que la durée de présence a été révisée à environ 2 mois
• Il est expliqué que les contrôles défensifs sur lesquels les équipes sécurité s’appuient dans la colonne de gauche deviennent sans effet, ou sont déjà satisfaits, dans un scénario de compromission via une app OAuth
• Cette asymétrie fait de la gouvernance OAuth un domaine de sécurité distinct de l’IAM

• La gouvernance OAuth comme fonction de risque fournisseur

  • De nombreuses organisations traitent l’approbation OAuth comme une question de self-service développeur
  • Elles se limitent à l’approbation des outils nécessaires par employé, avec un minimum de revue centralisée
  • Cet incident est présenté comme un argument pour traiter les apps OAuth approuvées comme des fournisseurs tiers disposant d’un accès persistant
  • Une revue fournisseur, une réapprobation périodique et une surveillance des usages anormaux sont nécessaires

Affirmations de l’acteur malveillant et attribution

• Les affirmations d’acteurs malveillants sur des forums clandestins sont, par nature, difficiles à considérer comme fiables.
• Les informations ci-dessous sont présentées non comme des faits confirmés, mais à des fins de perception et de suivi.

• Affirmation d’un lien avec ShinyHunters

  • Un auteur de message sur BreachForums affirme un lien avec ShinyHunters et prétend détenir des données de Vercel.
  • Éléments de données revendiqués
    • Environ 580 dossiers d’employés
    • Dépôts de code source
    • Clés API et tokens internes
    • Tokens GitHub et NPM
    • Communications internes
    • Accès à un workspace Linear
  • Les volumes et la portée ci-dessus sont tous non vérifiés.

• Éléments qui compliquent l’attribution

  • Des membres connus de ShinyHunters ont nié toute implication auprès de BleepingComputer.
  • Il existe des affirmations selon lesquelles une demande de rançon de 2 millions de dollars a été formulée via Telegram.
  • La marque ShinyHunters est utilisée, depuis la campagne d’origine, par plusieurs acteurs ou par des acteurs non liés.
  • L’avis de sécurité de Vercel ne mentionne pas ces affirmations publiées sur le forum.
  • Le fil de Rauch traite de la chaîne d’attaque, mais n’aborde pas directement le message du forum.

• Position de Vercel sur la chaîne de release de la supply chain

  • Rauch indique avoir analysé la supply chain de Next.js, Turbopack et de plusieurs projets open source, et affirme qu’ils sont sûrs pour la communauté.
  • Au moment de la rédaction, une vérification indépendante est toujours en cours.
  • Il est recommandé aux organisations utilisant Next.js, Turbopack et d’autres projets open source de Vercel de continuer à vérifier les signaux d’intégrité des packages, comme les checksums, les signatures et les provenance attestations.
  • En l’absence de vérification indépendante des données revendiquées sur le forum, celles-ci doivent être traitées comme des informations non confirmées.
  • Même avec la seule chaîne d’attaque OAuth décrite par Vercel, l’incident est techniquement cohérent, sans qu’il soit nécessaire de supposer la vaste portée d’accès affirmée par l’auteur du message sur le forum.

Cartographie MITRE ATT&CK

• La chaîne d’attaque confirmée se mappe naturellement sur des techniques MITRE ATT&CK existantes.
• Éléments de mapping
  • Initial Access / Trusted Relationship / T1199
    • L’application OAuth de Context.ai a été exploitée comme tiers de confiance.
  • Persistence / Application Access Token / T1550.001
    • Les tokens OAuth persistent même après un changement de mot de passe.
  • Credential Access / Valid Accounts / T1078
    • Identifiants Workspace d’employés compromis
  • Discovery / Account Discovery / T1087
    • Énumération des systèmes internes et des projets
  • Credential Access / Unsecured Credentials: Credentials in Files / T1552.001
    • Accès possible à des variables d’environnement non sensibles
  • Lateral Movement / Valid Accounts: Cloud Accounts / T1078.004
    • Possibilité d’utiliser des identifiants cloud exposés
  • Collection / Data from Information Repositories / T1213
    • Énumération des variables d’environnement à l’échelle des projets
• Dans cette cartographie, le point de détection le plus précieux est le passage d’un accès à une application OAuth vers un accès à des systèmes internes.
• Les organisations doivent surveiller les comportements anormaux des applications OAuth qui accèdent à des ressources hors de leur périmètre attendu ou depuis des plages d’IP inhabituelles.

Guerre d’encerclement de la supply chain : LiteLLM, Axios, Vercel

• L’incident Vercel n’est pas isolé : il s’inscrit dans une série d’attaques supply chain concentrées entre mars et avril 2026.
• L’article indique qu’il pourrait s’agir d’une campagne coordonnée, ou, plus probablement, du résultat de plusieurs attaquants ayant découvert en même temps les mêmes faiblesses structurelles : les frontières de confiance entre registres de packages, CI/CD, fournisseurs OAuth et plateformes de déploiement.

• 24 mars 2026 : compromission supply chain de LiteLLM sur PyPI

  • Publication des packages PyPI malveillants litellm 1.82.7 et 1.82.8
  • Utilisation d’identifiants de déploiement CI/CD volés depuis Trivy, le scanner de vulnérabilités d’Aqua Security
  • LiteLLM est un proxy LLM totalisant environ 3,4 millions de téléchargements par jour.
  • La backdoor en trois étapes ciblait plus de 50 types d’identifiants chez les principaux fournisseurs cloud.
  • Persistance via Kubernetes DaemonSet incluse
  • Temps de présence avant détection et suppression : environ 40 minutes à 3 heures
  • Le CVE associé est CVE-2026-33634.

• 31 mars 2026 : compromission supply chain d’Axios sur npm

  • Le package npm axios compte entre 70 et 100 millions de téléchargements par semaine.
  • Diffusion des versions malveillantes 1.14.1 et 0.30.4 après compromission d’un compte de mainteneur
  • Injection de la dépendance plain-crypto-js@4.2.1, incluant un RAT multiplateforme
  • 135 endpoints infectés ont été détectés en communication avec le C2 de l’attaquant.
  • Temps de présence : 2 à 3 heures
  • Microsoft attribue cette attaque à l’acteur malveillant soutenu par la Corée du Nord Sapphire Sleet.

• Schéma convergent

  • Trois attaques en trois semaines
  • Des vecteurs différents
  • Une cible commune : les identifiants et secrets stockés par les développeurs dans leur toolchain
  • Le résumé en tableau présente les éléments suivants
    • LiteLLM : vol d’identifiants CI/CD → PyPI, identifiants développeur et clés API, 40 minutes à 3 heures
    • Axios : compromission d’un compte de mainteneur → npm, RAT sur poste de travail développeur, 2 à 3 heures
    • Vercel : compromission d’une application OAuth → plateforme, variables d’environnement client, environ 22 mois dans le tableau, mais corrigé à environ 2 mois dans l’erratum de tête et dans le corps du texte

Schémas communs avec de précédentes compromissions de plateformes

• La compromission de Vercel s’inscrit dans un schéma récurrent où une compromission au niveau de la plateforme expose des secrets clients.

• Compromission de Codecov Bash Uploader, janvier à avril 2021

  • L’attaquant a modifié le script Bash Uploader pour exfiltrer les variables d’environnement des environnements CI des clients.
  • L’attaque est restée non détectée pendant environ 2 mois.
  • Plus de 29 000 clients potentiellement affectés, dont Twitch, HashiCorp et Confluent
  • Point commun avec Vercel : exposition des variables d’environnement client via une compromission de plateforme

• Incident de sécurité CircleCI, janvier 2023

  • Vol de tokens de session SSO d’employés via un malware sur un appareil personnel
  • Après accès aux systèmes internes, exfiltration de secrets clients et de clés de chiffrement
  • CircleCI a recommandé à tous ses clients de faire tourner tous les secrets stockés sur la plateforme.
  • Structure presque identique à celle de Vercel
    • Compromission d’un compte employé
    • Accès à des systèmes internes
    • Exfiltration de secrets clients

• Attaque contre les identifiants clients Snowflake, mai-juin 2024

  • UNC5537 a utilisé des identifiants obtenus via un infostealer et des comptes sans MFA.
  • Plus de 165 organisations affectées
  • Dont Ticketmaster, Santander Bank et AT&T

• Compromission du système de support Okta, octobre 2023

  • Accès au système de gestion des tickets de support client à l’aide d’identifiants volés
  • Consultation de tokens de session présents dans des fichiers HAR
  • Clients affectés, dont Cloudflare, 1Password et BeyondTrust

• Résumé du schéma

  • Accès initial via une relation de confiance ou des identifiants
  • Mouvement latéral vers des systèmes internes
  • Exfiltration de secrets clients
  • Le périmètre visé varie, de certaines cibles à l’ensemble de la plateforme.
  • Le tableau récapitule, pour chaque incident, le vecteur initial, les actifs exposés et le délai de détection.
    • Codecov : environ 2 mois
    • Okta : plusieurs semaines
    • CircleCI : plusieurs semaines
    • Snowflake : plusieurs mois
    • Vercel : environ 2 mois

Ce qui n’a pas encore été rendu public

• Malgré l’abondance de reportings publics et de déclarations de dirigeants, des zones d’ombre essentielles demeurent.
• Questions non résolues dans les archives publiques
  • Le moment où Vercel a détecté pour la première fois une activité anormale
  • La raison du décalage de 9 jours entre les premières preuves publiques d’exploitation d’identifiants et la communication publique
  • Le nombre de clients affectés
    • Rauch a parlé d’un impact « quite limited », sans donner de chiffre précis.
  • La question de savoir si les affirmations sur le forum ShinyHunters proviennent du même attaquant
  • Le statut actuel de Context.ai et l’éventuelle notification des clients en aval
  • L’étendue complète de l’accès interne chez Vercel
    • Le nombre d’équipes, de projets et de variables d’environnement affectés n’a pas été communiqué.
    • Il n’est pas confirmé non plus si d’autres systèmes internes, au-delà des variables d’environnement client, ont été consultés.
• L’article souligne que, pour une analyse rigoureuse, il est nécessaire non seulement de s’en tenir aux faits connus, mais aussi de reconnaître explicitement ce qui n’a pas été rendu public.

Guide de détection et de chasse

• Mesures immédiates pour les clients Vercel

  • Audit nécessaire de toutes les variables d’environnement des projets
  • L’article inclut les exemples CLI suivants
    • vercel env ls --environment production
    • vercel env ls --environment preview
    • vercel env ls --environment development
  • La CLI n’expose pas directement le flag sensitive à l’heure actuelle ; vérification nécessaire via le dashboard ou l’API

• Recherche d’utilisation non autorisée des identifiants exposés

  • Recherche dans les journaux d’audit des fournisseurs cloud
    • AWS CloudTrail
      • Filtre eventSource incluant sts.amazonaws.com, iam.amazonaws.com, s3.amazonaws.com
      • Recherche de userIdentity.accessKeyId correspondant à la clé d’accès Vercel stockée puis rotée
      • Détection de sourceIPAddress hors des CIDR connus de l’organisation, de python-requests, curl, Go-http-client et de chaînes d’automatisation userAgent non familières
      • Période : de février 2026 à aujourd’hui
    • GCP Audit Logs
      • Recherche de protoPayload.authenticationInfo.principalEmail du compte de service utilisant une clé stockée dans Vercel
      • callerIp hors des plages connues
      • Vérification de méthodes comme storage.objects.get, compute.instances.list, iam.serviceAccountKeys.create
    • Azure Activity Logs
      • Filtrage sur l’ID d’application ou le principal de service présent dans les variables d’environnement Vercel
      • callerIpAddress hors du périmètre attendu
      • Vérifier en priorité Microsoft.Storage/storageAccounts/listKeys, Microsoft.Compute/virtualMachines/write, Microsoft.Authorization/roleAssignments/write
  • Recherche dans les journaux d’accès aux bases de données
    • Toutes les bases dont la chaîne de connexion figurait dans les variables d’environnement Vercel
    • Analyse de toute la fenêtre de février à avril 2026
    • Vérification des IP hors des plages d’egress connues, comme les IP edge Vercel, le VPN, les bureaux
    • Détection des connexions utilisant des identifiants exposés en dehors des fenêtres normales de déploiement
    • Pour PostgreSQL : pg_stat_activity, log_connections
    • Pour MySQL : general log ou plugin d’audit
    • Pour MongoDB Atlas : événements DATA_EXPLORER, CONNECT du Project Activity Feed
  • Recherche dans les journaux des processeurs de paiement
    • Stripe Dashboard → Developers → Logs
    • source_ip en dehors des serveurs attendus
    • /v1/charges, /v1/transfers, /v1/payouts, /v1/customers
    • Vérifier les journaux équivalents chez Braintree et Adyen
    • Priorité aux clés API stockées dans des variables d’environnement non sensibles qui n’ont pas encore été rotées
    • Vérifier aussi les envois inattendus dans les journaux des services d’envoi d’e-mails
  • Vérifier les alertes de fuite involontaire d’identifiants émises par OpenAI, Anthropic, GitHub, AWS, Stripe, etc.

• Rotation et redéploiement doivent être effectués ensemble

  • D’après la documentation Vercel, la rotation des variables d’environnement seule n’invalide pas les anciennes valeurs d’identifiants des déploiements passés
  • Les anciens déploiements continuent d’utiliser les anciens identifiants jusqu’au redéploiement
  • Chaque rotation nécessite donc le redéploiement de tous les environnements utilisant ces variables, ou la désactivation explicite des anciens déploiements
  • Priorités dans l’ordre suivant
    • Identifiants des fournisseurs cloud
    • Chaînes de connexion aux bases de données
    • Clés des processeurs de paiement
    • Secrets d’authentification
    • Clés d’API tierces
    • Tokens de monitoring et de logging

• Préparation proactive pour les équipes sécurité

  • Examiner toutes les applications OAuth approuvées dans Google Workspace Admin Console → Security → API Controls → Third-party app access
  • Identifier les applications avec des scopes étendus sur Drive, Gmail, Calendar, etc.
  • Enquêter sur les applications de fournisseurs sans relation commerciale active
  • Surveiller l’utilisation de tokens OAuth depuis des plages IP inattendues
  • Recherche nécessaire du Client ID OAuth malveillant connu
    • 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com

Logique de détection SIEM

• Signaux anormaux d’applications OAuth, étapes 1 à 2

  • Alerte immédiate sur les événements d’autorisation ou de refresh de token liés au Client ID OAuth malveillant connu
  • Croiser les événements d’octroi de scopes étendus — accès complet aux e-mails, lecture/écriture Drive, accès au calendrier — avec la liste actuelle des fournisseurs
  • Les applications qui ne servent plus à l’activité doivent être révoquées
  • Une enquête est nécessaire si l’utilisation de tokens par des applications OAuth approuvées provient d’IP hors des plages CIDR attendues de l’entreprise et des fournisseurs

• Accès aux systèmes internes et mouvement latéral, étape 3

  • Événements d’authentification SSO/SAML anormaux
    • Lorsqu’un compte Workspace compromis se connecte à des applications internes depuis une IP, une région ou une empreinte d’appareil jamais vues
  • Collecte d’identifiants via e-mail et Drive
    • Recherche massive de mots-clés comme API key, secret, token, password, .env
    • Accès aux dépôts partagés d’identifiants, runbooks d’ingénierie et documentation d’infrastructure
    • Création de règles de transfert d’e-mails
  • Accès aux outils internes via des connexions OAuth
    • Création de sessions ou activité API à des horaires inhabituels ou depuis une infrastructure inhabituelle sur Slack, Jira, GitHub, des dashboards internes, etc.
  • Tentatives d’élévation de privilèges
    • Ajout à de nouveaux groupes ou rôles
    • Accès à des consoles d’administration inutilisées
    • Surveiller les appels à la Directory API de Google Workspace, les changements de délégation et les tentatives d’énumération des tokens OAuth d’autres utilisateurs

• Énumération des variables d’environnement, étape 4

  • Détecter dans les journaux d’audit d’équipe Vercel les schémas anormaux de volume et de fréquence des appels de type lecture, listing ou déchiffrement d’environnements
  • Établir d’abord une baseline sur les horaires normaux des builds CI/CD
  • Déclencher ensuite des alertes pour les accès dont le volume, le timing ou le principal source s’écartent de cette baseline
  • Porter une attention particulière aux accès depuis des comptes utilisateurs plutôt que des comptes de service, et aux accès de comptes qui n’interagissaient pas habituellement avec ces projets

• Abus d’identifiants en aval, étape 5

  • Examiner les journaux de tous les services cibles correspondant à des identifiants stockés comme variables d’environnement Vercel non sensibles pendant la fenêtre de février à avril 2026
  • Pour AWS, rechercher dans CloudTrail par access key ID spécifique
  • Pour GCP et Azure, rechercher dans les journaux d’audit par compte de service ou ID d’application
  • Pour les API SaaS comme Stripe, OpenAI, Anthropic, SendGrid, Twilio, vérifier dans les dashboards ou journaux API l’usage depuis des IP inconnues ou à des horaires inactifs
  • Toute utilisation qui ne peut pas être attribuée à votre propre infrastructure doit être considérée immédiatement comme un identifiant compromis, avec rotation et enquête sur les actions menées

• Alertes de fuite d’identifiants tiers

  • Il faut surveiller les alertes automatiques de scan de secrets, comme GitHub secret scanning partner program, AWS compromised key detection, OpenAI, Anthropic, Stripe, Google Cloud, etc.
  • Une alerte concernant une clé qui n’existait que sur la plateforme de déploiement doit être traitée non comme un simple avertissement d’hygiène, mais comme un indicateur de compromission de la plateforme

Procédure manuelle de threat hunting

• Recherche manuelle dans la Google Workspace Admin Console

  • Admin Console → Reports → Audit and Investigation → OAuth Log Events
  • Application Name = Context.ai ou Client ID = 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
  • Période : de février 2026 à aujourd’hui
  • Si des résultats apparaissent, il faut immédiatement révoquer les autorisations et lancer une enquête sur l’incident

• Vérification des applications OAuth tierces avec des scopes étendus

  • Admin Console → Security → API Controls → Third-party app access → Manage Google Services
  • Trier les applications dont App access est Unrestricted
  • Points à vérifier pour chaque application
    • Existence d’une relation active avec le fournisseur
    • Justification métier des scopes
    • Date de dernière utilisation
  • Les applications inutilisées depuis plus de 90 jours doivent être révoquées

Recommandations de défense

• Mesures immédiates, 0 à 48 heures

  • Faire tourner toutes les variables d’environnement Vercel non marquées comme sensitive
  • Redéployer tous les environnements après rotation
  • Activer le flag sensitive sur toutes les variables d’environnement contenant des identifiants, tokens, clés ou secrets
  • Auditer les validations d’applications OAuth dans la console d’administration Google Workspace ou Microsoft Entra
  • Révoquer l’accès des applications qui ne sont plus activement utilisées
  • Examiner les journaux d’accès de tous les services ayant utilisé des identifiants stockés dans les variables d’environnement Vercel entre février 2026 et aujourd’hui

• Renforcement à court terme, 1 à 4 semaines

  • Migrer vers des gestionnaires de secrets dédiés comme HashiCorp Vault, AWS Secrets Manager, Doppler ou Infisical
  • Utiliser l’injection à l’exécution au lieu du stockage dans les variables d’environnement de la plateforme
  • Là où c’est pris en charge, éliminer les identifiants de longue durée au profit d’une authentification basée sur OIDC
  • Mettre en place une surveillance des applications OAuth
    • Nudge Security, Grip Security, Valence Security ou les fonctions d’administration natives de Google Workspace
  • Mettre en place l’automatisation de la rotation des identifiants
    • Cycle recommandé de 30 à 90 jours
  • Inclure les validations OAuth dans un inventaire des risques tiers au même titre que les fournisseurs sous contrat

• Changements structurels, 1 à 6 mois

  • Adopter une posture Zero Trust pour les variables d’environnement
    • Partir du principe que tout secret stocké sur une plateforme de déploiement peut être exposé en cas de compromission de la plateforme
  • Appliquer le principe du moindre privilège
    • Comptes de base de données au minimum de privilèges
    • Limitation du périmètre d’action des clés API
    • Pour les identifiants cloud, utiliser des identifiants temporaires basés sur des rôles plutôt que des access keys de longue durée
  • Effectuer un examen de sécurité tiers et une réévaluation périodique pour toutes les applications OAuth et intégrations accédant au système d’identité de l’entreprise
  • Inclure les plateformes PaaS dans l’inventaire SBOM/ASPM
    • Elles ne doivent pas être traitées comme de simples services externes, mais comme des dépendances critiques de la supply chain

• Surveillance recommandée

  • Auditer le Client ID OAuth ci-dessus dans la Google Workspace Admin Console
  • Surveiller les appels API env.read et env.list inattendus dans les journaux d’audit Vercel
  • Vérifier dans CloudTrail, GCP Audit Logs et Azure Activity Logs toute utilisation depuis une IP ou un user agent inattendu d’identifiants stockés dans les variables d’environnement Vercel entre février et avril 2026
  • Si l’arbre de dépendances contient LiteLLM ou Axios, surveiller également les IoC mentionnés dans chaque avis
  • Surveiller les alertes des principaux fournisseurs d’API concernant des identifiants involontairement exposés pendant la période d’exposition

Impact réglementaire et conformité

• Les organisations susceptibles d’avoir subi une exposition d’identifiants à cause de cette compromission doivent évaluer les obligations suivantes

• GDPR

  • Si les identifiants exposés permettaient d’accéder à des systèmes contenant des données personnelles de l’UE, le délai de notification de 72 heures peut commencer au moment de la confirmation de l’exposition
  • La notification d’OpenAI du 10 avril soulève la question de savoir si, pour certaines organisations, la date de connaissance pourrait être antérieure à la divulgation publique du 19 avril

• CCPA/CPRA

  • L’exposition d’identifiants donnant accès à des données de consommateurs peut déclencher des obligations de notification

• PCI DSS

  • L’exposition d’identifiants de traitement des paiements, comme Stripe, Braintree ou Adyen, peut entraîner des exigences de réponse à incident et d’enquête forensique

• SOC 2

  • La documentation de l’incident, les mesures de rotation des identifiants et les contrôles mis à jour doivent être reflétés dans les preuves de surveillance continue

• SEC Cybersecurity Rules 8-K

  • Les sociétés cotées qui jugent l’incident matériel ont une obligation de divulgation sous 4 jours ouvrés
  • L’article souligne que, même si l’on ignore encore si les accès non autorisés ont réellement été utilisés, de nombreux cadres réglementaires peuvent se baser sur l’exposition elle-même plutôt que sur la confirmation d’un abus

Indicateurs de compromission

• IoC confirmés

  • OAuth Client ID
    • 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
    • Valeur liée à l’application OAuth Context.ai compromise

[GN⁺]

Réactions sur Hacker News

• Cela me rappelle qu’au moment où Vercel a lancé pour la première fois l’interface des variables d’environnement, l’option sensitive n’existait même pas. Il a fallu presque plus de deux ans pour que cette fonctionnalité arrive. Les échanges correspondants figurent dans la discussion GitHub et dans le changelog Vercel

  • Même si on ajoute le flag sensitive dans l’UI, cela ne change rien au runtime. Dès que c’est injecté dans process.env au moment du build, n’importe quelle dépendance qui cherche à fouiller peut le lire. Le vrai problème, à mon avis, c’est l’architecture qui entasse tous les secrets dans une seule poche d’env puis les transmet en bloc aux outils de build. Cloudflare, avec ses scoped bindings, ou Fly, les séparent déjà, et d’autres plateformes me semblent en retard sur ce point
  • sensitive ne veut pas dire illisible, seulement masqué dans l’UI. Il suffit de retourner un peu trop de props depuis une action ou une route pour que ça fuite facilement. Pour se protéger de ce genre de problème, il faut au final chiffrer les valeurs d’environnement avec sa propre clé, et comme les moyens de séparation sont limités, une autre parade possible est de baked-in certains secrets dans le code. L’attaquant ne doit alors pas seulement lire les valeurs d’environnement, mais aussi télécharger l’artefact de build et retrouver la clé de déchiffrement, ce qui relève un peu la barre. Ce n’est pas idéal, mais comme mesure temporaire, ça peut fonctionner

• Le fait de s’être fait avoir de cette manière donne vraiment l’impression d’un incident embarrassant. D’après la citation, il est particulièrement gênant que l’infection par Lumma Stealer ait commencé avec le téléchargement d’un script d’exploit Roblox par un employé de Context.ai

• Le passage où le CEO attribue publiquement la rapidité des attaquants à des techniques d’attaque accélérées par l’IA me semble, à moi, très peu étayé. Du coup, j’ai aussi l’impression qu’il n’y a pas grand-chose de concret qui soit réellement révélé

  • En ce moment, l’IA semble même bouleverser le marché des excuses absurdes, et j’ai le sentiment que la presse relaie cela sans véritable vérification
  • D’un autre côté, cela me rappelle que les solutions vibe coded avaient souvent tendance à recommander Vercel. Ça me fait penser à l’ancienne vague de recommandations d’Axios

• Je n’ai pas bien compris l’explication de la Phase 2. Si l’application ContextAI demandait toutes les autorisations Google mail, drive, calendar, ça me paraît excessif. Ce n’est pas une toute petite société, et j’ai du mal à croire qu’elle ait accepté de faire tourner ce genre de chose hors de son propre environnement. Cela dit, en lisant le billet de mise à jour sécurité de Context.ai, on a plutôt l’impression qu’un employé de Vercel a, à titre personnel, autorisé un accès complet à son Google Workspace

• J’ai toujours du mal à voir précisément comment cette chaîne a fonctionné. Je me demande si le token OAuth mentionné ici est celui reçu après Sign in with Google. En général, ce token n’est-il pas lié au client id et au client secret d’une application Google donnée ? Même si un attaquant connaît le token OAuth de l’utilisateur et les informations du client, je comprends qu’il puisse accéder à Drive, etc., mais je ne vois pas bien comment cela débouche ensuite sur une connexion au control plane de Vercel. Je me demande s’ils ont fini par trouver des identifiants dans Google Drive

  • J’ai l’impression que le rapport n’est pas clair sur ce point. Cela pousse presque à supposer qu’il y a eu une erreur encore plus embarrassante, qu’ils cherchent à dissimuler. Ça pouvait être un mot de passe stocké dans Drive ou Gmail, ou, comme le suggère un autre commentaire, un lien de connexion passwordless
  • Une fois le flux OAuth terminé, on reçoit finalement un session token, et c’est avec lui qu’on peut envoyer des requêtes à l’API. L’hypothèse centrale semble être que le token émis donnait aussi accès à la boîte de réception de la victime, et que l’attaquant a pu lire ses e-mails pour récupérer un mot de passe à usage unique, un magic link, ou d’autres informations sensibles
  • Moi aussi, je suis perdu. Je me demande si c’est réellement l’application OAuth de Context.ai qui a été compromise, et si cela a donné aux attaquants la même visibilité que Context.ai sur tous les espaces de travail de ses clients. Mais alors, pourquoi la responsabilité semble-t-elle se concentrer sur un seul employé en particulier ? Au fond, la vraie question semble être de savoir si cet employé de Vercel a autorisé Context.ai à lire l’intégralité de l’espace de travail Vercel

• Je suis d’accord avec l’idée qu’il faut « traiter les applications OAuth comme des fournisseurs tiers, supprimer les secrets de plateforme de longue durée et concevoir en supposant une compromise côté fournisseur », mais concevoir en partant du principe qu’un fournisseur sera compromis me paraît vraiment difficile. Après tout, la confiance est le point de départ du système

  • Comme nous réfléchissons nous-mêmes aux applications OAuth dans notre SaaS, cela me semble d’autant plus un problème extrêmement difficile. Je me demande même s’il existe une marketplace qui résout cela correctement. Après l’incident Salesloft, Cloudflare a proposé de proxyfier tout le trafic OAuth et API tiers via ses propres services, mais j’ai aussi l’impression que cela ne fait que déplacer le vecteur de menace ailleurs. Au-delà des règles de base comme minimiser les scopes, réduire les expirations ou faire la rotation des client secrets, je ne vois pas très bien quoi faire de plus. Une allowlist d’IP source par client est une des rares idées qui me viennent
  • Ce genre de cas donne aussi l’impression que tout ce discours sur le zero-trust relevait en grande partie du marketing. Si l’on veut une vraie security by design, il faudrait intégrer dès le départ l’hypothèse qu’une attaque de la supply chain puisse compromettre totalement un fournisseur en amont

• À mon avis, ce genre d’incident va devenir bien plus fréquent. J’ai l’impression que toute l’économie IT encaisse avec retard la dette de risque accumulée parce que les grandes comme les petites entreprises ont largement expérimenté des outils d’IA. Du coup, j’ai tendance à lire cela non pas comme de l’“AI-enabled tradecraft”, mais comme le résultat de directions d’entreprise qui ont poussé à l’installation et au test d’outils d’IA partout au nom de la vitesse. L’attaque en elle-même est extrêmement banale, et presque toutes les entreprises sont exposées dès lors qu’elles n’ont pas d’allowlist imposable pour les installations d’outils IA. Si vous demandez aux équipes IT combien d’outils comme Context sont installés, en local comme en SaaS, il y en a probablement beaucoup. Le problème, c’est que ces outils ont pratiquement accès à tout, tandis que l’écosystème des vendors de sécurité et du RBAC capable de les encadrer n’arrivera sans doute pas à maturité avant encore 18 à 24 mois. Vercel ressemble à un canari dans la mine, et je doute fortement que Context ait été la seule cible. C’est à mon sens un vecteur de menace bien connu mais ignoré, où la compromission d’un acteur peut en faire tomber d’autres en chaîne. Les six prochains mois risquent d’être particulièrement difficiles, et tout le monde devrait déjà être en train d’auditer ses installations d’IA, ou de s’y mettre. Les attaquants, eux, exploiteront probablement les accès qu’ils possèdent déjà avant qu’ils ne soient bloqués. Pour référence, je suis responsable sécurité dans l’industrie tech

  • Je dis moi aussi depuis quelques années qu’on va voir beaucoup d’incidents de sécurité étranges faire la une
  • Je partage complètement ce point de vue. J’ai vraiment l’impression qu’on entre dans une période assez intéressante

• En lisant le résumé disant que « la relation de confiance OAuth s’est propagée jusqu’à exposer toute la plateforme, que le CEO a attribué la rapidité de l’attaque à l’IA, et que le délai entre détection et divulgation pose aussi question », l’échec principal qui me saute aux yeux paraît très classique. Il y avait manifestement un compte utilisateur aux privilèges excessifs, et il y en avait peut-être d’autres semblables. Il est aussi très probable qu’il n’y avait pas de 2FA ou de ZeroTrust, ou alors de façon très limitée. Globalement, l’hygiène de sécurité ne semblait pas bonne

  • J’ai l’impression qu’à l’avenir, accuser l’IA deviendra l’excuse passe-partout des incidents de sécurité, un peu comme accuser systématiquement une DDoS quand un site tombe

• Il y a un point que beaucoup de gens ratent. Même si on fait tourner les variables d’environnement sur Vercel, les anciens déploiements ne sont pas automatiquement invalidés, donc les anciens deploys continuent de fonctionner avec les vieux identifiants tant qu’on ne les redéploie pas ou qu’on ne les supprime pas. Donc même après rotation des clés à la suite de l’annonce, les valeurs compromises peuvent encore rester actives si tous les déploiements n’ont pas été relancés. Et il faut aussi absolument vérifier les autorisations OAuth dans Google Workspace. Si vous allez dans Admin Console > Security > API Controls > Third-party app access, il est fort probable que des applications approuvées il y a deux ans pour une démo aient encore aujourd’hui un accès complet au mail et à Drive

  • C’est pour cette raison que nous utilisons plusieurs comptes Google distincts. Mais beaucoup d’organisations ne peuvent pas se le permettre à cause du coût par utilisateur de Google Workspace. Dans un ancien poste, j’avais aussi proposé de donner ce type d’autorisations OAuth à un compte séparé plutôt qu’au compte principal, mais cela n’avait pas abouti
  • En général, quand on parle de rotation de credentials, j’estime que cela inclut l’invalidation des anciens identifiants. Créer les nouveaux tout en laissant les anciens actifs me paraît être quelque chose qu’on entend très rarement
  • Cette phrase du rapport m’a moi aussi beaucoup troublé. Le fait qu’un ancien déploiement utilise encore une vieille env var ne détermine pas, en soi, si ce credential reste valide ou non. Cela ressemble davantage à un footgun qui affecte la disponibilité que la confidentialité. La section du rapport intitulée “Environment variable enumeration (Stage 4)” m’a aussi paru étrange. En particulier lorsqu’elle dit de surveiller si l’accès aux variables d’environnement provient d’un user account plutôt que d’un service account, ou d’un compte qui n’interagit habituellement pas avec le projet : j’ai trouvé étrange de découvrir que des gens récupéraient réellement des identifiants depuis les env vars Vercel pour les réutiliser dans d’autres systèmes
  • Les preview deploys me paraissent encore plus problématiques. Il s’en crée un par PR avec les mêmes env vars, et personne ne les nettoie. On peut faire tourner les clés et redéployer la prod, mais il peut rester des centaines de previews zombies avec les anciennes valeurs
  • Lors d’une rotation, il va de soi qu’il faut aussi faire expirer les anciennes variables

• Certains détails de ce rapport, en particulier la timeline qui commence en 2024~2025, m’ont donné l’impression de ne pas avoir été largement relayés ailleurs. Par exemple, je me demande d’où viennent des dates comme « fin 2024 à début 2025, les attaquants ont pivoté de l’accès OAuth Context.ai vers le compte Google Workspace d’un employé de Vercel », ou « début à mi-2025, l’accès aux systèmes internes de Vercel et l’énumération des variables d’environnement des clients ont commencé »

  • À mon avis, toutes ces dates sont inventées, et il est fort possible qu’il s’agisse d’une hallucination