36.769 KI-Dienste im öffentlichen Internet erreichbar

Öffentliche Erreichbarkeit zieht sich durch die gesamte KI-Lieferkette

Eine am 11. September veröffentlichte Studie identifizierte 36.769 öffentlich erreichbare KI-Endpunkte – von lokalen Modellservern über Automatisierungsplattformen bis hin zu Vektorspeicher-Konsolen.

Forscher von Mysterium VPN fanden die Systeme, indem sie den Internet-Scan-Index von Netlas abfragten und dienstspezifische Fingerprints abglichen. Nur 2,02 % der identifizierten Endpunkte antworteten mit HTTP 401 oder 403 – Statuscodes, die als Hinweis auf eine Authentifizierungsschranke dienen.

Das bedeutet nicht, dass alle übrigen Dienste uneingeschränkten Zugriff erlaubten. Anmeldeseiten können mit HTTP 200 antworten, während die Authentifizierung an anderer Stelle in einer Anwendung durchgesetzt wird. Die Zahl zeigt vielmehr, dass bei den meisten Deployments am gescannten Endpunkt keine auf Netzwerkebene erkennbare Zugriffshürde vorhanden war.

Die Untersuchung erfasste die beobachtbare Exponierung, nicht erfolgreiche Eindringversuche. Die Forscher riefen weder Dokumente ab, untersuchten Chatverläufe, lasen Zugangsdaten aus, führten Modelle aus noch nutzten sie Schwachstellen aus. Hostnamen und IP-Adressen wurden ebenfalls nicht veröffentlicht.

Bei der Gesamtzahl handelt es sich zudem um eine Untergrenze. Internet-Scan-Indizes erfassen nicht jeden Port und jeden Host, und strenge Fingerprints schließen Systeme aus, die sich keinem bestimmten Produkt mit ausreichender Sicherheit zuordnen lassen.

Dennoch zeigt die Verteilung, wie selbst gehostete KI-Infrastruktur mehrere unterschiedliche Ressourcen offenlegen kann: GPU-Kapazität, Zugangsdaten für Workflows, Verbindungen zu Geschäftssystemen und die privaten Daten, die für Retrieval-Augmented Generation verwendet werden.

Modellserver stellen den größten Anteil der exponierten Systeme

Open WebUI war mit 18.529 erreichbaren Instanzen die größte Produktgruppe im Datensatz. Nur eine davon antwortete mit einer HTTP-Authentifizierungsaufforderung.

Die Forscher identifizierten außerdem:

• 4.880 vLLM-Endpunkte, von denen drei mit einer Authentifizierungsaufforderung antworteten;
• 150 LocalAI-Endpunkte, von denen keiner mit einer solchen Aufforderung antwortete;
• 69 llama.cpp-Endpunkte, von denen keiner mit einer solchen Aufforderung antwortete.

Aus diesen Zahlen lässt sich nicht ableiten, dass jede Installation anonym nutzbar war. Eine Open-WebUI-Anmeldeschnittstelle kann beispielsweise mit HTTP 200 antworten und dennoch Zugangsdaten verlangen, bevor Unterhaltungen oder Modellfunktionen offengelegt werden.

Bei Ollama war die Beweislage eindeutiger, da der Root-Endpunkt ohne Authentifizierungsabfrage den erkennbaren Text Ollama is running ausgibt. Mysterium fand 6.935 Hosts mit diesem Fingerprint, darunter 6.046, die ausdrücklich mit HTTP 200 antworteten.

Eine exponierte Ollama-API kann installierte Modelle offenlegen und externen Nutzern ermöglichen, Inferenzanfragen über die Hardware des Betreibers zu stellen. Angreifer können dadurch GPU-Zeit und Strom verbrauchen, ohne den Host im herkömmlichen Sinne zu kompromittieren.

Dieser Ressourcenmissbrauch wird häufig als LLMjacking bezeichnet. Er kann Kosten verursachen, den Dienst für legitime Nutzer beeinträchtigen und die Infrastruktur des Betreibers mit Inhalten verknüpfen, die von einem unbekannten Dritten erzeugt wurden.

