Gefälschter Host-Header kann DeepSeek Harness zur Fernsteuerung öffnen

QVD-2026-57410 ist eine gemeldete kritische Schwachstelle in DeepSeek Harness (DSH) 0.1.1-rc.2. Berichte mit Bezug zum QiAnXin Threat Intelligence Center bewerten sie mit einem CVSS-3.0-Wert von 9.8. Es geht um eine nicht authentifizierte Remotecodeausführung (RCE): Die Vertrauensentscheidung der /api-Schnittstelle kann sich auf den vom Client kontrollierten HTTP-Header Host stützen – und damit auf ein Merkmal, das kein verlässlicher Identitätsnachweis ist. 1924

Das tatsächliche Risiko hängt stark vom Deployment ab. Der von DeepSeek dokumentierte Start des Web-Interfaces bindet den Dienst standardmäßig an 127.0.0.1:3080. Damit ist er zunächst nur auf dem lokalen Rechner erreichbar. Gefährlich wird es, wenn der Dienst an eine Nicht-Loopback-Adresse gebunden, über Docker veröffentlicht oder durch einen Reverse-Proxy, Tunnel, ein VPN, ein LAN oder einen Ingress weitergereicht wird. 1118

So funktioniert der Host-Header-Bypass

Die betroffene Architektur versucht offenbar, lokale und externe Anfragen anhand der Host-Information zu unterscheiden. Der Host-Header wird jedoch vom anfragenden Client geliefert und kann manipuliert werden. Erreicht ein Angreifer den Dienst, kann er deshalb einen lokal wirkenden Host-Wert mitsenden. Die /api-Schicht kann die Anfrage dann fälschlicherweise als vertrauenswürdig einstufen. In den Berichten wird dies als Umgehung der Loopback- beziehungsweise lokalen Vertrauensgrenze von DSH beschrieben. 1924

Die gemeldete Angriffskette lässt sich auf hoher Ebene so zusammenfassen:

1. Der Angreifer erreicht einen nach außen oder in ein nicht vertrauenswürdiges Netz veröffentlichten DSH-Web- oder Management-Endpunkt.
2. Er sendet eine Anfrage mit einem gefälschten, lokal wirkenden Host-Header.
3. Die für interne Vorgänge gedachte /api-Beschränkung wird umgangen.
4. Eingeschränkte RPC-Funktionen werden aufgerufen.
5. Ein vom Angreifer kontrollierter Modellanbieter wird registriert oder verwendet.
6. Die Agent-Funktionen von DSH werden dazu gebracht, Befehle auf dem Zielsystem auszuführen. 1920

Das ist deutlich mehr als ein gewöhnlicher Routing- oder Informationsabflussfehler: Der Bypass führt zu Funktionen eines KI-Agenten, der bewusst mit Systembefehlen und anderen leistungsfähigen Werkzeugen arbeiten kann.

Warum daraus Remotecodeausführung werden kann

DeepSeek bezeichnet Harness als experimentelle Developer-Preview-Software, die noch keinem Sicherheits-Audit unterzogen wurde. In der eigenen Sicherheitswarnung heißt es, dass das Projekt modellgenerierten Code und Befehle ausführen sowie auf bereitgestellte Netzwerke, Prozesse, Zugangsdaten und Dateien zugreifen kann. 4

Das LLM-Subsystem unterstützt außerdem die Registrierung von Providern und die Ermittlung verfügbarer Modelle, unter anderem über die Remote-Operation discoverModels. 23 Nach den vorliegenden Berichten kann ein vom Angreifer kontrollierter Provider genutzt werden, um den Agenten bis zu seinen Befehlsausführungsfunktionen zu führen. 19

Eine erfolgreiche Ausnutzung verleiht nicht automatisch Root-Rechte. Die Befehle werden mit den Berechtigungen des DSH-Serviceprozesses ausgeführt. Diese können jedoch ausreichen, um zugängliche Dateien zu lesen oder zu verändern, erreichbare Zugangsdaten und API-Schlüssel auszulesen, Prozesse zu starten, Anwendungsdaten zu manipulieren oder ausgehende Netzwerkverbindungen aufzubauen.

Wie weit der Schaden reicht, hängt von der Umgebung ab. Das Risiko steigt etwa bei übermäßigen Dateirechten, privilegierten Containern, einem eingebundenen Docker-Socket oder verfügbaren Cloud-Zugangsdaten. Die vorliegenden Berichte belegen nicht, dass jede Installation automatisch vollständig übernommen werden kann.

Welche Installationen besonders gefährdet sind

Betreiber sollten insbesondere diese Konfigurationen umgehend prüfen:

• DSH lauscht auf 0.0.0.0 oder einer anderen Nicht-Loopback-Adresse.
• Docker oder eine andere Container-Laufzeitumgebung veröffentlicht Port 3080 über den lokalen Rechner hinaus.
• Ein Reverse-Proxy leitet die Management-API ins Internet oder in ein nicht vertrauenswürdiges LAN weiter.
• Ein Tunnel, VPN oder Ingress macht den Dienst für Nutzer erreichbar, die nicht stark authentifiziert sind.
• Der Proxy akzeptiert beliebige Host-Werte von Clients oder leitet deren Host-Header unverändert an DSH weiter.

