Vercel confirme une faille de sécurité, des hackers affirment vendre les données dérobées
(bleepingcomputer.com)- Vercel a officiellement confirmé un incident de sécurité impliquant un accès non autorisé à ses systèmes internes, et collabore actuellement avec des experts en réponse aux incidents ainsi qu’avec les forces de l’ordre
- La cause de la compromission est liée à l’application Google Workspace OAuth de l’outil d’IA tiers Context.ai, qui a été compromise, entraînant le détournement d’un compte employé de Vercel
- Les attaquants ont énuméré des variables d’environnement non sensibles (non-sensitive) afin d’obtenir des privilèges supplémentaires, ces variables étant stockées sans chiffrement au repos
- Un hacker se présentant comme ShinyHunters affirme sur un forum de piratage vendre des clés d’accès, du code source, des données de base de données, des clés API, etc., et réclame une rançon de 2 millions de dollars
- Vercel a confirmé la sécurité de ses projets open source comme Next.js et Turbopack, et recommande à ses clients de vérifier leurs variables d’environnement et d’activer la fonctionnalité de variables sensibles
Aperçu de l’incident de sécurité
- Vercel est une plateforme d’infrastructure cloud d’hébergement et de déploiement spécialisée dans les frameworks JavaScript, éditrice de Next.js et fournisseur de fonctions serverless, d’edge computing et de services de pipeline CI/CD
- Dans un avis de sécurité, l’entreprise a officiellement confirmé qu’un accès non autorisé (unauthorized access) à ses systèmes internes avait eu lieu
- Un sous-ensemble limité de clients a été affecté, mais le service lui-même n’a pas été impacté
- L’entreprise a engagé des experts en réponse aux incidents et a notifié les forces de l’ordre, tout en poursuivant l’enquête
Vecteur de compromission et détails techniques
- La cause profonde de la faille est la compromission de l’application Google Workspace OAuth de la plateforme d’IA tierce Context.ai
- Le CEO de Vercel, Guillermo Rauch, a publié des détails supplémentaires sur X (anciennement Twitter)
- Les attaquants ont compromis le compte Google Workspace d’un employé de Vercel via la compromission de Context.ai
- Ils ont ensuite élevé leurs privilèges (escalate) depuis ce compte vers l’environnement Vercel
- Les attaquants ont accédé à des variables d’environnement marquées "non sensibles (non-sensitive)", stockées sans chiffrement au repos (not encrypted at rest)
- Vercel indique que toutes les variables d’environnement client sont stockées avec un chiffrement complet au repos (fully encrypted at rest) et protégées par des mécanismes de défense multicouches, mais que les variables marquées comme "non sensibles" ont servi de point faible
- Recommandation aux administrateurs Google Workspace de vérifier l’application OAuth suivante :
110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
Les affirmations des hackers sur la vente des données
- Un acteur malveillant se présentant comme ShinyHunters a publié sur un forum de piratage un message affirmant disposer des données issues de la compromission de Vercel et les mettre en vente
- Éléments proposés à la vente : clés d’accès, code source, données de base de données, accès au déploiement interne, clés API (dont des tokens NPM et GitHub)
- Il affirme détenir l’accès à de nombreux comptes employés, en présentant des données Linear comme preuve
- D’anciens acteurs malveillants liés au groupe ShinyHunters ont nié auprès de BleepingComputer toute implication dans cet incident
- Le fichier texte partagé par les attaquants contiendrait 580 fiches d’employés de Vercel, avec nom, adresse e-mail Vercel, statut du compte et horodatages d’activité
- Une capture d’écran présentée comme provenant du tableau de bord Vercel Enterprise a également été partagée
- BleepingComputer n’a pas pu vérifier indépendamment l’authenticité de ces données et de cette capture
- Dans des messages Telegram, l’acteur malveillant affirme être en contact avec Vercel et avoir demandé une rançon de 2 millions de dollars (ransom)
Réponse de Vercel et recommandations aux clients
- Vercel a confirmé que Next.js, Turbopack et les autres projets open source sont sûrs
- L’entreprise a déployé sur le tableau de bord une page de vue d’ensemble des variables d’environnement ainsi qu’une interface améliorée pour gérer les variables d’environnement sensibles
- Mesures recommandées aux clients :
- Vérifier les variables d’environnement (environment variables)
- Activer la fonctionnalité de variables d’environnement sensibles (sensitive environment variable feature) afin de garantir le chiffrement lorsqu’elles ne sont pas utilisées
- Effectuer une rotation des secrets (secret rotation) si nécessaire
3 commentaires
Réactions sur Hacker News
La mise à jour de l’avis publiée à l’instant m’a semblé importante, car elle précise que l’incident a commencé par la compromission d’une application OAuth Google Workspace d’un outil d’IA tiers
Des IOC pour aider à l’enquête ont aussi été publiés, avec la recommandation pour les administrateurs de vérifier immédiatement s’ils utilisent cette application
L’application OAuth est
110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com, et le texte original est consultable dans le bulletin de sécurité de VercelL’explication selon laquelle l’énumération de variables d’environnement non sensibles aurait permis des accès supplémentaires m’a particulièrement marqué, tout comme l’hypothèse qu’il s’agirait d’un groupe sophistiqué fortement accéléré par l’IA
Malgré cela, l’absence de notification par e-mail aux utilisateurs reste assez inquiétante
Je comprends la réticence à désigner immédiatement un responsable, mais masquer le nom du service donne l’impression de retarder la réponse
Aujourd’hui, au lieu de construire sur des bases stables, il est devenu trop normal d’assembler toutes sortes de composants tiers, ce qui multiplie les points de défaillance
Cela rappelle une fois de plus que la sécurité n’est jamais plus solide que son maillon le plus faible, et je considère qu’adosser un business à des outils d’IA au côté très vibe-coded est clairement risqué
Ça m’a amené à me demander s’il faut vraiment continuer à pousser dans cette direction, et jusqu’à quel niveau de complexité on acceptera d’aller avant de revenir en arrière
En lisant cette analyse de la stack recommandée par Claude Code, j’ai eu l’impression que Claude Code contribue à uniformiser davantage le web en recommandant par défaut certains fournisseurs et frameworks
Ce manque de diversité semble au final élargir le rayon d’impact lorsqu’un incident se produit
On a l’impression que c’est devenu le choix par défaut
Quand je lui ai demandé de le faire sans Node, il l’a immédiatement réécrite avec un backend Python, en expliquant lui-même qu’il réduisait aussi les dépendances
Pour précision, c’était juste une expérience sur un résultat destiné à être jeté, pas une recommandation en faveur du vibe coding
Au final, c’est surtout une question de manière de l’utiliser, et il faut mieux guider les développeurs pour qu’ils ne laissent pas Claude décider à leur place
On peut prendre en compte des conseils, mais au bout du compte un humain doit faire une revue critique, et sur ce point cela ne me semble pas très différent du travail avec d’autres membres d’une équipe
Internet avait déjà cette tendance, mais ici cela me paraît un peu différent
En tant qu’ancien membre d’une équipe de réponse aux incidents de sécurité, je compatis avec la difficulté de la tâche pour l’équipe actuelle
Mais la première communication m’a vraiment paru désastreuse
Elle ne disait pas ce qui s’était passé, tout en employant des formulations laissant entendre que c’était assez grave pour prévenir les forces de l’ordre, et les seules consignes données aux clients se résumaient à « examinez vos variables d’environnement »
Or, du point de vue du client, c’était beaucoup trop flou. Fallait-il vérifier si les valeurs existaient encore ? Comment était-on censé déterminer si elles avaient déjà fuité ?
À mon sens, il fallait immédiatement dire de faire tourner tous les mots de passe, jetons d’accès et secrets sensibles confiés à Vercel, puis recommander un audit des journaux d’accès et des anomalies sur les données clients
Si l’on paie un hébergement coûteux, c’est justement parce qu’on s’attend à une gestion professionnelle de la sécurité et de la fiabilité, et là, même en tenant compte de l’incertitude du début, tout cela semblait excessivement vague de manière délibérée
En revanche, si des secrets comme des clés API, jetons, identifiants de base de données ou clés de signature n’étaient pas marqués comme sensitive, il fallait les considérer comme potentiellement exposés et les remplacer en priorité
La source était la page d’incident, telle que je l’ai consultée à 16 h 22, heure de l’Est
Je suis client payant depuis plus d’un an, et voir un agrégateur de news me l’annoncer avant l’e-mail de l’entreprise est absurde
On peut retrouver ce contexte dans le fil HN et les réactions de l’époque
Pour le reste, ce sont généralement des choix qui s’attirent des problèmes
Mais j’ai décidé de ne plus compter sur cette commodité, et j’ai tout migré de Render vers linode
Avant, je payais plus de 50 dollars par mois à Render ; maintenant je suis autour de 3 à 5 dollars, donc je n’ai pratiquement plus l’intention de réutiliser ce type d’hébergeur
En lisant la phrase « Vercel n’a pas précisé quel système avait été compromis », même sans être expert en sécurité, cela m’a semblé une attitude assez difficile à justifier
Ça donnait aussi l’impression qu’ils cherchaient davantage à se protéger eux-mêmes qu’à aider les clients à comprendre l’impact
Par exemple, dire que le sous-système X peu connu de GitHub a été compromis n’apporterait peut-être pas beaucoup plus d’aide concrète que la formule déjà donnée selon laquelle « certains environnements clients ont été compromis »
En revoyant l’avis après l’ajout des IOC, il était clair que le fait que l’incident ait commencé par la compromission d’une application OAuth Google Workspace était une information importante pour l’ensemble de la communauté
Je me suis dit que les administrateurs et propriétaires de comptes devraient immédiatement vérifier cet identifiant d’application, et plus de détails figuraient dans l’avis de Vercel
Je suis sur MacBook Pro avec Chrome 147.0.7727.56, et en cliquant sur le logo Vercel en haut à gauche de la page, Chrome a immédiatement planté
Ça m’a semblé être un bug assez intéressant
La situation était assez drôle : tout le monde lisait que Vercel semblait avoir subi une compromission, et en même temps on se mettait à reproduire un crash de page web
Évidemment, je me suis aussi dit que ce genre d’expérience collective de reproduction ne pouvait absolument pas être sans effets pervers
J’ai même enregistré une vidéo, et comme j’utilise uBlock Origin Lite, je me suis demandé si cela venait de là, mais même en le désactivant, ça ne plantait toujours pas
Je me suis dit que cela aurait été un peu amusant si j’avais réussi à le reproduire
Ça avait duré un moment avant d’être finalement corrigé
En revanche, après avoir ouvert une fois la page d’accueil de Vercel directement par l’URL, cliquer sur le logo ne provoquait plus de crash
En revanche, maintenant j’ai un peu moins envie de cliquer sur le bouton Finish update
Pour compléter, je regardais aussi un autre fil HN et plusieurs posts sur X
Dans la première mention de Theo, il disait que cela semblait crédible ; dans un post de suivi, il précisait que les env var marquées sensitive étaient sûres et qu’il fallait remplacer préventivement les valeurs non marquées
Dans un autre post, il disait que ce type de piratage pouvait arriver à n’importe quel hébergeur, et dans une autre mention encore, un possible lien avec ShinyHunters était évoqué
Et s’il faut impérativement les changer, cela veut dire qu’il s’agissait dès le départ de données sensibles qui auraient dû être marquées sensitive, non ?
À ce stade, je n’avais pas l’impression qu’il apportait énormément de contenu concret
Ce genre d’incident rappelle à quel point l’écosystème web moderne est concentré autour de points de défaillance uniques
Jusqu’ici, la communication publique me semble relativement transparente, mais cela m’a quand même poussé à recalculer le profil de risque d’un choix reposant entièrement sur une PaaS entièrement managée
L’expression « un nombre limité de clients » est techniquement compatible même avec 99 %, donc cela m’a semblé être une formulation assez ambiguë
Je me suis aussi demandé si, en réalité, beaucoup de clients avaient été touchés, mais qu’on appelait simplement subset ceux parmi les grands comptes qu’il serait problématique de voir partir
En général, quand on peut vraiment rassurer, on donne un chiffre précis, comme « moins de 1 % des utilisateurs », ce qui n’a pas été fait ici
J’en ai donc conclu qu’ils manquaient peut-être encore de visibilité, ou que les chiffres ne leur convenaient pas
Cela dit, je compatis avec la difficulté du travail de l’équipe de réponse, et j’espère qu’à l’avenir ils communiqueront de façon plus ouverte et plus transparente
On voit aussi ici des caractères hindi. Ces derniers temps, quel que soit le modèle — openai, claude ou google — il arrive assez souvent que de l’hindi se mélange aux sorties en coréen ; est-ce que l’annotation des jeux de données coréens a été faite par des Indiens ?
Je n’aimais déjà pas les modèles chinois parce qu’ils mêlaient du chinois aux réponses en coréen, mais récemment, comme les modèles frontier se mettent à mélanger sans arrêt de l’hindi, ça a plutôt réduit mon rejet des modèles chinois.
Avec Claude, il me semble que du japonais apparaît souvent. C’était encore le cas hier.