Kann jede Website deine lokale KI fernsteuern? Vier Server im Standard-Check

Darum geht es

Auf Reddit hat ein Nutzer gerade etwas bemerkt, das viele überrascht: Läuft auf dem eigenen Rechner ein KI-Server wie llama.cpp oder vLLM, kann eine beliebige Website in einem anderen Browser-Tab Anfragen an ihn schicken. Je nach Server liest sie die Antwort sogar mit. Der Einwand „der Server lauscht doch nur auf 127.0.0.1“ hilft nicht, schreibt der Nutzer, denn der Browser läuft auf demselben Rechner. Technisch sei das nichts Neues, sondern 20 Jahre alte Web-Angriffstechnik: CSRF (eine fremde Seite löst im Namen des Nutzers Anfragen aus) und DNS-Rebinding (eine Domain zeigt nach dem Laden der Seite plötzlich auf 127.0.0.1).

Neu ist, was hinter dem Port steckt. llama.cpp hat inzwischen eingebaute Werkzeuge, die Dateien lesen und Befehle ausführen. Open WebUI 0.13 lässt Modelle einen Desktop bedienen, und Version 0.13.1 bietet Coding-Agenten wie Claude Code direkt als Modelle an. Ein offener localhost-Port verschenkt damit nicht mehr nur Rechenzeit, sondern kann zum Einfallstor werden.

Wir haben deshalb nachgeprüft, wie offen die vier wichtigsten lokalen Server ab Werk sind und was die Browser dagegen tun. Wichtig vorab: Unsere Angaben stammen aus Dokumentation, Quellcode, Sicherheitshinweisen und Tests Dritter. Einen eigenen Browser-Test haben wir nicht durchgeführt.

Kurz erklärt: Was CORS schützt und was nicht