„Intern“ ist dabei kein Synonym für „autorisiert“. Wer den Endpunkt erreichen und die relevanten Request-Header beeinflussen kann, kann zumindest versuchen, die Vertrauensprüfung zu umgehen.

Öffentlicher PoC, CVE-Status und Hinweise auf Angriffe

Mehrere Berichte geben an, dass technische Details und Proof-of-Concept-Material (PoC) zu QVD-2026-57410 öffentlich zugänglich sind. 192027 Das erhöht den Zeitdruck bei der Absicherung. Ein öffentlicher PoC ist jedoch kein Beleg dafür, dass eine konkrete Installation bereits kompromittiert wurde.

Zum Zeitpunkt der Veröffentlichung lagen laut den bereitgestellten Berichten keine beobachteten Ausnutzungen in freier Wildbahn und keine Hinweise auf eine Verbindung zu einem bekannten Angreifer oder einer bestimmten Kampagne vor. 1924 Das ist lediglich eine Momentaufnahme und keine Entwarnung. Erreichbare Systeme sollten auf ungewöhnliche /api-Anfragen, unerwartete Provider-Registrierungen, neue Prozesse und auffällige ausgehende Verbindungen untersucht werden.

Wichtig ist außerdem die Bezeichnung: QVD-2026-57410 ist eine QVD-Kennung und keine CVE-Nummer. Die ähnlich lautende CVE-2026-57410 bezeichnet laut NVD eine davon unabhängige Privilegieneskalationslücke im WordPress-Plugin MailerPress. 17

Was Betreiber jetzt tun sollten

1. Netzwerkzugriff sofort reduzieren

Entfernen Sie die DSH-Management- und API-Schnittstelle aus dem öffentlichen Internet. Binden Sie sie an Loopback oder ein dediziertes Management-Netz. Für Fernzugriffe sollten ein kontrolliertes VPN oder ein Bastion-Host verwendet werden.

2. Zugriffe auf jeder Netzebene begrenzen

Setzen Sie Regeln in Firewall, Cloud-Sicherheitsgruppen, Container-Netzwerk und Reverse-Proxy um, die ausschließlich ausdrücklich vertrauenswürdige Quellen zulassen. Eine interne Route oder ein „lokal“ aussehender Header darf nicht als Identitätsnachweis dienen.

3. Proxy-Header validieren und überschreiben

Verwerfen Sie am Edge-Proxy unerwartete Host-Werte. Wenn eine Weiterleitung erforderlich ist, sollte der Proxy den Upstream-Host-Header mit einem bekannten festen Wert überschreiben, statt den Client-Wert blind weiterzureichen. Header zur Client-IP sollten nur dann als vertrauenswürdig gelten, wenn sie von einem kontrollierten Proxy stammen.

4. Authentifizierung unabhängig vom Host-Header einführen

Schützen Sie Management- und interne RPC-Funktionen mit echter Authentifizierung und Autorisierung – etwa über ein stark abgesichertes Gateway, mTLS und Berechtigungen pro Operation. Eine Host-Header-Prüfung kann bei der Weiterleitung helfen, darf aber niemals die einzige Identitätskontrolle sein.

5. Provider-Erkennung und ausgehende Verbindungen einschränken

Deaktivieren oder beschränken Sie llm.discoverModels, wenn die Funktion nicht benötigt wird. Erlauben Sie nur bekannte Provider-Endpunkte und setzen Sie Egress-Regeln für ausgehenden Datenverkehr. Der Zugriff auf sensible interne Ziele und Cloud-Metadaten-Dienste sollte blockiert werden. Das kann den Schaden begrenzen, falls die Provider-Erkennung als serverseitige Anfragefunktion missbraucht wird. Die DSH-Dokumentation bestätigt, dass Provider-Registrierung und Modellerkennung zu den verfügbaren Fähigkeiten gehören. 23

6. Eine bestätigte Fehlerbehebung abwarten beziehungsweise einspielen

Die bereitgestellten Quellen nennen 0.1.1-rc.2 als betroffene Version und zeigen spätere Release-Aktivitäten. Sie bestätigen jedoch nicht, dass ein bestimmter späterer Build die Schwachstelle tatsächlich behebt. Prüfen Sie daher die aktuellen Release Notes und Sicherheitsmitteilungen von DeepSeek auf eine ausdrücklich bestätigte Korrektur, bevor Sie ein Update als ausreichend betrachten. Die Sicherheitswarnung des Projekts stuft Harness weiterhin als experimentell und nicht produktionsreif ein. 410

7. Bei bestehender Exponierung nach Kompromittierung suchen

Analysieren Sie Reverse-Proxy- und DSH-Logs auf ungewöhnliche /api-Anfragen, gefälschte lokale Host-Werte, unerwartete Provider-Registrierungen, neue Prozesse, veränderte Dateien und ausgehende Verbindungen. Rotieren Sie alle Zugangsdaten, auf die der DSH-Prozess zugreifen konnte. Gibt es Hinweise auf Befehlsausführung oder Persistenz, sollte der betroffene Host beziehungsweise Container isoliert und neu aufgebaut werden – ein Neustart allein entfernt eine mögliche Kompromittierung nicht zuverlässig.