Le 19 avril 2026, Vercel — la plateforme de déploiement cloud utilisée par des millions de développeurs à travers le monde — a confirmé avoir été victime d'une intrusion dans ses systèmes internes. Derrière l'attaque : le groupe ShinyHunters, déjà responsable de plusieurs violations de données majeures ces dernières années. Le vecteur d'entrée n'était pas une faille dans l'infrastructure Vercel elle-même, mais une compromission en cascade venue d'un outil tiers.
Une chaîne d'approvisionnement comme point d'entrée
Tout a commencé chez Context.ai, une plateforme d'analyse alimentée par l'IA utilisée par des équipes techniques. Un employé de Vercel utilisait ce service — et c'est là que la brèche s'est ouverte. Les attaquants ont exploité une vulnérabilité chez Context.ai pour compromettre son compte Google Workspace via une application OAuth malveillante. Une fois dans la place, l'escalade de privilèges vers les systèmes internes de Vercel n'a été qu'une question de temps.
Ce type d'attaque illustre parfaitement pourquoi la sécurité d'une entreprise n'est plus seulement affaire de ses propres systèmes — chaque outil tiers est une surface d'attaque potentielle.
Le groupe ShinyHunters est connu pour sa sophistication opérationnelle. Leur méthode ici — compromettre un maillon faible de la chaîne pour rebondir vers une cible plus grande — est un manuel classique de l'attaque par supply chain, popularisé à grande échelle depuis SolarWinds en 2020.
Ce qui a été touché — et ce qui ne l'a pas été
Vercel a communiqué rapidement sur le périmètre de l'incident. Les données confirmées comme compromises incluent :
- ~580 dossiers d'employés : noms, adresses e-mail et horodatages d'activité
- Variables d'environnement non protégées d'un sous-ensemble limité de clients — celles non marquées comme "sensibles" dans l'interface Vercel
En revanche, Vercel affirme que les variables d'environnement marquées comme sensibles — chiffrées au repos — n'ont pas été exposées. Les projets open source comme Next.js et Turbopack n'ont pas été compromis. Les services sont restés opérationnels tout au long de l'incident.
Les attaquants ont de leur côté prétendu détenir bien davantage : clés d'accès, codes sources, données de bases de données, tokens npm et GitHub. Ils ont réclamé une rançon de 2 millions de dollars et menacé de revendre les données sur des forums cybercriminels. Ces affirmations n'ont pas été vérifiées indépendamment.
La réponse de Vercel
La plateforme a mobilisé Mandiant (filiale de Google spécialisée en réponse aux incidents) et d'autres experts en cybersécurité. Les autorités fédérales américaines ont été notifiées. Vercel a également déployé des mesures de surveillance renforcées sur ses systèmes.
Côté utilisateurs, la plateforme recommande une série d'actions immédiates :
- Examiner les journaux d'activité pour détecter tout comportement suspect
- Effectuer une rotation de toutes les variables d'environnement non marquées comme sensibles
- Activer la protection des variables sensibles sur les projets existants
- Inspecter les déploiements récents pour détecter toute anomalie
- Configurer la Deployment Protection au niveau Standard minimum
- Rotation des tokens de Deployment Protection
L'alerte particulière pour les projets crypto
L'incident a déclenché une vague de panique dans l'écosystème crypto, où de nombreux projets DeFi et Web3 utilisent Vercel pour déployer leurs frontends. Des variables d'environnement exposées — même "non sensibles" — peuvent contenir des clés d'API de wallets, des endpoints RPC ou des configurations pointant vers des contrats intelligents. Plusieurs équipes ont signalé avoir procédé en urgence à la rotation de leurs secrets dans les heures suivant l'annonce.
Si vous déployez un projet crypto sur Vercel : traitez l'incident comme si vos variables étaient compromises, même si vous n'avez pas reçu de notification directe de Vercel.
Les leçons à retenir
L'incident Vercel n'est pas une faille dans le code de Vercel — c'est une attaque sociale et organisationnelle qui a exploité la confiance implicite accordée aux outils SaaS. Il y a plusieurs enseignements immédiats à tirer :
- Toujours marquer les secrets comme sensibles dans Vercel. La distinction existe pour une raison.
- Principe du moindre privilège pour les comptes employés — limiter l'accès aux systèmes internes depuis des outils tiers.
- Auditer les applications OAuth connectées aux comptes Google Workspace de l'équipe régulièrement.
- Ne pas stocker de secrets critiques dans des env vars non chiffrées — utiliser un gestionnaire de secrets dédié (HashiCorp Vault, AWS Secrets Manager) pour les tokens à haute valeur.
Dans un monde où les pipelines de déploiement sont devenus des cibles prioritaires pour les attaquants — de CodeCov à CircleCI, en passant maintenant par Vercel — la surface d'attaque de la supply chain logicielle n'a jamais été aussi large. Et les outils que l'on utilise quotidiennement sans y penser sont souvent les vecteurs les moins surveillés.
