NVIDIA Brev : des clés SSH potentiellement exposées, comment vérifier le risque réel

Activité rapportée du 4 au 20 octobre 2026 ; notifications client relayées fin octobre. Des extraits de notifications attribuées à NVIDIA, rapportés par la presse, décrivent un accès non autorisé à Brev et une possible exposition de clés SSH utilisées pour des machines virtuelles clientes. La notification rapportée dit que des clés ont été remplacées et qu’aucun usage abusif n’a été trouvé à ce stade. Nous n’avons pas identifié de rapport d’incident public NVIDIA détaillant le vecteur initial, le nombre de comptes concernés ou une compromission des VM. L’intervalle de 16 jours décrit l’activité signalée sur la plateforme, pas 16 jours d’accès prouvé à chaque machine.

Que permet une clé SSH privée ?

Une paire SSH sépare une clé publique, autorisée sur la machine, d’une clé privée, utilisée par le client pour prouver son identité. Si un attaquant copie une clé privée et peut joindre un serveur qui accepte encore la clé publique correspondante, il peut tenter l’authentification sous le compte associé. La réussite dépend aussi de la configuration de la machine, des contrôles réseau, d’une éventuelle protection de la clé et des autres mécanismes d’accès. L’exposition possible d’une clé ne démontre donc ni une connexion réussie ni la lecture de données de la VM.

La documentation Brev décrit la gestion des clés par son outil en ligne de commande et les fichiers conservés dans le répertoire local ~/.brev/. Cela explique pourquoi la rotation doit être vérifiée aux deux extrémités : une nouvelle clé côté client et le remplacement ou la suppression de l’ancienne clé publique dans les comptes autorisés des instances. Une rotation annoncée par la plateforme ne dispense pas d’examiner d’autres copies de la clé, d’autres serveurs qui lui feraient confiance et les journaux d’authentification pendant la fenêtre rapportée.

Ce que l’enquête doit établir

Il faut distinguer quatre questions : quelles clés ont pu être lues, lesquelles étaient encore valides, sur quelles instances elles donnaient accès et quels usages apparaissent dans les journaux SSH. Une inspection des authorized_keys, des connexions et des nouveaux comptes ou clés ajoutés peut révéler un maintien d’accès indépendant de la clé initiale. Les workloads doivent également vérifier leurs propres secrets, car une VM compromise pourrait exposer des variables d’environnement ; aucune compromission de workload n’est établie par les sources publiques consultées.

Ce dossier est publié comme analyse conditionnelle d’une notification rapportée. Il ne faut pas lui attribuer le mode d’entrée, un nombre de victimes, ni une exploitation des clés que les éléments disponibles ne démontrent pas. Une publication technique de NVIDIA permettrait de préciser ces points.

Sources : notification client rapportée par Tom’s Hardware, documentation officielle du CLI Brev.