Ihr Localhost ist nicht privat: Entwicklerumgebungen gegen Localhost SSRF und DNS-Rebinding sichern

Die meisten Entwickler betrachten localhost als Vertrauensgrenze. Alles, was an 127.0.0.1 gebunden ist, wird nur von Ihnen erreichbar angenommen. Diese Annahme hat sich wiederholt als falsch erwiesen – in Browsern, KI-Tools, Entwicklungsservern und Container-Laufzeiten.

Dieser Artikel behandelt zwei verwandte Angriffsarten, wie sie Entwicklermaschinen treffen, die Änderungen bei Browsern der letzten zwei Jahre und was dagegen zu tun ist. Er zeigt auch, wo ein Tunneling-Tool wie InstaTunnel hilft und wo es keine Lösung bietet.

Zwei Angriffsarten, eine falsche Annahme

Localhost SSRF ist serverseitige Request Forgery, die auf Loopback abzielt. Eine Anwendung ruft eine URL ab, die der Angreifer kontrolliert (z.B. Webhook-Ziel, Bild-URL, Link-Vorschau), und der Angreifer weist sie an, 127.0.0.1, 0.0.0.0 oder eine interne Adresse zu verwenden. Der Server macht dann die Anfrage aus dem Vertrauensbereich heraus an Dienste, die niemals für externe Anfragen vorgesehen sind.

DNS-Rebinding funktioniert im Browser. Ein Opfer besucht eine Seite des Angreifers. Die Domain des Angreifers löst sich zuerst auf den Server des Angreifers auf, dann auf 127.0.0.1, sodass der Browser Requests weiterhin als gleiche Herkunft behandelt, während sie den lokalen Dienst des Opfers erreichen. Vites Sicherheitswarnung beschreibt diese Kette: Der Angreifer ändert die DNS-Antwort, um auf 127.0.0.1 oder eine andere private Adresse zu zeigen, und ein HTTP-Server, der die Host-Header nicht validiert, kann den Unterschied nicht erkennen.

Beide Angriffe basieren auf der gleichen falschen Annahme: Der Zugriff auf einen lokalen Port bedeutet, dass der Anrufer vertrauenswürdig ist.

Die 0.0.0.0 Day-Schwachstelle

Im August 2024 enthüllte Oligo Security den “0.0.0.0 Day”, eine Logikschwäche in der Handhabung von Anfragen an 0.0.0.0 in großen Browsern (Chromium, Firefox, Safari). Oligo hatte dies bereits im April 2024 den Browser-Herstellern gemeldet.

• Der Mechanismus. Private Network Access (PNA) sollte öffentliche Websites daran hindern, private Adressen zu erreichen. Aber 0.0.0.0 war nicht auf der Liste der privaten oder lokalen Bereiche, sodass Anfragen an diese Adresse durchrutschten.
• Wer betroffen war. Das Problem betraf macOS und Linux, nicht Windows. Oligo-Forscher sagte, öffentliche Seiten könnten jeden offenen Port auf dem Host erreichen, ohne die Antwort lesen zu können – die Gefahr besteht hauptsächlich bei Blind-Requests, die den Zustand verändern.
• Alter. Es ist nicht neu im Sinne von “kürzlich”. Oligos Offenlegung widersprach einem Bug, der 2006 bei Mozilla gemeldet wurde.
• Die Fixes. Chrome blockierte 0.0.0.0 in Chromium 128, mit schrittweiser Einführung bis Chrome 133. Apple änderte WebKit, um es zu blockieren. Mozilla änderte den Fetch-Standard, hatte aber zum Zeitpunkt noch keinen Fix für Firefox ausgeliefert.

Der Rollout war uneinheitlich. Als Oligo im Jahr 2025 den MCP Inspector-Fehler (siehe unten) veröffentlichte, war das Verhalten bei 0.0.0.0 in Chromium und Firefox noch ungelöst. Nicht alle Browser auf Ihrem Team sind automatisch geschützt.

Reale Ausnutzung: MCP Inspector

