QVD-2026-57410: DeepSeek Harness की Host-Header खामी को समझें

QVD-2026-57410, DeepSeek Harness (DSH) 0.1.1-rc.2 में रिपोर्ट की गई एक गंभीर, अनधिकृत रिमोट कोड एक्जीक्यूशन (RCE) खामी है। QiAnXin से जुड़े सुरक्षा रिपोर्टों के अनुसार इसका CVSS 3.0 स्कोर 9.8 है। समस्या की जड़ यह है कि DSH का /api सुरक्षा निर्णय क्लाइंट द्वारा भेजे गए HTTP Host Header पर भरोसा कर सकता है—जबकि यह Header हमलावर अपनी इच्छा से बदल सकता है। 1924

इस खामी का वास्तविक जोखिम डिप्लॉयमेंट पर निर्भर करता है। DeepSeek के दस्तावेजों के अनुसार वेब कमांड डिफॉल्ट रूप से 127.0.0.1:3080 पर इंटरफेस शुरू करती है, जिससे सीधे बाहरी नेटवर्क से पहुंच सीमित रहती है। खतरा तब काफी बढ़ जाता है जब यही सेवा किसी गैर-loopback इंटरफेस पर उपलब्ध हो, Docker के जरिए पोर्ट प्रकाशित किया गया हो या रिवर्स प्रॉक्सी, टनल, VPN, LAN अथवा ingress के माध्यम से आगे भेजी जा रही हो। 1118

Host Header से सुरक्षा सीमा कैसे टूटती है?

प्रभावित डिजाइन स्थानीय और दूरस्थ अनुरोधों में अंतर करने के लिए अनुरोध के host संबंधी विवरण का इस्तेमाल करता है। लेकिन Host Header अनुरोध भेजने वाला स्वयं तय करता है और इसे फर्जी बनाया जा सकता है। इसलिए सेवा तक पहुंच रखने वाला हमलावर ऐसा host value भेज सकता है जो स्थानीय अनुरोध जैसा दिखे। इससे /api लेयर अनुरोध को भरोसेमंद मान सकती है और मूल रूप से आंतरिक उपयोग के लिए सीमित कार्यों तक पहुंच दे सकती है। रिपोर्टों ने इसे DSH की loopback-आधारित trust boundary को पार करना बताया है। 1924

रिपोर्ट की गई attack chain को ऊंचे स्तर पर इस तरह समझा जा सकता है:

1. इंटरनेट या किसी अविश्वसनीय नेटवर्क से उपलब्ध DSH वेब या management endpoint तक पहुंच बनाना।
2. स्थानीय जैसा दिखने वाला फर्जी Host Header भेजना।
3. /api के उस प्रतिबंध को पार करना जो आंतरिक संचालन को सुरक्षित रखने के लिए बनाया गया है।
4. प्रतिबंधित RPC कार्यों को इस्तेमाल करना।
5. हमलावर के नियंत्रण वाले model-provider route को register या इस्तेमाल करना।
6. DSH की Agent क्षमताओं के जरिए होस्ट पर कमांड चलाने की कोशिश करना। 1920

यही कारण है कि यह केवल routing या information-disclosure की समस्या नहीं है। DSH एक AI Agent framework है, जिसे सिस्टम पर कमांड और अन्य क्षमताओं के साथ काम करने के लिए बनाया गया है।

यह खामी RCE में कैसे बदल सकती है?

DeepSeek अपने Harness को experimental developer-preview software बताता है और कहता है कि इसका security audit नहीं हुआ है। सुरक्षा सूचना के अनुसार यह मॉडल से उत्पन्न कोड और कमांड चला सकता है तथा उसे उपलब्ध कराई गई नेटवर्क, प्रक्रियाओं, credentials और files तक पहुंच सकता है। 4

DSH का LLM subsystem provider registration और model discovery जैसी सुविधाएं भी उपलब्ध कराता है। इनमें discoverModels नामक remote operation शामिल है। 23 रिपोर्ट की गई exploit chain में हमलावर के नियंत्रण वाले provider का इस्तेमाल उस इनपुट को उपलब्ध कराने के लिए किया जा सकता है जो Agent की command-execution क्षमताओं तक पहुंचने में मदद करे। 19

सफल exploitation का अर्थ अपने-आप root access मिलना नहीं है। कमांड DSH service process के अधिकारों के साथ चलेंगी। फिर भी ये अधिकार पर्याप्त रूप से संवेदनशील हो सकते हैं—मसलन, हमलावर उन फाइलों को पढ़ या बदल सकता है जिन तक सर्विस की पहुंच है, उपलब्ध credentials या API keys का दुरुपयोग कर सकता है, नई प्रक्रियाएं शुरू कर सकता है, application data बदल सकता है या बाहरी नेटवर्क कनेक्शन बना सकता है।

अंतिम प्रभाव इस बात पर निर्भर करेगा कि सेवा कैसे तैनात की गई है। अत्यधिक filesystem access, privileged container, mounted Docker socket या cloud credentials तक पहुंच जैसी गलत कॉन्फिगरेशन नुकसान को बहुत बढ़ा सकती हैं। उपलब्ध रिपोर्ट यह साबित नहीं करतीं कि हर deployment में स्वतः पूरे host का नियंत्रण मिल जाता है।

किन deployments की तुरंत समीक्षा करें?

