La fonction d'affichage dans le chat de Databricks Genie a été transformée, par un Skill malveillant, en canal d'exfiltration de données. Le 5 octobre 2026, la société de sécurité PromptArmor a publié un rapport de divulgation : après l'exécution d'un Skill malveillant par Genie Code, l'assistant agentique de Databricks, une fenêtre de phishing s'affiche lorsque l'utilisateur ouvre les résultats d'analyse, et les données du tenant partent vers un serveur de l'attaquant via le navigateur de l'utilisateur lui-même. Quatre catégories de contrôles sur lesquels les entreprises comptaient n'ont rien arrêté. Précisons d'emblée la nature de l'affaire : il s'agit d'une démonstration d'attaque publiée selon un processus de divulgation responsable, et non d'une fuite de données réelle confirmée.
Comment l'attaque va jusqu'au bout
Genie Code est l'assistant agentique de Databricks destiné aux équipes data des entreprises : il permet de manipuler les données d'un tenant en langage naturel. Databricks avance vite — le jour de la sortie d'un nouveau modèle, Databricks l'a fait tester par ses 12000 employés. La chaîne d'attaque démontrée par PromptArmor compte quatre étapes :
- Un utilisateur demande à Genie d'analyser des données à l'aide d'un Skill téléversé. Les Skills circulent sur des places de marché en ligne, un écosystème déjà pollué par des Skills malveillants. Et Genie charge les Skills depuis les espaces de travail personnels des utilisateurs, et non depuis le catalogue gouverné de l'organisation.
- Genie exécute le code du Skill. Un agent garde-fou examine les commandes avant exécution et signale les actions comme « envoyer des données à des tiers », mais cette fois, il a approuvé le code et manqué la capacité malveillante cachée à l'intérieur.
- Genie invite l'utilisateur à ouvrir les résultats complets de l'analyse.
- Dès que les résultats s'affichent, l'attaque se déclenche sur deux fronts : le code du Skill a déjà intégré à l'affichage HTML des informations sensibles collectées dans le tenant, comme les jeux de données de la victime ; les scripts de cet affichage amènent le navigateur de l'utilisateur à émettre des requêtes réseau qui emportent les données vers le serveur de l'attaquant. Au même moment, l'affichage superpose une page de phishing destinée à soutirer les identifiants de l'utilisateur. Aucune validation humaine n'intervient à aucun moment.
Pourquoi aucun des quatre contrôles n'a fonctionné
- La gouvernance des Skills au niveau de l'organisation : Databricks dispose d'un système de catalogue gouverné, mais Genie charge en réalité les Skills depuis les espaces personnels, une couche que la gouvernance n'atteint pas.
- L'agent garde-fou : selon Databricks, la fonction d'approbation automatique (auto-allow) n'est pas une frontière de sécurité, seulement une mesure de contrôle destinée à empêcher l'exécution automatique d'entrées non fiables. Elle reste pourtant le mode d'approbation des commandes par défaut et recommandé dans la documentation. Attendre d'elle un audit de sécurité, c'est lui demander ce pour quoi elle n'est pas faite.
- Les contrôles de sortie réseau de l'environnement de code : l'environnement de code n'a effectivement pas le droit de contacter des adresses externes non fiables, et cette règle n'a pas été enfreinte. Les requêtes ont été émises par le navigateur de l'utilisateur, une voie de sortie que les contrôles de l'environnement de code ne couvrent pas.
- Le bac à sable des affichages du chat : la règle interdisant à un affichage d'interroger les données du tenant a elle aussi été techniquement respectée — l'affichage n'a rien interrogé du tout. Il s'est contenté de rendre des données que le code du Skill y avait intégrées au préalable, avant de les expédier à l'extérieur.
Conclusion de PromptArmor : deux garanties ont été respectées à la lettre, et pourtant le résultat même qu'elles devaient empêcher — l'exfiltration de données — s'est produit. Cela révèle une brèche dans le modèle de menace de Databricks.
La réponse de Databricks, et le point resté sans réponse
Le calendrier est explicite : PromptArmor a signalé le problème à Databricks le 16 août 2026, les deux parties se sont coordonnées jusqu'au 15 septembre, et le 16 septembre PromptArmor a annoncé son intention de publier. La réponse centrale de Databricks tient en une phrase : « il incombe en dernier ressort à l'utilisateur de s'assurer que les Skills téléversés ne contiennent pas de contenu malveillant. » Sur le fait que Genie charge les Skills depuis les espaces personnels plutôt que depuis le catalogue gouverné de l'organisation, Databricks n'a fait aucune déclaration.
Ce que les équipes qui utilisent Genie doivent faire dès maintenant
Premièrement, traiter les Skills des espaces personnels comme du code : ne pas installer de Skills de source inconnue et les examiner avant usage. Deuxièmement, désactiver ou restreindre l'approbation automatique dans les environnements de données de production, en acceptant davantage d'interruptions de validation. Troisièmement, étendre la surveillance aux sorties côté navigateur — la leçon de cette affaire est que les données ne sortent pas forcément par le serveur, elles peuvent sortir par le navigateur d'un employé. Quatrièmement, inventorier tous les Skills déjà installés et leur provenance. Le risque n'est pas propre à Databricks : tout produit où un agent peut afficher du HTML dans le chat pendant que des Skills tiers touchent aux données métier devrait se tester contre la même chaîne d'attaque.