CVE-2025-49596 traf den MCP Inspector, ein Entwickler-Tool zum Testen von MCP-Servern. Es wurde als kritisch eingestuft (CVSS 9.4). Versionen vor 0.14.1 hatten keine Authentifizierung zwischen Client und lokalem Proxy. Durch das Ketten einer CSRF-ähnlichen Anfrage mit dem 0.0.0.0-Tag konnte eine bösartige Website Befehle an den Proxy senden und Code auf dem Entwicklerrechner ausführen. Version 0.14.1, veröffentlicht am 13. Juni 2025, fügte standardmäßig ein Sitzungs-Token und Host-Überprüfung hinzu.

Warum KI-Tools das verschlimmert haben

Lokale KI-Tools laufen oft ohne Authentifizierung auf Loopback, weil “es ist nur lokal”. Drei aktuelle Fälle zeigen dieses Muster.

MCP SDKs (Dezember 2025). CVE-2025-66416 (Python SDK, behoben in 1.23.0) und CVE-2025-66414 (TypeScript SDK, behoben in 1.24.0) wurden offenbart, weil die SDKs keinen Schutz gegen DNS-Rebinding standardmäßig aktiviert hatten. Ein unauthentifizierter MCP-Server auf localhost konnte von einer bösartigen Website erreicht werden, die dann die Tools aufrufen konnte. Server, die stdio verwenden, sind nicht betroffen.

ClawJacked (Februar 2026). Oasis Security zeigte, dass jede Website einen lokalen OpenClaw-Agenten hijacken konnte. Browser blockieren WebSocket-Verbindungen zu localhost auf Cross-Origin-Basis nicht, sodass JavaScript auf der Seite eine Verbindung zum Gateway öffnen und das Passwort erraten konnte. Das Gateway exempted localhost von Ratenbegrenzung und genehmigte Gerätepaare automatisch, was bei erfolgreichem Ratenversuch dauerhaften Zugriff ermöglichte. Ein Fix wurde innerhalb eines Tages veröffentlicht.

NVIDIA NemoClaw und Ollama (August 2026). Oasis Security berichtete, dass eine bösartige Webseite die Ollama-Instanz übernehmen könnte, die hinter NemoClaw läuft. Ollama hatte den DNS-Rebinding-Fehler (CVE-2024-28224) in Version 0.1.29 durch Validierung des Host-Headers behoben. Der Bericht sagt, dass die Validierung übersprungen wird, wenn Ollama an eine Nicht-Loopback-Adresse gebunden ist, und dass der Windows-Host-Pfad OLLAMA_HOST=0.0.0.0:11434 setzt. Der Angreifer konnte dann die Chat-Vorlage des Modells manipulieren, um persistente Anweisungen zu platzieren. Es gibt kein CVE dazu, und bis zum 25. August 2026 wurden keine Exploits gemeldet. Laut Forscher wurde ein Fix für macOS und Linux in NemoClaw v0.0.35 veröffentlicht, nicht aber für Windows und WSL. Überprüfen Sie den aktuellen Status, bevor Sie sich darauf verlassen.

Die Lektion ist, dass das Binden an 0.0.0.0 Schutzmechanismen, die nur für Loopback gelten, stillschweigend deaktivieren kann.

Entwickler-Server und Container-Laufzeiten

Vite (CVE-2025-24010). Vor der Behebung konnten jede Website Anfragen an den Entwicklungsserver senden und die Antworten lesen, wegen permissiver CORS-Einstellungen und fehlender Origin-Validierung bei WebSocket-Verbindungen. Das betraf auch Server, die nur auf der lokalen Maschine liefen. In Vite 6.0.9, 5.4.12 und 4.5.6 behoben. Die neue Option server.allowedHosts erlaubt standardmäßig localhost, *.localhost und IP-Adressen. Vite-Dokumentation warnt, dass das Setzen auf true jede Website erlaubt, den Entwicklungsserver durch DNS-Rebinding zu erreichen, und empfiehlt eine explizite Liste.

Docker Desktop (CVE-2025-9074). Die Docker-Engine-API war erreichbar unter 192.168.65.7:2375 von jedem Container ohne Authentifizierung. Der Fehler wurde mit CVSS 9.3 in Docker Desktop 4.44.3 behoben. Betroffen waren Windows und macOS, nicht Linux, da die Linux-Version einen lokalen Socket nutzt. SOCRadar klassifiziert es als SSRF: Eine Anfrage, die aus einem Container gefälscht wurde, erreichte die Steuerungsebene, die alle Anrufer als vertrauenswürdig ansah.