ऑपरेटरों को खास तौर पर इन कॉन्फिगरेशन को प्राथमिकता देनी चाहिए:

• DSH को 0.0.0.0 या किसी अन्य non-loopback address पर bind किया गया हो।
• Docker या किसी अन्य container runtime ने port 3080 को लोकल मशीन से बाहर प्रकाशित किया हो।
• रिवर्स प्रॉक्सी management API को इंटरनेट या अविश्वसनीय LAN तक forward कर रही हो।
• टनल, VPN या ingress के जरिए ऐसी पहुंच उपलब्ध हो जिसे मजबूत authentication से नियंत्रित नहीं किया गया है।
• प्रॉक्सी मनमाने client Host values स्वीकार करती हो या उन्हें बिना बदले upstream भेजती हो।

किसी सेवा का “internal” होना अपने-आप authorization control नहीं है। यदि हमलावर endpoint तक पहुंच सकता है और संबंधित request headers को प्रभावित कर सकता है, तो वह bypass का प्रयास कर सकता है।

Public PoC, CVE स्थिति और active exploitation

कई रिपोर्टों के अनुसार QVD-2026-57410 के technical details या proof-of-concept (PoC) material सार्वजनिक है। 192027 इससे containment की urgency बढ़ती है, लेकिन public PoC का मतलब यह नहीं है कि किसी खास इंस्टॉलेशन से छेड़छाड़ निश्चित रूप से हो चुकी है।

उपलब्ध रिपोर्टिंग के समय इस खामी के in-the-wild exploitation के कोई observed evidence नहीं मिले थे। किसी ज्ञात threat actor या campaign से इसके संबंध का भी प्रमाण नहीं बताया गया। 1924 यह केवल disclosure के समय की सीमित स्थिति है, सुरक्षा की गारंटी नहीं। खुले नेटवर्क पर उपलब्ध instances में संदिग्ध requests, अनपेक्षित provider registrations, नई processes और असामान्य outbound connections की जांच फिर भी करनी चाहिए।

ध्यान दें कि QVD-2026-57410, QVD identifier है, CVE identifier नहीं। इसी तरह दिखने वाला CVE-2026-57410 एक अलग MailerPress privilege-escalation vulnerability को दर्शाता है, जैसा कि NVD entry में दर्ज है। 17

ऑपरेटरों के लिए जरूरी कदम

1. पहले नेटवर्क exposure हटाएं

DSH management और API service को सार्वजनिक इंटरनेट पर प्रकाशित करना बंद करें। इसे loopback या अलग management network तक सीमित करें। दूरस्थ प्रशासन जरूरी हो तो नियंत्रित VPN या bastion host का इस्तेमाल करें।

2. हर नेटवर्क लेयर पर access सीमित करें

Firewall, cloud security group, container network और reverse-proxy नियमों में केवल स्पष्ट रूप से trusted sources को अनुमति दें। किसी internal route या “local-looking” Header को पहचान का प्रमाण न मानें।

3. Proxy headers को validate और overwrite करें

Edge proxy पर अनपेक्षित Host values अस्वीकार करें। Proxying आवश्यक हो तो client की value को सीधे forward करने के बजाय upstream Host Header को ज्ञात और fixed value से overwrite करें। Forwarded client-IP headers पर तभी भरोसा करें जब वे नियंत्रित proxy से आए हों।

4. Host Header से स्वतंत्र authentication जोड़ें

Management और internal RPC operations को वास्तविक authentication और authorization से सुरक्षित करें—जैसे strongly authenticated gateway, mTLS और operation-level access controls। Host-header validation routing में मदद कर सकता है, लेकिन इसे कभी अकेला identity check न बनाएं।

5. Provider discovery और outbound जोखिम घटाएं

जहां जरूरत न हो, llm.discoverModels को disable या restrict करें। Provider discovery आवश्यक हो तो provider endpoints को allowlist करें और outbound egress controls लागू करें। संवेदनशील internal addresses तथा cloud-metadata destinations तक पहुंच रोकने से provider-discovery path के दुरुपयोग की स्थिति में SSRF-जैसे प्रभाव को सीमित किया जा सकता है। DSH के LLM दस्तावेज provider registration और model discovery को उपलब्ध क्षमताओं के रूप में दर्ज करते हैं। 23

6. आधिकारिक fix की पुष्टि के बाद ही upgrade को पर्याप्त मानें

उपलब्ध स्रोत 0.1.1-rc.2 को प्रभावित संस्करण बताते हैं और बाद की release activity दिखाते हैं, लेकिन वे यह स्थापित नहीं करते कि कोई खास बाद का build इस vulnerability को ठीक करता है। DeepSeek की मौजूदा release notes और security advisories में स्पष्ट रूप से confirmed remediation देखें। Harness की अपनी safety notice अब भी इसे experimental और production-ready न होने वाला software बताती है। 410

7. Exposure रहा हो तो जांच और credential rotation करें

Reverse-proxy और DSH logs में असामान्य /api requests, स्थानीय जैसा फर्जी Host value, अनपेक्षित model-provider registrations, नई processes, बदली हुई files और असामान्य outbound connections तलाशें। DSH process को उपलब्ध credentials rotate करें। यदि command execution या persistence के संकेत मिलें, तो केवल service restart पर निर्भर न रहें—प्रभावित host या container को isolate करके rebuild करें।