🛡️ Cybersécurité/Vercel piraté via un outil IA tiers : la supply chain du web en danger
vercelshinyhunterssupply chaincontext.aicybersécuritéOAuth

Vercel piraté via un outil IA tiers : la supply chain du web en danger

ShinyHunters revendique l'accès aux systèmes internes de Vercel via Context.ai. Comment un simple outil tiers a failli compromettre des millions de sites web.

Julian COLPARTJulian COLPART9 min de lecture

Un outil IA d'analyse de code. Un accès OAuth Google Workspace. Et voilà comment l'un des hébergeurs les plus utilisés au monde s'est fait infiltrer.

Le 19 avril 2026, Vercel publiait un bulletin de sécurité sobre mais alarmant : un acteur non autorisé avait accédé à une partie de ses systèmes internes. En parallèle, sur BreachForums — le forum underground de référence — un vendeur se réclamant du groupe ShinyHunters proposait à 2 millions de dollars des clés d'accès, du code source et des bases de données liées à l'infrastructure de l'entreprise.

Le point d'entrée ? Context.ai, un petit outil d'IA destiné à l'analyse de code, utilisé par un employé de Vercel. Une compromission tierce partie, banale en apparence, qui a failli déclencher l'une des pires crises de supply chain de l'histoire du web.

Contexte : Vercel, l'infrastructure invisible du web moderne

Si tu développes des applications web, tu connais Vercel. L'entreprise américaine héberge et déploie des millions de sites et d'applications à travers le monde. Elle est surtout connue pour être le créateur et le principal mainteneur de Next.js, le framework React le plus populaire de l'écosystème frontend.

En pratique, Vercel est le passage obligé de dizaines de milliers de startups, d'entreprises et de projets open source. Quand tu déplies ton code sur Vercel, l'entreprise gère le build, l'hébergement, le CDN, les variables d'environnement — y compris tes secrets de production, clés API et tokens d'accès.

Autant dire qu'une compromission de cette plateforme ne concerne pas juste une entreprise. C'est l'ensemble de la chaîne d'approvisionnement numérique qui vacille.

Le scénario de l'attaque, étape par étape

Vercel a publié un bulletin de sécurité détaillé qui retrace le cheminement de l'attaquant. Voici ce qui s'est passé.

Étape 1 : la compromission de Context.ai

L'attaquant a d'abord compromis Context.ai, un outil d'intelligence artificielle utilisé pour l'analyse et l'amélioration de code. Context.ai disposait d'une application OAuth intégrée à Google Workspace — le système d'authentification utilisé en interne par Vercel.

La faille n'était pas chez Vercel. Elle était chez un fournisseur tiers, dont l'application OAuth avait des permissions sur les comptes Google de ses utilisateurs.

Étape 2 : le piratage du compte Google Workspace d'un employé

Grâce à la compromission de Context.ai, l'attaquant a pu détourner le compte Google Workspace individuel d'un employé de Vercel. Le résultat : un accès authentifié, légitime en apparence, à l'environnement interne de l'entreprise.

Pas de brute force. Pas d'exploit zero-day. Juste une faille dans une application tierce connectée à l'écosystème d'identité de l'entreprise.

Étape 3 : le pivot vers les systèmes internes

Une fois à l'intérieur, l'attaquant a navigué dans les systèmes de Vercel. Son objectif : lire et déchiffrer les variables d'environnement non sensibles stockées sur la plateforme. Ces variables, quand elles ne sont pas marquées comme « sensibles » par les utilisateurs, sont décryptables en texte clair.

Autrement dit : clés API, tokens de déploiement, identifiants de base de données — tout ce que les développeurs ont omis de classer comme sensible était potentiellement exposé.

Vercel a qualifié l'attaquant de « hautement sophistiqué », citant sa vélocité opérationnelle et sa connaissance approfondie de la surface API de l'entreprise. L'enquête a été confiée à Google Mandiant, l'un des leaders mondiaux de la réponse aux incidents.

Ce qui a été exposé — et ce qui a été préservé

Vercel a été relativement transparent sur l'ampleur de l'incident. Voici ce qu'on sait.

