QVD-2026-57410: Så kan en falsk Host-header kringgå DeepSeek Harness skydd

QVD-2026-57410 är en rapporterad kritisk sårbarhet i DeepSeek Harness (DSH) 0.1.1-rc.2. Rapporter kopplade till QiAnXin beskriver den som en oautentiserad sårbarhet för fjärrkörning av kod, med CVSS 3.0-poängen 9,8. Grundproblemet är att DSH:s beslut om huruvida en begäran är betrodd kan bygga på HTTP-headern Host – ett värde som klienten själv kontrollerar. Det är inte en säker ersättning för autentisering. 1924

Den praktiska risken beror mycket på hur tjänsten är distribuerad. DeepSeeks dokumenterade webbkommando startar som standard gränssnittet på 127.0.0.1:3080, vilket begränsar direkt åtkomst från andra datorer. Läget blir betydligt allvarligare om tjänsten binds till ett annat nätverksgränssnitt eller görs åtkomlig via Docker, en reverse proxy, en tunnel, ett VPN, ett lokalt nätverk eller en ingress. 1118

Så fungerar kringgåendet av Host-headern

Den berörda designen försöker skilja lokala förfrågningar från fjärrförfrågningar genom information i begärans värd. Men Host-headern skickas av klienten och kan förfalskas. En angripare som kan nå tjänsten kan därför ange ett lokalt utseende på värdet och få /api-lagret att behandla begäran som betrodd. Rapporter beskriver detta som ett kringgående av DSH:s loopback-baserade förtroendegräns. 1924

På en övergripande nivå ser den rapporterade attackkedjan ut så här:

1. Angriparen når en exponerad webb- eller administrationsendpoint i DSH.
2. En begäran skickas med en förfalskad, lokalt utformad Host-header.
3. /api-begränsningen som ska skydda interna funktioner kringgås.
4. Begränsad RPC-funktionalitet anropas.
5. En angriparkontrollerad modellleverantör registreras eller används.
6. DSH:s agentfunktioner drivs till att köra kommandon på värdsystemet. 1920

Det är därför sårbarheten är allvarligare än ett vanligt routingfel eller en informationsläcka: kringgåendet når funktioner som är utformade för att låta en AI-agent arbeta med systemnära funktioner.

Varför felet kan leda till fjärrkörning av kod

DeepSeek beskriver Harness som experimentell förhandsversion för utvecklare och uppger att projektet inte har genomgått någon säkerhetsgranskning. I säkerhetsinformationen varnas det för att projektet kan köra modellgenererad kod och kommandon samt få åtkomst till nätverk, processer, autentiseringsuppgifter och filer som görs tillgängliga för det. 4

LLM-delsystemet stöder dessutom registrering av leverantörer och modellidentifiering, bland annat genom fjärroperationen discoverModels. 23 I den rapporterade exploitkedjan kan en angriparkontrollerad leverantör användas för att leverera den input som behövs för att nå agentens kommandokörning. 19

En lyckad attack ger inte automatiskt angriparen root-behörighet. Kommandon körs med samma rättigheter som DSH-tjänstens process. De kan ändå räcka för att läsa eller ändra åtkomliga filer, använda tillgängliga lösenord och API-nycklar, starta processer, ändra applikationsdata eller skapa utgående nätverksanslutningar.

Den slutliga påverkan beror på distributionen. Riskerna ökar exempelvis om tjänsten har överdriven filåtkomst, körs i en privilegierad container, har en monterad Docker-socket eller kan använda molnuppgifter. Det tillgängliga underlaget visar inte att varje installation automatiskt innebär ett fullständigt övertagande av värddatorn.

Vilka installationer är mest utsatta?

Följande konfigurationer bör granskas omgående:

• DSH är bunden till 0.0.0.0 eller någon annan adress än loopback.
• Docker eller en annan containerkörmiljö publicerar port 3080 utanför den lokala datorn.
• En reverse proxy vidarebefordrar administrations-API:t till internet eller ett otillförlitligt lokalt nätverk.
• En tunnel, ett VPN eller en ingress gör tjänsten åtkomlig för användare som inte är starkt autentiserade.
• Proxyinställningar accepterar godtyckliga klientvärden i Host eller skickar dem vidare till backend utan validering.