Was Browser jetzt tun

Chrome’s früherer Plan, Private Network Access mit CORS-Preflights, wurde ausgesetzt wegen Kompatibilitätsproblemen. Vor dem Pausieren fügte Chrome 0.0.0.0/8 zu PNA’s lokalen Bereichen hinzu.

Der Ersatz ist Local Network Access (LNA):

• Chrome 142 (28. Oktober 2025) blockiert Anfragen von öffentlichen Seiten an lokale oder Loopback-Adressen hinter einer Berechtigungsabfrage. Andere Chromium-Browser folgten.
• Chrome 145 teilt die Berechtigung in local-network und loopback-network, laut Chrome-Tracking-Issue. Das gleiche Issue sagt, dass Chrome 147 die Beschränkungen auf WebSocket und WebTransport ausdehnt, und dass die temporäre Enterprise-Opt-out-Policy in Chrome 156 entfernt wird.
• Firefox hat eine ähnliche Abfrage. Mozilla-Supportseite sagt, dass es ab Version 149 für Nutzer mit Strengerer Schutzfunktion gilt, mit schrittweiser Einführung ab Version 151.

Diese Verbesserungen sind echte Fortschritte, aber sie sind nur eine Verteidigungsebene. Sie fordern Nutzer auf und kontrollieren Cross-Site-Anfragen; sie machen keinen unauthentifizierten lokalen Dienst sicher. DNS-Rebinding und Malware auf dem Gerät sind separate Probleme. Die Standardlösung gegen Rebinding ist die Validierung von Host- und Origin-Headern auf dem Server. Browserkontrollen sind eine zweite Schutzschicht.

App absichern: Checkliste

1. Authentifizieren Sie jeden lokalen Dienst, auch auf Loopback. Verwenden Sie ein zufälliges Token, nicht “es ist nur localhost”. CVE-2025-49596 und ClawJacked basierten auf fehlender oder schwacher Authentifizierung.
2. Whitelist für den Host-Header und alles andere ablehnen. Das ist die Kernabwehr gegen DNS-Rebinding. Verwenden Sie niemals Wildcards oder “allow all” (z.B. Vite allowedHosts: true).
3. Validieren Sie Origin bei zustandsverändernden Anfragen und WebSocket-Upgrade. CORS regelt WebSocket-Verbindungen nicht, daher kann es sie nicht schützen.
4. Setzen Sie Ratenbegrenzungen auch für localhost, und genehmigen Sie Gerätepaare oder Registrierung von Loopback aus nicht automatisch.
5. Binden Sie an 127.0.0.1, nicht an 0.0.0.0, außer Sie benötigen LAN-Zugriff. Wenn ein Container oder WSL eine breitere Bindung erzwingt, prüfen Sie, welche Host-Checks noch aktiv sind.
6. Bevorzugen Sie stdio oder lokale Sockets gegenüber TCP für lokale Kommunikation. MCPs stdio-Transport ist nicht dem Browserangriff ausgesetzt, und Docker auf Linux hat CVE-2025-9074 deshalb vermieden.
7. Patchen Sie. Die oben genannten Versionen sind das Minimum: Vite 6.0.9 / 5.4.12 / 4.5.6, MCP Inspector 0.14.1, MCP Python SDK 1.23.0, MCP TypeScript SDK 1.24.0, Ollama 0.1.29, Docker Desktop 4.44.3.

Server-seitige Fetcher absichern (localhost SSRF)

Wenn Ihr Backend URLs vom Nutzer abruft:

• Bevorzugen Sie eine Allowlist. Das OWASP SSRF Prevention Cheat Sheet sagt, dass Deny-Listen anfällig für Umgehungen sind. Vergleichen Sie den Host mit bekannten Zielen und bauen Sie die Anfrage selbst.
• Blockieren Sie alle lokalen Repräsentationen, nicht nur 127.0.0.1. OWASP listet 127.0.0.0/8, 0.0.0.0/8 und ::1/128 für localhost. Öffentliche Listen zeigen viele Varianten: 127.1, 0, [::], Dezimal 2130706433, Hex 0x7f000001, IPv4-mapped IPv6-Formen.
• Auflösen, validieren, fixieren. Suchen Sie sowohl A- als auch AAAA-Records, prüfen Sie jede Adresse gegen Ihre Blocklisten und verbinden Sie sich mit der validierten IP. Andernfalls kann ein Hostname die Validierung passieren und sich auf eine private Adresse auflösen.
• Weiterleitung umkehren, dann erneut prüfen. Ein Redirect-Ziel ist eine zweite Anfrage, die die gleichen Prüfungen braucht.
• Blockieren Sie Link-Local- und private Bereiche, inklusive der Cloud-Metadatenadresse 169.254.169.254.