Données Statut
Variables d'environnement non sensibles Compromises (texte clair)
Variables d'environnement sensibles Non compromises
Packages npm publiés par Vercel Vérifiés, non compromis
Base de données interne Revendiquée par ShinyHunters, non confirmée
Données employés Potentiellement exposées

Le point positif : Vercel, en collaboration avec GitHub, Microsoft, npm et Socket, a confirmé que la chaîne d'approvisionnement npm restait intacte. Aucun package publié par Vercel n'a été altéré.

Le point inquiétant : les variables d'environnement non sensibles peuvent contenir des secrets très réels. Beaucoup de développeurs ne prennent pas la peine de marquer leurs variables comme « sensibles » dans l'interface Vercel — un réflexe qui a pu coûter cher.

ShinyHunters : des criminels ou des imitateurs ?

Le groupe ShinyHunters est apparu en 2020. Il est connu pour avoir ciblé des entreprises technologiques de premier plan, volant des bases de données massives qu'il revend ou extorque sur des forums criminels.

Mais dans cette affaire, un détail intriguant : ShinyHunters a nié toute implication quand CyberInsider les a contactés. Le groupe n'apparaît pas non plus sur leur portail d'extorsion connu.

Deux hypothèses : soit un acteur distinct utilise le nom de ShinyHunters comme paravent, soit le groupe opère en cellules décentralisées. Quoi qu'il en soit, la vente proposée sur BreachForums — 2 millions de dollars pour des accès Vercel — a été prise très au sérieux.

La vague ShinyHunters d'avril 2026

L'incident Vercel n'est pas isolé. Ce même mois d'avril, le groupe ShinyHunters — ou des acteurs s'en réclamant — a été lié à plusieurs attaques majeures :

  • Canada Life : 70 000 personnes touchées par une intrusion via un compte employé compromis. Noms, dates de naissance, adresses, niveaux de revenus exposés.
  • Polmed (Afrique du Sud) : le régime de santé de la police sud-africaine piraté. Des données extrêmement sensibles — fonctions des agents, adresses résidentielles, dossiers médicaux — auraient été exfiltrées.

Un constat s'impose : les attaquants ciblent systématiquement les identités et les accès tiers plutôt que les infrastructures elles-mêmes. Pourquoi s'attaquer à un système blindé quand on peut compromettre l'outil IA d'un employé et récupérer ses accès Google ?

Les leçons à retenir pour les développeurs et les entreprises

L'incident Vercel illustre parfaitement un danger qui grandit chaque jour dans l'écosystème tech : la confiance aveugle dans les outils tiers.

1. Marque tes variables comme sensibles

Vercel propose un paramètre de variables d'environnement sensibles qui empêche leur lecture, même par les administrateurs du projet. Si tu ne l'actives pas, tes secrets sont potentiellement lisibles en texte clair par quiconque accède aux systèmes.

2. Limite les permissions OAuth des outils tiers

Context.ai avait un accès OAuth à Google Workspace. Cet accès a été le vecteur de l'attaque. Chaque outil connecté à ton écosystème d'identité est une surface d'attaque supplémentaire.

Applique le principe du moindre privilège : un outil d'analyse de code n'a pas besoin d'un accès complet à ton Google Workspace.

3. Active l'authentification multifacteur résistante au phishing

Vercel le recommande dans son bulletin : utilise une clé hardware (YubiKey, Titan) ou une authentification résistante au phishing. Le SMS ne suffit plus.

C'est d'autant plus critique que les campagnes de phishing sont devenues quasi indétectables grâce à l'IA générative.

4. Surveille tes journaux d'activité

Vercel a détecté l'intrusion grâce à l'analyse de ses journaux de requêtes et d'événements. Fais de même dans ton propre environnement. Surveille les lectures inhabituelles de variables, les déploiements suspects, les accès depuis des localisations inconnues.

Le risque supply chain : une menace systémique

Ce qui rend l'incident Vercel particulièrement préoccupant, c'est sa nature de supply chain attack — une attaque sur la chaîne d'approvisionnement.

L'attaquant n'a pas ciblé directement les clients de Vercel. Il a ciblé Vercel lui-même, sachant qu'un accès aux systèmes internes de la plateforme lui donnerait potentiellement accès aux déploiements de millions de sites web.

