Bug in Open WebUI macht Kostenlos-Tool zur Backdoor

Sicherheitsforschende von Cato Networks haben eine Schwachstelle in Open WebUI, einem selbstgehosteten Enterprise Interface für Large Language Models (LLM), entdeckt. Diese soll es externen Modell-Servern, die über das Feature „Direct Connections“ eingebunden sind, ermöglichen, Schadcode einzuschleusen und KI-Workloads zu übernehmen.

Das Problem, gekennzeichnet als CVE-2025-64496, beruht auf dem unsicheren Handling von Server-Sent Events (SSE). Dadurch können Benutzerkonten übernommen und in einigen Fällen – bei erweiterten Berechtigungen – auch per Remote Code Execution (RCE) auf Backend-Servern ausgeführt werden.

Laut den Experten kann das Frontend dazu verleitet werden, unbemerkt eingeschleustes JavaScript auszuführen. Hierfür muss ein Mitarbeitender Open WebUI mit einem von den Angreifenden kontrollierten Modell-Endpoint verbinden, beispielsweise unter dem Vorwand einer „kostenlosen GPT-4-Alternative“.

Dieser Code stiehlt dann JSON Web Tokens (JWTs) aus dem Browser-Kontext und soll den Kriminellen so dauerhaften Zugriff auf den KI-Arbeitsbereich, Dokumente, Chats und eingebettete API-Schlüssel des Opfers ermöglichen.

Der Fehler betrifft Open WebUI-Versionen bis einschließlich 0.6.34 und wurde in Version 0.6.35 behoben. Unternehmen sollten daher ihre Produktionsumgebungen umgehend patchen.

Krise statt Komfort

Laut den Cato-Forschenden liegt das Problem bei Direct Connections, einer Funktion, die es Usern ermöglicht, Open WebUI mit externen, OpenAI-kompatiblen Modell-Servern zu verbinden. Der SSE-Handler der Plattform vertraut eingehenden Events dieser Server, insbesondere solchen mit dem Tag „{type: execute}“. Deren Payload führt er dann über einen dynamischen JavaScript-Konstruktor aus.

Wenn sich ein User mit einem bösartigen Server verbindet, was durch Social Engineering leicht möglich ist, kann dieser Server eine SSE mit ausführbarem JavaScript senden. Dieses Skript hat vollen Zugriff auf den Speicher des Browsers, einschließlich des JWT, welches zur Authentifizierung verwendeten wird.

„Open WebUI speichert das JWT-Token im localStorage“, so die Experten von Cato in einem Blogbeitrag. „Jedes auf der Seite ausgeführte Skript kann darauf zugreifen. Tokens sind standardmäßig langlebig, haben kein HttpOnly-Attribut und sind Tab-übergreifend. In Kombination mit dem Execute-Event bietet dies ein Zeitfenster für die Kontoübernahme.“

Laut einer Beschreibung der National Vulnerability Database (NVD) erfordert der Angriff jedoch, dass das Opfer Direct Connections aktiviert, die standardmäßig deaktiviert sind, und die schädliche Modell-URL des Angreifers hinzufügt.

Eskalation bis hin zur Remote-Code-Ausführung

Das Risiko endet jedoch nicht mit der Kontoübernahme: Sollte das kompromittierte Konto über Berechtigungen für Workspace Tools verfügen, können Angreifende dieses Session-Token nutzen. Hiermit sind sie dann in der Lage, authentifizierten Python-Code über die Tools-API von Open WebUI einzuschleusen, der ohne Sandboxing oder Validierung ausgeführt wird.

Damit wird laut den Experten ein kompromittierter Browser zu einer vollständigen Remote Code-Execution auf dem Backend-Server. Sobald Angreifende Zugriff auf die Python-Ausführung erlangt haben, können sie

Persistenzmechanismen installieren,

in interne Netzwerke eindringen,

auf sensible Datenspeicher zugreifen, oder

laterale Attacken durchführen.

Die Schwachstelle erhielt vom NVD eine hohe Schweregradbewertung von 8/10 sowie 7,3/10 von GitHub. Dass sie dabei als hoch statt kritisch eingestuft wurde, hat zwei Gründe: Zum einen setzt der Exploit voraus, dass das Direct-Connections-Feature aktiviert wurde. Zum anderen muss ein User zunächst dazu verleitet werden, eine Verbindung mit einem manipulierten externen Modellserver herzustellen.

Der Fehler in Open WebUI v0.6.35 kann per Patch-Mitigation behoben werden. Dabei werden „execute“-SSE-Events aus Direct Connections vollständig blockiert. Organisationen, die noch ältere Versionen verwenden, sind jedoch weiterhin gefährdet.

Die Forschenden empfehlen zusätzlich, die Authentifizierung auf kurzlebige und rotierbare HttpOnly-Cookies umzustellen: „Kombinieren Sie dies mit einer strengen CSP und verbieten Sie die dynamische Codeauswertung“. (tf)