Sicherheit selbst gehosteter LLMs: On-Premise bedeutet nicht automatisch sicher

Unternehmen verlagern KI-Workloads aus guten Gründen ins eigene Rechenzentrum (on-premise): Datenresidenz, Einhaltung von DSGVO und SOC 2 sowie Kostenkontrolle im großen Maßstab. Der Betrieb eines Open-Weight-Modells innerhalb der eigenen Infrastruktur bedeutet, dass Prompts und feinabgestimmte Gewichte diese Infrastruktur niemals verlassen. Doch hinter dieser Entscheidung verbirgt sich eine gefährliche Annahme: „Es läuft auf unseren eigenen Servern, also ist es sicher." Das stimmt nicht. Self-Hosting eliminiert ein Risiko — dass Dritte Einblick in Ihre Daten erhalten — und überträgt Ihnen die volle Verantwortung für alles, was ein Managed-API-Anbieter bislang stillschweigend übernommen hat: Endpoint-Sicherheit, Artefaktverifizierung, Isolation und Patching. Hier ist die reale Angriffsfläche.

175.000 offen zugängliche Inferenz-Server

Im September 2025 entdeckte Cisco Talos über 1.100 Ollama-Instanzen im öffentlichen Internet ohne jegliche Authentifizierung. Anfang 2026 zählten Scans von SentinelLABS und Censys rund 175.000 öffentlich erreichbare Ollama-Hosts in 130 Ländern, dazu ungeschützte vLLM- und LiteLLM-Endpunkte. Die Ursache: Beliebte Self-Hosting-Tools wurden auf Entwicklerkomfort hin ausgelegt. Die REST-API von Ollama bringt überhaupt keine integrierte Authentifizierung mit. Ein einziges Binding auf 0.0.0.0 oder eine zu permissive Cloud-Security-Group genügt, und die gesamte API steht offen. Angreifer scannen aktiv danach — dokumentierte „LLMjacking"-Operationen finden offene Instanzen und verkaufen den Zugang auf Untergrundmarktplätzen weiter. Ein offener Endpunkt verschafft einem Angreifer kostenlose GPU-Rechenleistung, die Möglichkeit, Ihre feinabgestimmten Modelle abzuziehen (die Ihre Daten sind), Einblick in Systemprompts und RAG-Konfigurationen sowie einen Netzwerk-Brückenkopf innerhalb Ihrer Infrastruktur.

CVEs im Inferenz-Stack

Die Serving-Schicht ist junge Software, die primär auf Performance ausgelegt wurde. Die bisherige Bilanz:

• Probllama (2024) — Remotecodeausführung (RCE) in Ollama
• CVE-2025-47277 — Die verteilte Inferenzschicht von vLLM rief pickle.loads() auf Daten aus einem Netzwerk-Socket auf: ein Lehrbuchbeispiel für RCE
• Bleeding Llama, CVE-2026-7482 — Drei nicht authentifizierte API-Aufrufe legten Systemprompts, Sessions, API-Schlüssel und Datenbank-Zugangsdaten aus Ollama offen. Der Patch existierte monatelang, bevor die CVE zugewiesen wurde — Scanner und Compliance-Tools waren die ganze Zeit blind dafür

Die Lehre daraus: Ein Inferenz-Server ist ein produktiver Netzwerkdienst und braucht dieselbe Patch-Disziplin wie Ihre Datenbank. Verfolgen Sie Upstream-Releases direkt — sich allein auf CVE-Feeds zu verlassen, wird Sie im Stich lassen. Es gibt zudem ein Risiko, das für KI ganz spezifisch ist: Serving-Engines fassen Anfragen in gemeinsam genutzten GPU-Speicherpools und KV-Caches zusammen. Ein kompromittierter Prozess kann Fragmente der Konversationen anderer Nutzer preisgeben, und privilegierte GPU-Treiber bringen einen kompromittierten Container nur einen Schritt vom Host entfernt.

Modellgewichte sind ausführbare Artefakte

Teams wenden Supply-Chain-Sicherheit auf Code an, laden Modellgewichte aus öffentlichen Hubs jedoch ohne jede Verifizierung herunter. Zwei Ausfallmuster: Bösartige Serialisierung. Pickle-basierte Modellformate können beim Laden beliebigen Code ausführen. Im Jahr 2026 gibt es keinen Grund, in der Produktion etwas anderes als safetensors zu laden. Modellvergiftung. Gewichte, die in Benchmarks unauffällig abschneiden, aber so feinabgestimmt wurden, dass sie unter bestimmten Bedingungen Daten preisgeben oder versteckten Anweisungen folgen. Kein Absturz, kein Logeintrag. Die Lösung ist klassische Supply-Chain-Hygiene: ausschließlich vertrauenswürdige Quellen, Artefakte an verifizierte Hashes gebunden, Modellsignaturen, wo verfügbar, und intern feinabgestimmte Modelle, die wie das wertvollste geistige Eigentum des Unternehmens behandelt werden.

Prompt Injection ist es egal, wo das Modell läuft

Bösartige Anweisungen, die in Dokumenten, E-Mails oder Webseiten eingebettet sind, wirken bei selbst gehosteten und Cloud-Modellen identisch. Self-Hosting macht die Sache oft sogar schlimmer: Open-Weight-Modelle verfügen über ein schwächeres Sicherheitstraining, Teams deaktivieren Schutzmechanismen, „weil es ja nur intern ist", und das On-Premise-Modell hat in der Regel deutlich privilegierteren Zugriff — auf Datenbanken, interne APIs, Dateisystem-Tools — als es ein Cloud-Modell je hätte. Der OWASP Top 10 für LLM-Anwendungen ist das richtige Framework. Das Wesentliche: Tool-Zugriff nach dem Least-Privilege-Prinzip, Modellausgaben als nicht vertrauenswürdige Eingaben behandeln, Codeausführung in einer Sandbox und Egress-Filterung an den Inferenz-Workern.

Hardening-Baseline

Die Mindestanforderung für den Produktivbetrieb:

• Netzwerk: Bindung an localhost oder private Subnetze; jeglicher Zugriff ausschließlich über einen authentifizierten Reverse-Proxy oder ein LLM-Gateway; standardmäßige Egress-Filterung
• Plattform: Nicht-Root-Container, minimale Capabilities, Patching, das Upstream-Releases nachverfolgt
• Artefakte: ausschließlich safetensors, an Hashes gebunden, Speicher mit Zugriffskontrolle für feinabgestimmte Gewichte
• Anwendung: Review nach OWASP LLM Top 10, Ausgabevalidierung, vollständiges Inferenz-Logging in Ihr SIEM

Nichts davon ist exotisch — es ist dieselbe Disziplin, die Sie bereits auf Datenbanken anwenden, erweitert auf einen neuen Workload, den die meisten Teams derzeit mit der Sicherheitshaltung eines Wochenend-Hobbyprojekts betreiben.

Fazit

„On-Premise" ist eine Eigenschaft der Datenresidenz, keine Sicherheitseigenschaft. Die 175.000 offen zugänglichen Inferenz-Server sind kein Tooling-Versagen — sie sind ein Versagen der Denkweise: KI-Infrastruktur, die wie eine Desktop-Anwendung ausgerollt wird, obwohl sie wie eine produktive Datenbank behandelt werden müsste. Bei NextVector bauen wir Backend- und Blockchain-Infrastruktur, bei der Sicherheit ein Designkriterium ist und kein nachträglicher Gedanke — und dieselbe Disziplin gilt unmittelbar auch für KI. Planen Sie eine On-Premise-KI-Bereitstellung? Kontaktieren Sie uns.