Le bug permet aux serveurs de modèles contrôlés par des attaquants d’injecter du code, de voler des jetons de session et, dans certains cas, de passer à l’exécution de code à distance sur les backends d’IA d’entreprise.
Les chercheurs en sécurité ont signalé une faille de haute gravité dans Open WebUI, une interface d’entreprise auto-hébergée pour les grands modèles de langage, qui permet aux serveurs de modèles externes connectés via sa fonctionnalité Direct Connections d’injecter du code malveillant et de détourner les charges de travail d’IA.
Le problème, identifié comme CVE-2025-64496, provient d’une gestion dangereuse des événements envoyés par le serveur (SSE), permettant la prise de contrôle de compte et, dans certains cas, avec des autorisations étendues, l’exécution de code à distance (RCE) sur les serveurs back-end.
Selon les conclusions de Cato CTRL, si un employé connecte Open WebUI à un point de terminaison de modèle contrôlé par un attaquant, comme sous le prétexte d’une « alternative gratuite au GPT-4 », le frontend peut être amené à exécuter silencieusement le JavaScript injecté. Ce code vole les jetons Web JSON (JWT) dans le contexte du navigateur, offrant aux attaquants un accès persistant à l’espace de travail d’IA, aux documents, aux discussions et aux clés API intégrées de la victime.
Le bug affecte les versions d’Open WebUI jusqu’à 0.6.34 et est corrigé dans la version 0.6.35, les entreprises étant invitées à corriger les déploiements de production sans délai.
Une fonctionnalité de commodité transformée en crise
Les chercheurs de Cato ont déclaré que le problème venait des connexions directes, une fonctionnalité destinée à permettre aux utilisateurs de connecter Open WebUI à des serveurs modèles externes compatibles OpenAI. Le gestionnaire SSE de la plateforme fait confiance aux événements entrants provenant de ces serveurs, en particulier ceux marqués comme « {type : execute} », et exécute leur charge utile via un constructeur JavaScript dynamique.
Lorsqu’un utilisateur se connecte à un serveur malveillant, facilement activé grâce à l’ingénierie sociale, ce serveur peut diffuser un SSE avec du JavaScript exécutable. Ce script s’exécute avec un accès complet à la couche de stockage du navigateur, y compris le JWT utilisé pour l’authentification.
« Open WebUI stocke le jeton JWT dans localStorage », ont déclaré les chercheurs de Cato dans un article de blog. « Tout script exécuté sur la page peut y accéder. Les jetons ont une durée de vie longue par défaut, n’ont pas HttpOnly et sont croisés. Lorsqu’ils sont combinés avec l’événement d’exécution, cela crée une fenêtre pour la prise de contrôle du compte. «
L’attaque nécessite que la victime active les connexions directes (désactivées par défaut) et ajoute l’URL du modèle malveillant de l’attaquant, selon une description NVD.
Passage à l’exécution de code à distance
Le risque ne s’arrête pas au rachat de compte. Si le compte compromis dispose des autorisations workspace.tools, les attaquants peuvent exploiter ce jeton de session pour transmettre du code Python authentifié via l’API Tools d’Open WebUI, qui s’exécute sans sandboxing ni validation.
Cela transforme une compromission au niveau du navigateur en exécution complète de code à distance sur le serveur backend. Une fois qu’un attaquant obtient l’exécution de Python, il peut installer des mécanismes de persistance, pivoter vers les réseaux internes, accéder à des magasins de données sensibles ou lancer des attaques latérales.
La faille a reçu une note de gravité élevée avec un score de base de 8/10 par NVD et un score de base de 7,3/10 par GitHub. La faille a été jugée élevée plutôt que critique, reflétant le fait que son exploitation nécessite l’activation de la fonctionnalité de connexions directes et repose sur le fait qu’un utilisateur soit d’abord incité à se connecter à un serveur de modèles externe malveillant. L’atténuation des correctifs dans Open WebUI v0.6.35 implique le blocage complet des événements SSE « d’exécution » à partir de connexions directes, mais toute organisation encore sur des versions plus anciennes reste exposée. De plus, les chercheurs ont conseillé de déplacer l’authentification vers des cookies de courte durée et HttpOnly avec rotation. « Associez-le à un CSP strict et interdisez l’évaluation dynamique du code », ont-ils ajouté.