Wo ein Tunnel passt

Ein Tunnel kehrt Ihre Exposition um: Statt eines localhost-Dienstes, den nur Ihr Browser erreichen kann, haben Sie einen Dienst, den jeder mit der URL erreichen kann. Das ist nützlich für Webhooks, OAuth-Callbacks, Demos und MCP-Tests, aber es macht die obige Checkliste zwingend.

Ein Tunnel behebt die oben genannten Probleme nicht. Es kann kein Host-Validation für Ihren Entwicklungsserver oder Authentifizierung für Ihren MCP-Endpunkt hinzufügen. Was es tun kann, ist Zugriffskontrolle vor den lokalen Dienst zu setzen, damit Sie sich nicht auf die Standardkonfiguration des Dienstes verlassen. Basierend auf InstaTunnel-Dokumentation:

• Edge-Authentifizierung. --password und --auth user:pass schützen einen Tunnel. Diese benötigen einen Pro- oder Business-Plan. Ab CLI 1.1.24 werden Passwort- und Basic-Auth-Einstellungen vor Weiterleitung an Ihre Maschine durchgesetzt.

instatunnel 3000 --subdomain acme-qa --auth qa:review-secret

• MCP-Tunnel mit Bearer-Token. --mcp erfordert Pro oder Business. Die Dokumentation zeigt, wie man ein Token mit node -e "console.log(require('crypto').randomBytes(32).toString('hex'))" generiert und es als Authorization: Bearer-Header verwendet. Ihr MCP-Server muss das Token selbst durchsetzen; der Client benötigt es standardmäßig nicht.

instatunnel 8787 --mcp --transport v2 --subdomain mymcp

• Traffic-Policies. Die Traffic-Policy-Dokumentation beschreibt IP-Allow- und Deny-Regeln nach CIDR, Header-Regeln, Ratenbegrenzungen pro IP/API-Key/Nutzer (mit 403 oder 429 bei Blockierung) und Audit-Logs für blockierte Anfragen. Diese werden von Administratoren über /admin/policies verwaltet.
• Sichtbarkeit und Bereinigung. --logs (Pro/Business) ruft Request-Logs ab, und --kill <subdomain> beendet einen Tunnel. Für QA-Links empfehlen die Dokumente, Anmeldedaten zu rotieren und den Tunnel nach Überprüfung zu stoppen.

Ein praktischer Punkt: Wenn Ihr Tunnel seinen öffentlichen Hostnamen im Host-Header weitergibt, wird eine Host-Allowlist wie Vites allowedHosts es ablehnen, bis Sie genau diesen Hostnamen hinzufügen. Fügen Sie den spezifischen Hostnamen hinzu, den Sie kontrollieren, nicht eine Wildcard und nicht true. Überprüfen Sie, was Ihr Tunnel tatsächlich sendet, bevor Sie sich darauf verlassen.

Zusammenfassung

• 0.0.0.0 Day ist eine Browser-Schwachstelle aus 2024, die uneinheitlich gemildert wurde. Sie wurde in der Praxis gegen Entwickler-Tools wie MCP Inspector ausgenutzt.
• DNS-Rebinding taucht immer wieder in Entwickler-Tools auf, von Ollama 2024 bis MCP SDKs 2025 bis NemoClaw 2026. Die Lösung ist immer serverseitig: Authentifizieren und Host- sowie Origin-Header validieren.
• Browser-Berechtigungsabfragen (Chrome 142+, Firefox 149+) reduzieren die Exposition, ersetzen aber nicht diese Prüfungen.
• Server-seitige Fetcher brauchen Allowlists, vollständige Adressfamilienauflösung und fixierte Verbindungen.
• Tunnels sollten Authentifizierung und Zugriffskontrolle vor Ihren Dienst setzen, niemals nur die einzige Barriere sein.