CORS (Cross-Origin Resource Sharing) ist eine Absprache zwischen Server und Browser. Der Server teilt mit, welche fremden Websites („Origins“, also Herkünfte wie https://beispiel.de) seine Antworten lesen dürfen. Zwei Punkte werden oft übersehen:

1. CORS regelt das Lesen der Antwort, nicht das Senden der Anfrage. Der Sicherheitsforscher g3tsyst3m formuliert es so: CORS bestimmt, ob die Seite die Antwort lesen kann, es verhindert nicht, dass die Anfrage den Server erreicht. Auch der Autor des vLLM-Fixes schreibt, dass CORS nicht alle einfachen Anfragen von fremden Seiten blockiert und kein Ersatz für Authentifizierung ist.
2. Code, der schon auf der „erlaubten“ Herkunft läuft, etwa eine Browser-Erweiterung oder ein Lesezeichen-Skript auf localhost, umgeht CORS vollständig.

Gegen beides hilft nur ein API-Schlüssel, also ein Passwort, das jede Anfrage mitschicken muss.

Die vier Server ab Werk

llama-server ist am offensten. Die README sagt wörtlich, der Server spiegle jeden Origin-Header zurück und erlaube Credentials. Das sei nur vertretbar, solange er zustandslose, nur lesende Endpunkte anbietet. Die Optionen --cors-origins und --api-key kamen erst im Juli 2026 dazu (Pull Request #25655). Den offenen Standard behielt das Projekt, um nichts kaputt zu machen. Beim Start erscheint eine Warnung („CORS is set to allow all origins ('*') and no API key is set“). Wie verbreitet das Problem ist, zeigt der Agent atomic-agent: Er startete llama-server Ende September ohne Schlüssel und mit offenem CORS und hat das erst nach einem Bug-Report geändert. Mit --tools oder --agent begrenzt llama-server CORS automatisch auf localhost, denn dann lassen sich über die API Dateien lesen und schreiben. Die Werkzeuge laufen standardmäßig direkt auf dem Rechner (--tools-runtime: „none, use host environment“).

g3tsyst3m hat beides im eigenen Labor vorgeführt, mit Qwen3.8-27B auf einer Radeon 7900 XTX. Ohne Tools konnte eine beliebige HTML-Seite Prompts schicken und die Antworten lesen. Mit --tools all blockte der Server fremde Seiten. Ein Lesezeichen-Skript, das man im offenen Tab der llama-Weboberfläche anklickt, ließ das Modell aber einen Systembefehl ausführen, ohne Rückfrage. Weil der Server per sudo lief, hätten die Werkzeuge Root-Rechte gehabt.

vLLM hatte bis Version 0.31 den Standard allowed_origins = ["*"]. Laut dem Advisory GHSA-vvpg-rrww-wpmh (CVE-2026-115917) konnte jede Website, die der Browser des Opfers erreicht, Modelle auflisten, Antworten erzeugen lassen, also GPU-Zeit verbrauchen, und die Ausgabe mitlesen. Behoben ist das in 0.32.0 mit einer leeren Liste. Die Schwere ist mit CVSS 3.4 niedrig, weil Cookies nicht mitgeschickt werden. Eine Fußnote aus der aktuellen Doku: --api-key schützt nur die Pfade /v1, /v2, /inference und /cohere. /invocations bietet dieselben Funktionen und bleibt ohne Schlüssel erreichbar.

Ollama ist am besten abgesichert, zumindest im Auslieferungszustand. Laut Quellcode stehen nur localhost-Herkünfte und einige App-Schemata auf der Liste. Fremde Herkünfte bekommen laut einer Analyse von localaimaster.com einen 403-Fehler, auch bei einfachen POST-Anfragen. Ein zweiter Filter prüft den Host-Header gegen DNS-Rebinding. Diesen Schutz gibt es seit Version 0.1.29 (März 2024), nachdem NCC Group gezeigt hatte, wie eine präparierte Website über DNS-Rebinding lokale Dateien abziehen konnte (CVE-2024-28224). Zwei Haken: Die Host-Prüfung läuft nur, wenn Ollama auf einer Loopback-Adresse lauscht. Und file://* ist standardmäßig erlaubt, eine heruntergeladene HTML-Datei kann Ollama also ansprechen.

LM Studio hat CORS laut Doku ausgeschaltet („When not set, CORS is disabled“). Wer es einschaltet, bekommt eine Warnung und die Empfehlung, Authentifizierung zu aktivieren. Die gibt es seit Version 0.4.0, ab Werk ist sie aus. Ob ein „blinder“ Request von einer fremden Seite trotzdem eine Generierung auslöst, ohne dass die Antwort lesbar ist, dokumentiert LM Studio nicht. Das bleibt offen.

Die zweite Hälfte: Was die Browser tun

Seit 2025 fragen Chrome und Firefox nach, bevor eine öffentliche Website Geräte im Heimnetz oder Dienste auf dem eigenen Rechner erreicht. Das Verfahren heißt Local Network Access (LNA).

Für Firefox wurde die Sperre für unverschlüsselte Seiten wieder gelockert. Nach Problemen mit Router-Oberflächen gilt laut Bugzilla 2059274 vorerst „Allow LNA from insecure pages“. Solche Seiten bekommen also wieder eine Nachfrage statt einer Blockade. Einen Bug-Report zu WebSocket-Angriffen auf localhost schloss Mozilla mit dem Hinweis, die LNA-Schutzmaßnahmen deckten das bereits ab.

Bei Safari ist die Lage dünn. WebKit hat im Oktober 2026 den LNA-Prüfalgorithmus eingebaut, schaltet ihn aber bisher nur für Tests ein (Pull Request #75708). Ob er in einer Safari-Version ab Werk aktiv ist, haben wir nicht belegen können. Ein Entwickler im Apple-Forum berichtete im Januar 2026, Chrome frage nach, Safari zeige keine Abfrage. Belegt ist nur: Seit Safari 18 und macOS Sequoia blockiert Apple die Adresse 0.0.0.0. Nach einem älteren WebKit-Kommentar (2021) gelten Anfragen von HTTPS-Seiten an http://127.0.0.1 als „Mixed Content“, also unzulässig gemischte verschlüsselte und unverschlüsselte Inhalte, und werden blockiert. Von HTTP-Seiten gingen sie damals durch. Ob das heute noch gilt, ist offen.

Die Matrix: Was eine fremde Website wirklich kann

Unsere Einschätzung: Die Browser-Abfrage ist ein guter Schutz, solange niemand auf „Erlauben“ klickt. Eine Seite kann aber einen Vorwand liefern („Verbinde dich mit deiner lokalen KI“). Einmal erteilt, merkt sich der Browser die Erlaubnis. Erweiterungen, lokal geöffnete HTML-Dateien und andere Programme auf dem Rechner unterliegen dieser Abfrage gar nicht. Der Reddit-Autor weist außerdem darauf hin, dass auch ein KI-Agent, der für dich einen echten Browser steuert, solche Anfragen auslösen kann. Wie LNA sich bei automatisierten Browsern verhält, ist nicht dokumentiert.

Die richtigen Einstellungen für jeden Server

• llama-server: --api-key-file datei (oder --api-key) setzen und --cors-origins localhost oder die genaue Adresse der eigenen Oberfläche angeben. --host bleibt bei 127.0.0.1. --tools und --agent nur einschalten, wenn du sie brauchst, dann mit --tools-runtime in einer getrennten Umgebung und nie als root.
• vLLM: Auf mindestens 0.32.0 aktualisieren und --host 127.0.0.1 ausdrücklich setzen, weil die Doku keinen Standard nennt. Dazu --api-key (oder VLLM_API_KEY) und nur konkrete Einträge bei --allowed-origins. Beachte, dass /invocations ohne Schlüssel erreichbar bleibt.
• Ollama: Die Standards lassen. Nie OLLAMA_ORIGINS="*" setzen, wie manche Anleitungen für Browser-Erweiterungen raten, sondern nur gezielte Einträge wie chrome-extension://<ID>. Wer OLLAMA_HOST=0.0.0.0 braucht, etwa für Docker, verliert die Host-Prüfung und sollte eine Firewall davorsetzen.
• LM Studio: CORS ausgeschaltet lassen. Wer es braucht, aktiviert vorher unter Developer → Server Settings „Require Authentication“ und vergibt Tokens mit möglichst wenigen Rechten. MCP-Aufrufe über die API nur freigeben, wenn sie gebraucht werden.
• Browser: Chrome, Edge und Firefox aktuell halten. Abfragen wie „Apps und Dienste auf diesem Gerät“ ablehnen, wenn du nicht genau weißt, warum die Seite das will, und alte Freigaben in den Website-Einstellungen prüfen. Wer Safari nutzt, sollte sich nicht auf den Browser verlassen und den Server selbst absichern.

Unser Fazit

Die Reddit-Entdeckung ist alt, aber aktueller denn je. Ab Werk sicher ist von den vier Servern nur Ollama, LM Studio ist es weitgehend. vLLM hat seinen offenen Standard erst im Oktober 2026 geschlossen. llama-server ist absichtlich offen geblieben und verlässt sich auf eine Warnzeile beim Start. Solange nur Text generiert wird, geht es vor allem um gestohlene Rechenzeit und mitgelesene Antworten. Mit Werkzeugen, MCP und Agenten, die Dateien schreiben und Befehle ausführen, steht dagegen der ganze Rechner auf dem Spiel. Chrome und Firefox haben das Problem seit 2026 weitgehend entschärft, Safari bleibt eine Lücke im Bild.

Unsere Einschätzung: Für alles, was auf localhost lauscht und mehr kann als Text ausgeben, ist ein API-Schlüssel Pflicht, denn er wirkt unabhängig vom Browser. Offen bleibt, wie sich Safari konkret verhält und ob LM Studio und vLLM auf „blinde“ Anfragen reagieren. Das ließe sich nur mit einer eigenen Testseite klären, die wir noch nicht gebaut haben.