C'est exactement le même schéma que l'attaque de l'ASP qui a exposé les données bancaires de citoyens français : on ne s'attaque pas à la victime finale, on s'attaque à l'intermédiaire de confiance.

Et ce n'est pas près de s'arrêter. Comme l'a montré la fuite de données de l'ANTS affectant 12 millions de Français, les systèmes centralisés sont des cibles de choix. Plus une plateforme est critique, plus elle attire les attaquants.

Les 1300 serveurs SharePoint vulnérables : un autre signal d'alerte

L'actualité de cette semaine porte un autre message frappant : plus de 1 300 serveurs Microsoft SharePoint restent non corrigés contre la vulnérabilité CVE-2026-32201, une faille d'usurpation d'identité activement exploitée.

Pourtant, le correctif a été publié lors du Patch Tuesday d'avril. Moins de 200 systèmes ont été mis à jour depuis. La CISA (agence américaine de cybersécurité) a classé la faille dans son catalogue des vulnérabilités connues et exploitées, obligeant les agences fédérales à patcher en urgence.

Le parallèle avec Vercel est saisissant : dans les deux cas, le problème n'est pas tant la vulnérabilité technique que la lenteur de la réponse humaine. Les correctifs existent, les bonnes pratiques sont connues, mais l'application reste laborieuse.

Les recommandations de Vercel aux développeurs

Vercel a publié une série de recommandations que voici résumées :

  • Rotation immédiate de toutes les variables d'environnement non marquées comme sensibles
  • Vérification des journaux d'activité et des déploiements récents
  • Activation de la protection de déploiement au minimum en mode Standard
  • Rotation des tokens de protection de déploiement
  • Activation de l'authentification multifacteur (app authenticateur ou passkey)

Vercel a également publié un indicateur de compromission (IOC) : l'identifiant de l'application OAuth Google Workspace utilisée par l'attaquant (110671459871-...). Les administrateurs Google Workspace sont invités à vérifier si cette app a été utilisée dans leur environnement.

Pourquoi cette attaque est un tournant

L'incident Vercel marque un tournant pour plusieurs raisons.

D'abord, il montre que les outils IA tiers sont devenus des vecteurs d'attaque à part entière. Un outil d'analyse de code, a priori inoffensif, a servi de pont vers l'infrastructure critique d'une entreprise majeure.

Ensuite, il confirme que les attaquants ont compris quelque chose de fondamental : les systèmes centraux sont blindés, mais l'écosystème d'outils connectés autour est souvent laissé sans surveillance. Comme l'a démontré l'affaire où Meta espionnait ses propres salariés via des outils IA, les outils que nous adoptons aveuglément peuvent se retourner contre nous.

Enfin, il rappelle que la sécurité n'est jamais un problème résolu. Vercel fait partie des entreprises les plus regardantes sur la sécurité. Leurs systèmes étaient solides. Mais la surface d'attaque s'est étendue là où personne ne regardait : une application OAuth tierce.

Ce que tu dois faire maintenant

Si tu utilises Vercel — ou n'importe quelle plateforme de déploiement cloud — prends dix minutes aujourd'hui pour :

  1. Vérifier que toutes tes variables d'environnement contenant des secrets sont marquées comme sensibles
  2. Rotation tes clés API et tokens, même si tu penses ne pas être concerné
  3. Auditer les applications OAuth connectées à ton compte Google ou GitHub
  4. Activer le 2FA avec une clé hardware si ce n'est pas déjà fait

L'attaque Vercel n'est probablement que le début d'une série d'incidents similaires ciblant les outils du développeur. L'écosystème SaaS est interconnecté comme jamais. Chaque connexion est une porte potentielle.

La question n'est pas de savoir si ton fournisseur sera attaqué. C'est de savoir si tes secrets seront protégés quand ça arrivera.

Sources

Julian COLPART

Julian COLPART

Fondateur & Rédacteur en chef

Passionné de tech, d'IA et de tendances qui façonnent notre quotidien. Je vérifie et valide chaque article publié sur DailyTrend pour garantir l'exactitude et la qualité de l'information.