RAG d'Open WebUI : une redirection qui atteint les identifiants du cloud
Un avis de fin juin 2026 montre que l'endpoint de récupération web d'Open WebUI ne vérifiait que la première URL : une redirection contrôlée par l'attaquant pouvait diriger la requête serveur vers les métadonnées cloud. Corrigé en 0.6.27.
De quoi s’agit-il ?
Le 30 juin 2026, un avis de sécurité a été publié pour Open WebUI, l’une des interfaces auto-hébergées les plus répandues pour piloter des modèles de langage locaux ou accessibles via API. Le problème est une faille de type SSRF (falsification de requête côté serveur) dans la fonction de récupération web : l’endpoint qui va chercher une URL fournie par l’utilisateur pour alimenter un pipeline de RAG appliquait son filtre de sécurité uniquement à l’URL saisie par l’appelant, et non à sa cible de redirection. Un utilisateur authentifié pouvait donc pointer le serveur vers une page qu’il contrôle, la faire répondre par une redirection HTTP vers une adresse interne, et laisser Open WebUI suivre cette redirection jusqu’à un endpoint de métadonnées cloud. La faille est classée CWE-918 (SSRF) et touche toutes les versions antérieures à 0.6.27, où elle est corrigée.
Ce n’est ni une attaque au niveau du prompt ni un jailbreak de modèle. C’est un SSRF applicatif classique qui se trouve logé dans un outil LLM — exactement le type de surface qui s’étend chaque fois qu’une interface de chat se voit confier la capacité d’aller chercher des URL arbitraires au nom d’un utilisateur.
Comment ça marche
L’endpoint de récupération d’Open WebUI accepte une URL, va chercher la page côté serveur et transmet le texte au pipeline RAG. Pour empêcher cette requête d’atteindre des systèmes internes, le code exécutait un filtre de blocage sur l’hôte demandé. Le défaut : la vérification n’avait lieu qu’une fois, sur l’URL originale de l’appelant, après quoi le client HTTP sous-jacent était autorisé à suivre les redirections sans nouvelle validation.
Un attaquant disposant d’une session authentifiée soumet une URL vers un serveur qu’il opère. Ce serveur répond par une redirection 3xx dont l’en-tête Location désigne une cible interne ou en lien local — par exemple le service de métadonnées d’instance sur 169.254.169.254, ou l’hôte équivalent chez GCP, Azure ou Alibaba Cloud. Comme la logique de filtrage ne validait que le premier saut et que les adresses de métadonnées ne figuraient pas dans la liste de blocage par défaut, le client émettait la seconde requête et renvoyait le corps de la réponse à l’appelant. Sur un hôte cloud dont l’accès aux métadonnées n’est pas durci, ce corps peut contenir les identifiants IAM de l’instance, transformant une fonction de récupération en lecture seule en chemin vers les secrets du cloud. L’impact rapporté se limite à la divulgation d’information (confidentialité), avec un vecteur réseau mais un prérequis de privilège — l’attaquant a besoin d’un compte valide capable d’appeler l’endpoint de récupération. Nous ne publions délibérément pas ici de configuration de redirecteur prête à l’emploi : la leçon est le mécanisme, pas un payload.
Pourquoi c’est important
Open WebUI est un choix par défaut pour les équipes qui veulent une interface de chat privée au-dessus d’Ollama ou d’une API hébergée, et un grand nombre de ces instances tournent sur des VM cloud. Deux faits rendent la faille digne d’attention malgré son score de gravité modéré. D’abord, le gain est un vol d’identifiants : une redirection réussie vers un service de métadonnées non protégé peut livrer les identifiants du rôle d’instance, un pied dans la porte bien plus précieux que la récupération elle-même. Ensuite, le prérequis — un utilisateur authentifié capable d’atteindre la fonction de récupération — est plus faible qu’il n’y paraît dans les nombreux déploiements qui autorisent l’auto-inscription ou partagent un même locataire peu fiable. Des schémas voisins de SSRF vers les métadonnées dans le même écosystème, d’un chargeur d’images de serveur d’inférence qui tirait les métadonnées cloud à des serveurs MCP qui atteignent le service de métadonnées d’instance, pointent la même leçon : tout composant LLM autorisé à émettre des requêtes sortantes hérite de tous les risques SSRF ordinaires, et l’internet regorge de front-ends LLM auto-hébergés exposés qui ne s’attendaient pas à être joignables.
Défenses
Mettez à jour Open WebUI vers la version 0.6.27 ou ultérieure. C’est le correctif principal : le patch ajoute une liste de blocage par défaut couvrant les adresses en lien local et de métadonnées cloud, et résout les cibles de redirection en adresse IP avant d’autoriser le client à les suivre — un en-tête Location hostile est ainsi revérifié plutôt que suivi de confiance.
Au-delà du correctif, durcissez l’environnement dans lequel tourne l’interface. Sur AWS, exigez IMDSv2 avec une limite de saut à un afin qu’un SSRF basique ne puisse lire les identifiants d’instance ; les autres grands clouds offrent des contrôles équivalents de durcissement des métadonnées. Restreignez le trafic sortant de la charge Open WebUI pour qu’elle ne puisse atteindre ni 169.254.169.254, ni les autres plages en lien local, ni les réseaux d’administration internes, quelle que soit la forme de la requête — idéalement via un proxy sortant qui bloque les destinations privées et en lien local. Si la mise à jour n’est pas immédiate, la version corrigée expose un contrôle WEB_FETCH_FILTER_LIST que vous pouvez configurer pour refuser les noms d’hôtes de métadonnées et les plages RFC 1918, et vous pouvez restreindre ou désactiver l’endpoint de récupération pour les niveaux d’utilisateurs non fiables au niveau du reverse proxy. Enfin, faites tourner tout identifiant d’instance qui aurait pu être exposé avant le correctif, et traitez l’accès authentifié comme un privilège : une inscription ouverte à tous transforme une faille « nécessite un compte » en faille ouverte.
Pour la détection, alertez sur les connexions sortantes du processus Open WebUI vers des adresses en lien local ou de métadonnées, et corrélez les requêtes vers l’endpoint de récupération avec les destinations sortantes qui suivent — une récupération vers une URL externe immédiatement suivie d’une réponse de métadonnées est la signature à surveiller. Les journaux d’audit cloud montreront l’usage d’identifiants de rôle d’instance peu après un appel de récupération suspect.
Statut
| Élément | Détail |
|---|---|
| Affecté | Open WebUI, toutes versions antérieures à 0.6.27 |
| Composant | endpoint de récupération web /api/v1/retrieval/process/web (RAG) |
| Corrigé dans | Open WebUI 0.6.27 (commit 02238d3) |
| Faiblesse | CWE-918, SSRF via l’en-tête Location de redirection |
| Impact | Divulgation d’information — confidentialité ; vecteur réseau, faibles privilèges requis |
| Gravité | CVSS 4.0 5.3 (moyenne) ; notation du site : medium |
| Référence | CVE-2026-56399 (publié le 2026-06-30) ; avis GHSA-82r6-c5jm-f3mw |
Sources
- → https://nvd.nist.gov/vuln/detail/CVE-2026-56399
- → https://github.com/open-webui/open-webui/security/advisories/GHSA-82r6-c5jm-f3mw
- → https://www.vulncheck.com/advisories/open-webui-server-side-request-forgery-via-location-redirect-in-api-v1-retrieval-process-web
- → https://github.com/open-webui/open-webui/commit/02238d3113e966c353fce18f1b65117380896774