Eine separate, im Januar veröffentlichte Studie von SentinelOne und Censys zählte rund 175.000 exponierte Ollama-Hosts in 130 Ländern. Fast die Hälfte unterstützte Tool-Calling-Funktionen, mit denen sich Code ausführen, APIs aufrufen oder externe Systeme ansprechen ließen. Unterschiede beim Scanumfang und bei den Anforderungen an die Fingerprints erklären, warum diese Zahl deutlich höher ausfiel.

Darüber hinaus beobachtete Mysterium 22.024 Antworten auf Ollamas Standardport 11434. Diese Systeme wurden nicht in die primäre Zählung aufgenommen, weil ein Port allein keinen Nachweis dafür liefert, welche Anwendung dort lauscht. Von diesen Antworten stammten 4.136 beziehungsweise 18,8 % aus den Vereinigten Staaten.

Die Forscher versuchten, die Daten nach Ländern aufzuschlüsseln, verwarfen diese Auswertung jedoch, nachdem Ratenbegrenzungen die Ergebnisse für mehrere wichtige Länder unzuverlässig gemacht hatten.

Agentenplattformen können mehr als Rechenleistung offenlegen

Die Studie fand 5.223 öffentlich erreichbare Plattformen zum Erstellen von Agenten und Workflows. Zu den identifizierten Produkten gehörten Flowise, n8n, ComfyUI, Dify, RAGFlow, Langflow und Open WebUI Pipelines.

Diese Anwendungen können größere Sicherheitsauswirkungen haben als ein isolierter Inferenzserver. Ihr Zweck besteht darin, Modelle mit Daten und Aktionen zu verbinden. Dazu speichern oder referenzieren sie häufig OpenAI-API-Schlüssel, Datenbankzugangsdaten, Slack-Tokens, CRM-Passwörter und Webhook-Secrets.

Eine Workflow-Plattform kann außerdem berechtigt sein, Produktionsdatenbanken abzufragen, Kundendatensätze zu aktualisieren, auf Quellcode-Repositories zuzugreifen, Nachrichten zu versenden oder andere Automatisierungen auszulösen. Durch die Exponierung gelangen daher sowohl Geheimnisse als auch autorisierte Ausführungspfade in die Nähe eines Angreifers.

Mysterium identifizierte 1.341 erreichbare Flowise-Instanzen. Keine davon antwortete mit einer Authentifizierungsaufforderung gemäß 401 oder 403, wobei diese Messung allein nicht belegt, dass keine Anmeldesteuerung auf Anwendungsebene vorhanden war.

Flowise birgt außerdem ein separates Softwarerisiko. CVE-2026-40933 ist eine kritische Schwachstelle im MCP-Adapter, über die ein authentifizierter Angreifer beliebige Befehle ausführen kann. Sie hat einen CVSS-Score von 9,9 und den Vektor CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H.

Das Problem wurde in Flowise 3.1.0 behoben. Administratoren sollten auf diese oder eine höhere Version aktualisieren.

Die Erreichbarkeit aus dem Internet belegt nicht, dass eines der erkannten Flowise-Systeme eine anfällige Version ausführt. Außerdem setzt die Schwachstelle weiterhin einen authentifizierten Zugriff voraus. Ein öffentlich erreichbares Deployment bietet Angreifern jedoch mehr Möglichkeiten, Zugangsdaten zu erlangen oder wiederzuverwenden und anschließend den Pfad zur Befehlsausführung anzugreifen.

Durchgesickerte Tokens machen eine Ausnutzung überflüssig

Die Risiken rund um n8n zeigen, warum sich Sicherheitsteams nicht ausschließlich auf Softwareschwachstellen konzentrieren dürfen.

In einer im August veröffentlichten Analyse untersuchten Forscher von GitGuardian n8n-API-Tokens, die in öffentlichen GitHub-Commits offengelegt worden waren. Sie identifizierten 4.576 eindeutige Tokens, die 1.255 Hostnamen zugeordnet waren.

Von diesen Hosts waren 896 während der Tests erreichbar. Mindestens ein durchgesickertes Token funktionierte bei 321 Instanzen.

In solchen Fällen benötigt der Angreifer keine Schwachstelle. Ein gültiges Token kann je nach Berechtigungen und Konfiguration der betroffenen Instanz direkten Zugriff auf Workflows und deren Integrationen ermöglichen.