Att en tjänst kallas ”intern” är inte i sig en behörighetskontroll. En angripare som kan nå endpointen och påverka relevanta headers kan fortfarande försöka kringgå skyddet.

Offentlig PoC, CVE-status och tecken på aktiv exploatering

Flera rapporter uppger att tekniska detaljer eller kod för ett proof of concept (PoC) för QVD-2026-57410 är offentliga. 192027 Det ökar behovet av att begränsa exponeringen, men offentlig PoC-kod är inte samma sak som bevis på att en viss installation har komprometterats.

Det tillgängliga underlaget uppger att ingen exploatering i det fria internet har observerats och att det vid rapporteringstillfället saknades belägg för koppling till en känd hotaktör eller kampanj. 1924 Det är bara en ögonblicksbild, inte en garanti för att tjänsten är säker. Exponerade installationer bör därför ändå kontrolleras efter misstänkta förfrågningar, oväntade modellregistreringar, nya processer och ovanliga utgående anslutningar.

QVD-2026-57410 är ett QVD-nummer och inte ett CVE-nummer. Det snarlika CVE-2026-57410 gäller enligt NVD en separat sårbarhet för privilegieeskalering i MailerPress. 17

Rekommenderade åtgärder

1. Ta bort nätverksexponeringen först

Sluta publicera DSH:s administrations- och API-tjänst på internet. Bind den till loopback eller ett separat administrationsnät och använd ett kontrollerat VPN eller en bastion för fjärradministration.

2. Begränsa åtkomsten i varje nätverkslager

Använd regler i brandvägg, molnets säkerhetsgrupper, containernätverk och reverse proxy så att endast uttryckligen betrodda källor tillåts. Lita inte på en intern rutt eller en ”lokal” header som bevis på identitet.

3. Validera och skriv över proxyheaders

Avvisa oväntade Host-värden i edge-proxyn. Om proxyvidarebefordran behövs ska proxyn skriva över upstream-värdet med ett känt, fast värde i stället för att blint skicka vidare klientens värde. Lita bara på vidarebefordrade klient-IP-headers när de kommer från en kontrollerad proxy.

4. Inför autentisering som inte bygger på Host

Skydda administrationsfunktioner och interna RPC-operationer med riktig autentisering och auktorisering, exempelvis en starkt autentiserad gateway, mTLS och åtkomstkontroll per operation. Host-headerkontroll kan vara användbar för routing, men får aldrig vara den enda identitetskontrollen.

5. Minska riskerna med modellidentifiering och utgående trafik

Inaktivera eller begränsa llm.discoverModels när funktionen inte behövs. Om modellidentifiering krävs bör leverantörernas endpoint-adresser vitlistas och utgående trafik begränsas. Blockering av känsliga interna adresser och molnplattformars metadataadresser kan minska effekten om funktionen missbrukas som en SSRF-liknande väg. DSH:s LLM-dokumentation bekräftar att registrering av leverantörer och modellidentifiering är exponerade funktioner. 23

6. Kontrollera en eventuell korrigering via officiell information

De tillgängliga källorna pekar ut 0.1.1-rc.2 som berörd version och visar senare releaseaktivitet, men de fastställer inte att en viss senare version åtgärdar just denna sårbarhet. Kontrollera DeepSeeks aktuella versionsinformation och säkerhetsmeddelanden efter en uttryckligen bekräftad korrigering innan en uppgradering betraktas som tillräcklig. Projektets egen säkerhetsinformation beskriver fortfarande Harness som experimentellt och inte produktionsklart. 410

7. Sök efter intrång och rotera hemligheter

Granska reverse-proxy- och DSH-loggar efter avvikande /api-förfrågningar, förfalskade lokala Host-värden, oväntade modellregistreringar, nya processer, ändrade filer och ovanliga utgående anslutningar. Rotera alla autentiseringsuppgifter som DSH-processen kan ha nått. Om det finns tecken på kommandokörning eller kvarvarande åtkomst bör den berörda värden eller containern isoleras och byggas om i stället för att man antar att en omstart har tagit bort intrånget.