Viele Unternehmen entwickeln interne Chatbots, RAG-Anwendungen und agentische Workflows nicht mehr als Einzelprojekte. Sie bauen sie auf Plattformen. Das ist nachvollziehbar: Ein LLMOps- oder Agenten-Framework nimmt Teams Arbeit bei Authentifizierung, Hosting, Plugin-Anbindung, Dokumentenverarbeitung, Tracing und Betrieb ab.
Genau dort entsteht aber ein neues Risiko. Wenn eine solche Plattform mandantenfähig läuft, wird nicht nur die eigentliche Anwendung sicherheitskritisch. Kritisch wird jede Grenze zwischen App, Workspace, Tenant, Plugin-Dienst, Dateiablage und Observability-Funktion.
Die am 22. Juni veröffentlichte DifyTap-Analyse von Zafran Security ist deshalb für AIFence relevant. Sie beschreibt vier Schwachstellen in Dify, einer verbreiteten Open-Source-Plattform für LLMOps, Chatbots und agentische Workflows. The Hacker News griff den Bericht ebenfalls auf. Entscheidend ist nicht „noch eine Web-App-Lücke“. Entscheidend ist die Risikoklasse: In AI-Plattformen können Chatverläufe, Modellantworten, hochgeladene Dateien und Trace-Daten besonders sensibel sein. Sie enthalten häufig Geschäftsprozesse, Kundendaten, Quelltext, interne Dokumente oder operative Anweisungen.
Was technisch passiert ist
Zafran bündelt die vier Schwachstellen unter dem Namen „DifyTap“. Nach Angaben der Forscher betrafen drei der vier Lücken die Mandantentrennung im Multi-Tenant-Betrieb. Zwei wurden als kritisch bewertet, zwei erforderten keine vorherige Authentifizierung. Dify ist ein Open-Source-LLMOps-System, das lokal oder als Cloud-Dienst betrieben werden kann. Die Plattform bietet unter anderem visuelle Workflows, RAG-Pipelines, App-Tracing und ein Plugin-System.
Die zentrale Schwachstelle ist CVE-2026-41947. Laut NVD und Zafran handelt es sich um einen Authorization Bypass vor Version 1.14.2. Authentifizierte Editor-Nutzer konnten Trace-Konfigurationen für Anwendungen setzen und aktivieren, ohne dass Dify die Tenant-Zugehörigkeit ausreichend prüfte. In der Praxis hieß das: Nachrichten und Modellantworten einer betroffenen Anwendung konnten an einen vom Angreifer kontrollierten LLM-Trace-Provider umgeleitet werden. Das ist besonders heikel, weil Tracing in AI-Systemen oft bewusst vollständige Prompts, Antworten, Metadaten und Fehlerkontext sammelt.
CVE-2026-41948 betrifft den Plugin Daemon. NVD beschreibt eine Path-Traversal-Schwachstelle in Dify 1.14.1 und älter. Authentifizierte Nutzer konnten damit Anfragen an interne REST-API-Endpunkte manipulieren. Zafran wertet das als architektonisches Problem: Externe Requests konnten in Richtung interner Plugin-Daemon-APIs verschoben werden. Für Unternehmen ist weniger der konkrete Pfad entscheidend als das Muster dahinter. Plugin-Dienste in AI-Plattformen sind oft besonders mächtig, weil sie Tools, externe APIs und Workflow-Aktionen verbinden.
Die beiden weiteren CVEs betreffen Dateien. CVE-2026-41949 ermöglichte laut NVD vor Version 1.14.2 das Lesen von bis zu 3.000 Zeichen eines hochgeladenen Dokuments über den File-Preview-Endpunkt, wenn eine Datei-UUID bekannt war. CVE-2026-41950 erlaubte vor Version 1.14.0 unter bestimmten Bedingungen das Lesen vollständiger Dateien anderer Nutzer innerhalb desselben Tenants. Dafür musste eine fremde Datei-UUID in einer Chat-Messages-Anfrage verwendet werden. Das klingt nach einem Detailproblem. In RAG- und Agenten-Umgebungen ist es zentral: Hochgeladene PDFs, Tabellen, Screenshots oder Exportdateien sind häufig genau die Datenbasis, mit der das Modell arbeitet.
Zahlen und Quellenlage
Die Primärquelle ist der Zafran-Bericht „DifyTap: Zafran discovers how attackers can silently wiretap AI data across tenants on a platform powering 1M+ apps“ vom 22. Juni 2026. Zafran nennt über 140.000 GitHub-Stars, mehr als 10 Millionen Docker-Pulls des API-Images, Einsätze in mehr als 60 Branchen und „tens of thousands“ öffentlich erreichbare Dify-Instanzen. The Hacker News bestätigte am selben Tag die Kernaussagen und verweist zusätzlich auf mehr als 146.000 GitHub-Stars. Für die formalen CVE-Details sind die NVD-Einträge zu CVE-2026-41947 bis CVE-2026-41950 relevant. Dort finden sich Beschreibungen, CVSS-Werte und betroffene Versionen.
Auch der Patch-Stand ist wichtig. Drei der vier von Zafran hervorgehobenen Schwachstellen – CVE-2026-41947, CVE-2026-41949 und CVE-2026-41950 – sind laut Zafran in Dify 1.14.2 beziehungsweise 1.14.0/1.14.2 adressiert. Zu CVE-2026-41948 schreibt Zafran, dass ein Fix bereits auf GitHub gemerged sei und mit dem nächsten Dify-Release ausgeliefert werden solle. Die Release-Notes zu Dify 1.14.2 nennen ausdrücklich „Tenant-scoped sensitive endpoints“ und eine stärkere Tenant-Isolation für Trace-Konfigurationen sowie FilePreview-Textextraktion.
Zafran weist außerdem darauf hin, dass die Dateiverarbeitung eine PDFium-Version nutzte, die für CVE-2024-5846 anfällig war, einen Use-after-free-Bug aus dem Chromium/PDFium-Umfeld. Das ist kein Dify-spezifischer Fehler in der Mandantentrennung. Der Punkt zeigt aber eine zweite Realität von AI-Plattformen: Dokumentenparser sind Angriffsfläche. Wer beliebige PDFs verarbeitet, betreibt nicht nur „KI“, sondern auch klassischen, potenziell riskanten Datei-Parsing-Code.
Warum das über Dify hinaus wichtig ist
DifyTap passt in einen größeren Trend. AI-Anwendungen laufen zunehmend als Plattformen mit vielen Nebenkomponenten: Vektor- und Dokumentenspeicher, Plugin-Daemons, Trace-Provider, Workflow-Engines, File-Preview-Dienste, OAuth-Integrationen und Admin-APIs. Klassische Schwachstellen wie Authorization Bypass, IDOR, Path Traversal oder SSRF verschwinden dadurch nicht. Sie treffen nur auf Daten, die im AI-Kontext besonders verdichtet und wertvoll sind.
Für Entscheider lautet die Lehre daher nicht, Dify pauschal zu meiden. Sinnvoller ist eine andere Konsequenz: AI-Plattformen gehören wie produktive Multi-Tenant-SaaS- und Automatisierungsumgebungen behandelt, nicht wie experimentelle Chatbot-Frontends. Wer Mandantenfähigkeit, Plugins und Tracing nutzt, braucht belastbare Tests auf Tenant-Isolation, Objektberechtigungen und interne Service-Grenzen. Ein grüner Container-Scan reicht dafür nicht. Viele Risiken liegen in der Anwendungslogik und im Zusammenspiel mehrerer Services.
Konkrete Implikationen für Unternehmen
Erstens sollten Dify-Betreiber ihre Version prüfen und mindestens auf die verfügbaren Sicherheitsupdates wechseln. Bei selbst gehosteten Instanzen ist vor allem relevant, ob 1.14.2 oder neuer läuft und wie mit dem noch ausstehenden Fix zu CVE-2026-41948 umgegangen wird. Bis zur vollständigen Behebung sollten Unternehmen die Erreichbarkeit des Plugin Daemon, interne Routen, Netzwerksegmente und Authentifizierungsgrenzen überprüfen.
Zweitens sollte Tracing als potenzieller Datenabflusskanal gelten. Trace-Provider dürfen nicht nur aus Observability-Sicht bewertet werden, sondern auch aus Data-Loss-Perspektive. Welche Prompts, Antworten, Dateien, Tool-Outputs und Metadaten werden übertragen? Wer darf Trace-Konfigurationen ändern? Gibt es Vier-Augen-Freigabe oder zumindest Audit-Logging für Änderungen an Trace-Zielen?
Drittens gehören Datei-UUIDs, Conversation-IDs und App-IDs nicht in die Kategorie „harmlose technische Bezeichner“. In vielen IDOR-Fällen reicht genau ein solcher Identifier aus, wenn die serverseitige Ownership-Prüfung fehlt. Security-Tests für AI-Plattformen sollten deshalb systematisch prüfen, ob Nutzer oder Tenants Objekte anderer Workspaces lesen, löschen, referenzieren oder in Workflows einschleusen können.
Viertens sollten RAG- und Dokumentenpipelines isoliert laufen. Parser für PDF, Office-Dokumente und Bilder brauchen Sandboxing, Dateigrößen- und Typbegrenzungen, regelmäßige Dependency-Pflege und klare Egress-Regeln. Das gilt besonders, wenn Endnutzer eigene Dokumente hochladen dürfen.
Risiken und Limitierungen
Die öffentliche Berichterstattung belegt Schwachstellen und Patches, aber keine breitflächige Ausnutzung in freier Wildbahn. Unternehmen sollten den Fall daher nicht dramatisieren, sondern priorisieren. Das reale Risiko hängt stark vom Betriebsmodell ab: Cloud-Dienst, selbst gehostete Instanz, öffentlich erreichbare App, interne Nutzung, aktivierte Plugins, Rolle von Tracing und Art der verarbeiteten Daten.
Gleichzeitig wäre es fahrlässig, DifyTap als Einzelfall abzutun. Die betroffenen Fehlerklassen sind bekannt, aber ihr Kontext verändert sich. Wenn ein AI-Workflow Kundendokumente, interne Tickets, Quellcode und Modellantworten verbindet, kann ein scheinbar begrenzter Authorization-Bug schnell zu einem weitreichenden Informationsabfluss werden.
Fazit
DifyTap zeigt, wo AI-Security im Unternehmensalltag tatsächlich ankommt: nicht nur bei Prompts und Modellverhalten, sondern bei Mandantentrennung, Tool-Architektur, Dateiverarbeitung und Observability. Unternehmen, die LLMOps- und Agentenplattformen produktiv einsetzen, sollten sie wie kritische Applikationsinfrastruktur behandeln.
Die Reihenfolge ist praktisch klar: patchen, Internet-Exposition prüfen, Trace- und Plugin-Rechte begrenzen, Datei-Pipelines härten und Tenant-Isolation aktiv testen. Wer diese Grundlagen ernst nimmt, kann AI-Plattformen nutzen, ohne aus jedem Chatbot einen unkontrollierten Datenabflusskanal zu machen.
Quellen: Zafran Security, „DifyTap: Zafran discovers how attackers can silently wiretap AI data across tenants on a platform powering 1M+ apps“, 22. Juni 2026; The Hacker News, „Researchers Detail DifyTap Flaws in Dify That Could Expose AI Chats Across Tenants“, 22. Juni 2026; NVD-Einträge zu CVE-2026-41947, CVE-2026-41948, CVE-2026-41949, CVE-2026-41950 und CVE-2024-5846; Dify GitHub Release Notes v1.14.2.