Dadurch werden mit Produktionsumgebungen verbundene n8n- und Flowise-Deployments zu besonders wertvollen Zugangsdaten-Speichern. Ein über Quellcode offengelegtes Token kann als Einstiegspunkt dienen, während eine öffentlich zugängliche Steuerungsebene dem Angreifer einen Ort zur Verwendung des Tokens bietet.

Sicherheitsteams sollten Repositories und Commit-Verläufe prüfen, nicht nur die aktuelle Version eines Projekts. Das Entfernen eines Secrets aus der neuesten Revision macht Kopien in früheren Commits, Forks, Logs oder Caches nicht ungültig. Jeder Zugang, bei dem eine Offenlegung vermutet wird, muss gewechselt werden.

Vektorspeicher bergen ein eigenständiges Datenrisiko

Mysterium zählte 920 erreichbare Vektorspeicher-Endpunkte, bei denen es sich fast durchweg um Attu-Management-Konsolen für Milvus handelte. Diese Kategorie ist besonders unvollständig, da die Scanquelle die nativen Ports von Qdrant- und Milvus-Datenbanken nicht erfasste.

Eine Vektordatenbank kann daher öffentlich erreichbar sein, ohne in der Gesamtzahl aufzutauchen.

Diese Systeme speichern Embeddings und zugehörige Inhalte, die von KI-Anwendungen zum Abruf relevanter Informationen verwendet werden. Je nach Deployment können dazu interne Dokumente, Support-Tickets, Kundendatensätze, Betriebsanweisungen oder private Einträge aus Wissensdatenbanken gehören.

Eine exponierte Management-Konsole und eine exponierte native Datenbankschnittstelle stellen außerdem unterschiedliche Erkennungsprobleme dar. Sicherheitsteams, die nur herkömmliche Webports scannen, finden möglicherweise Attu, übersehen jedoch die zugrunde liegende Datenbank – oder umgekehrt.

Die Studie untersuchte keine Collections und rief keine Datensätze ab. Sie belegt daher nicht, dass Daten von einem der 920 Endpunkte aus zugänglich waren. Sie zeigt jedoch, dass Management-Oberflächen aus dem öffentlichen Internet sichtbar waren.

Sicherheitsteams sollten die Exponierung vor der Untersuchung einer Kompromittierung reduzieren

Organisationen sollten zunächst Modellserver, Agentenplattformen, Workflow-Engines, Vektordatenbanken und zugehörige Management-Konsolen inventarisieren. Cloud-Ressourcen und temporäre KI-Experimente verdienen besondere Aufmerksamkeit, da Dienste nach Tests weiterhin an 0.0.0.0 gebunden sein können.

Wenn eine öffentliche Verbindung nicht erforderlich ist, sollten Dienste ausschließlich auf localhost oder privaten Netzwerkschnittstellen lauschen. Systeme, die einen Fernzugriff benötigen, sollten durch Authentifizierung, Perimeter-Kontrollen, Segmentierung und Einschränkungen der zulässigen Quellnetzwerke geschützt werden.

Zu den prioritären Maßnahmen gehören:

• Flowise auf Version 3.1.0 oder höher aktualisieren.
• Quellcode-Repositories und Commit-Verläufe nach API-Schlüsseln, n8n-Tokens, Datenbankpasswörtern, Webhook-Secrets und anderen Zugangsdaten durchsuchen.
• Secrets wechseln, die möglicherweise über exponierte Workflows oder öffentliche Repositories offengelegt wurden.
• Nicht benötigtes Tool-Calling, die Codeausführung, den API-Zugriff und externe Integrationen einschränken.
• Attu-Konsolen schützen und separat nach nativen Milvus- und Qdrant-Schnittstellen suchen.
• Auf unerwartete Inferenzanfragen, GPU-Auslastung, Workflow-Änderungen, Token-Nutzung und Aktivitäten in verbundenen Systemen achten.
• Produkt-Fingerprints in Internet-Scan-Diensten verwenden, um Organisationsressourcen zu finden, die von außerhalb des Netzwerks sichtbar sind.

Die Studie bestätigte keine Kompromittierung. Ihre praktische Erkenntnis ist enger gefasst, aber dennoch folgenreich: Zehntausende eindeutig erkennbare KI-Komponenten sind aus dem Internet erreichbar, und bei vielen ist vor der Anwendung selbst keine erkennbare Zugriffsschranke vorhanden.