vghost-watch

CVE-2026-74580 ("Vghost") के लिए एक परिधि-जाँच और जिम्मेदार-प्रकटीकरण सहायक — यह एक वास्तविक Linux kernel vhost मेटाडेटा-कैश बग है (CVE रिकॉर्ड, OSV प्रविष्टि) जो उजागर vhost/hypervisor होस्ट पर स्थानीय-privesc / VM-escape प्रदान करता है।

प्राथमिक उपयोग मामला: अपनी स्वयं की परिधि की जाँच करें। अपनी स्वयं की IP रेंज, CIDR, या डोमेन (import_list.py) दर्ज करें — आंतरिक या बाहरी — और उन्हें vhost-आसन्न एक्सपोज़र (libvirt/Proxmox/QEMU प्रबंधन पोर्ट) के लिए ट्राइएज करें, फिर अपने स्वयं के ट्रैकर के लिए उपचार नोट्स प्राप्त करें (run_pipeline.py --self, नीचे "अपनी स्वयं की परिधि की जाँच करना" देखें)। कोई ऑटो-डिस्कवरी नहीं, कोई सामूहिक संपर्क लुकअप नहीं — होस्ट पहले से ही आपका है।

द्वितीयक क्षमता: सार्वजनिक स्कैन डेटा के माध्यम से तृतीय-पक्ष खोज। यह प्रोजेक्ट स्वयं इंटरनेट को स्कैन नहीं करता — यह वैकल्पिक रूप से उन डेटासेट/API को क्वेरी कर सकता है जिन्होंने पहले ही स्कैनिंग कर ली है (Rapid7 Open Data / Sonar, Shodan, Censys) ताकि अन्य उजागर होस्ट खोजे जा सकें, फिर उनके मालिकों को प्रकटीकरण सूचनाओं का मसौदा तैयार करने में आपकी सहायता करता है। यहाँ समय निवेश करने से पहले जानने योग्य बात: इसके लिए कोई बाउंटी नहीं है (CSIRT भुगतान नहीं करते, और "ज्ञात CVE, अनपैच्ड इंस्टेंस" रिपोर्टें शायद ही कभी बाउंटी-पात्र होती हैं — नीचे "प्रभाव" देखें) — यह अवैतनिक, सज्जन-नागरिक अधिसूचना कार्य है, और इस रेपो का अधिकांश वास्तविक उपयोग ऊपर दिया गया परिधि-जाँच मामला है, यह नहीं।

प्रभाव: यह कब लागू / गंभीर है?

CVE-2026-74580 एक kernel-स्तरीय, स्थानीय बग है, वेब/नेटवर्क-फेसिंग नहीं -- इससे कुछ बातें निकलती हैं जो ट्राइएज के लिए मायने रखती हैं:

केवल तभी लागू जब ये सभी शर्तें पूरी हों:

• होस्ट एक अनपैच्ड Linux kernel चलाता है (5.10.265, 5.15.216, 6.1.183, 6.6.152, 6.12.104, 6.18.45, 7.1.9, या डिस्ट्रो बैकपोर्ट से नीचे)।
• यह vhost-समर्थित वर्चुअलाइज़ेशन का उपयोग करता है (QEMU/KVM के माध्यम से vhost-net/vhost-scsi, आमतौर पर libvirt या Proxmox के ज़रिए)। बिना VM वाला बेयर-मेटल होस्ट, या vhost ऑफ़लोड के बिना सादे virtio पर चलने वाले VM, पैच स्तर चाहे जो भी हो, इस बग के प्रति उजागर नहीं हैं।
• स्थानीय कोड निष्पादन एक पूर्वापेक्षा है। यह privesc/VM-escape है, रिमोट कोड निष्पादन नहीं -- हमलावर को पहले से ही कहीं ऐसा कोड चला रहा होना चाहिए जो कमज़ोर इंटरफ़ेस तक पहुँचता हो: एक गेस्ट VM, एक साझा-कर्नेल कंटेनर, या होस्ट पर एक स्थानीय खाता। "पहले से कोड चला रहा है" के लिए SSH जैसी सीधी पहुँच आवश्यक नहीं -- व्यवहार में यह अक्सर इनमें से एक होता है:
  • एक वैध किरायेदार, मल्टी-टेनेंट/क्लाउड हाइपरवाइज़र पर -- एक ग्राहक जिसने बस एक VM किराए पर लिया है, उसके अंदर पहले से ही पूर्ण कोड निष्पादन है, डिज़ाइन के अनुसार, किसी उल्लंघन की आवश्यकता नहीं।
  • गेस्ट के अंदर एक असंबंधित समझौता -- सबसे आम तौर पर एक कमज़ोर वेब ऐप में RCE (एक पुराना प्लगइन, SSRF-to-RCE, डीसेरियलाइज़ेशन बग, आदि), लेकिन गेस्ट-साइड का कोई भी समझौता इसी तरह काम करता है। vhost बग को इससे कोई फ़र्क नहीं पड़ता कि हमलावर अंदर कैसे आया, बस इतना कि अब उसके पास पिवट करने के लिए कोड निष्पादन है।

वास्तविक गंभीरता का निर्धारक यह है कि किसके पास पहले से कोड निष्पादन है (या प्राप्त कर सकता है) -- न कि यह कि होस्ट इंटरनेट-फेसिंग है या नहीं। इंटरनेट एक्सपोज़र केवल इस बात को प्रभावित करता है कि कोई बाहरी हमलावर लक्ष्य को कितनी आसानी से ढूँढता है या प्रारंभिक फ़ुटहोल तक दूर से पहुँचता है; इससे इस बात पर कोई फ़र्क नहीं पड़ता कि एक बार किसी के पास वह फ़ुटहोल हो जाने पर बग शोषणीय है या नहीं। केवल-आंतरिक, निजी अवसंरचना स्वाभाविक रूप से कम जोखिम वाली नहीं होती:

सबसे महत्वपूर्ण, इंटरनेट एक्सपोज़र की परवाह किए बिना:

• कोई भी मल्टी-टेनेंट या मल्टी-यूज़र हाइपरवाइज़र -- होस्टिंग प्रोवाइडर, लेकिन उतना ही एक आंतरिक प्राइवेट क्लाउड, एक आंतरिक VM-प्रति-टीम प्लेटफ़ॉर्म, या VM/ऐप्स पर सामान्य यूज़र खातों वाला एक साझा dev/test वातावरण भी। उनमें से हर एक यूज़र या टेनेंट के पास पहले से ही डिज़ाइन के अनुसार कोड-एग्ज़िक्यूशन की पूर्व-शर्त मौजूद है, बिना किसी सेंध के -- इंटरनेट-फेसिंग हो या न हो।
• कोई भी होस्ट जहाँ हमलावर के पास पहले से ही पैर जमा है (समझौता किया गया VM, इनसाइडर शेल, सह-स्थित कंटेनर एस्केप, समझौता किया गया आंतरिक ऐप) और vhost ऑफ़लोड उपयोग में है -- यह "मेरे पास लो-प्रिव शेल है" को "होस्ट मेरा है" में बदल देता है, चाहे वह शेल किसी भी तरह से प्राप्त हुआ हो।

जहाँ इंटरनेट एक्सपोज़र वास्तव में मायने रखता है (एक द्वितीयक कारक, प्राथमिक नहीं):

• यह किसी बाहरी हमलावर के लिए प्रारंभिक पैर जमाने को दूर से प्राप्त करना आसान बनाता है (जैसे कोई वेब ऐप RCE, नीचे WAF नोट देखें) और होस्ट को खोजना भी आसान बनाता है -- एक्सपोज़्ड मैनेजमेंट पोर्ट (libvirt 16509/16514, Proxmox 8006) इसके लिए एक रेकॉनिसेंस संकेत हैं, जिसे merge_and_triage.py की स्कोरिंग खोजती है। हालाँकि, एक एक्सपोज़्ड पोर्ट अपने आप में कुछ साबित नहीं करता -- यह तभी मायने रखता है जब हमलावर-नियंत्रित कोई चीज़ स्थानीय रूप से निष्पादित कर सके, जो पैसिव स्कैन डेटा नहीं दिखा सकता (यह देखने के लिए नीचे "Why passive-only" देखें कि यह रेपो उन होस्ट्स के विरुद्ध ऐसा क्यों नहीं करता जो आपके नहीं हैं)।
• समान मल्टी-यूज़र/मल्टी-टेनेंट एक्सपोज़र वाला केवल-आंतरिक होस्ट भी उतना ही महत्वपूर्ण है -- इसे बस पैर जमाने के लिए इंटरनेट-फेसिंग के बजाय किसी आंतरिक यूज़र, कॉन्ट्रैक्टर, या समझौता किए गए आंतरिक ऐप की आवश्यकता होती है। "इंटरनेट-फेसिंग नहीं" को "कम प्राथमिकता" मत समझिए।

वास्तव में कम गंभीरता:

• सिंगल-टेनेंट, कोई अविश्वसनीय गेस्ट, यूज़र, या ऐप नहीं -- एकमात्र "हमलावर" आप ही होंगे, इसलिए वास्तविक दुनिया का जोखिम बहुत कम है। फिर भी पैच करना उचित है ताकि भविष्य में कोई असंबंधित समझौता इसमें श्रृंखलाबद्ध न हो सके।
• कोई vIOMMU नहीं -- एडवाइज़री के अनुसार, VM-एस्केप पथ के लिए विशेष रूप से vIOMMU-सक्षम सेटअप आवश्यक है; इसके बिना, प्रभाव संभवतः गेस्ट/होस्ट सीमा पार करने के बजाय कर्नेल के भीतर स्थानीय privesc तक सीमित रहेगा।

क्या WAF मदद करता है? इस बग के विरुद्ध सीधे तौर पर नहीं -- एक WAF HTTP(S) ट्रैफ़िक का निरीक्षण करता है, और यह बग कर्नेल के vhost मेटाडेटा-कैश पथ में है, रिक्वेस्ट पार्सिंग में नहीं। यह भेद्यता के लिए एक्सपोज़र पथ में ही नहीं है।

जहाँ WAF वास्तव में मायने रखता है वह एक कदम पहले है: सबसे आम वास्तविक श्रृंखला है वेब ऐप RCE → गेस्ट के भीतर कोड एग्ज़िक्यूशन → vhost एक्सप्लॉइट → होस्ट एस्केप → हर अन्य टेनेंट तक लेटरल मूवमेंट। एक WAF (या अन्य वेब-सुरक्षा नियंत्रण) उस वेब-ऐप RCE को रोक सकता है जो हमलावर को उसका प्रारंभिक पैर जमाने का अवसर देता है, जिससे वे इस बग की पूर्व-शर्त तक पहुँचने से पहले ही रुक जाते हैं। तो: vhost बग के लिए स्वयं अप्रासंगिक, लेकिन इसकी पूर्व-शर्त तक पहुँचने के सबसे आम मार्गों में से एक के लिए प्रासंगिक।

जो वास्तव में जोखिम को शुरू से अंत तक कम करता है: कर्नेल को पैच करना, जहाँ आवश्यकता न हो वहाँ vhost ऑफ़लोड अक्षम करना, libvirt/Proxmox मैनेजमेंट पोर्ट को इंटरनेट पर उजागर न करना, गेस्ट के भीतर चलने वाले वेब ऐप्स/सेवाओं को हार्डन करना (उस प्रारंभिक RCE की संभावना कम करना), और टेनेंट-आइसोलेशन हार्डनिंग (seccomp, namespaces) ताकि किसी भी पैर जमाने को प्राप्त करना कठिन हो जाए।

डिज़ाइन के अनुसार केवल-पैसिव क्यों

उन सिस्टमों को सक्रिय रूप से पोर्ट-स्कैन या SSH-प्रोब करना जो आपके नहीं हैं या जिनके लिए आपके पास लिखित प्राधिकरण नहीं है, अधिकांश न्यायक्षेत्रों में अनधिकृत पहुँच है (EU में, यह Directive 2013/40/EU के कार्यान्वयनों के अंतर्गत आता है; चेक कानून इसे § 230 trestního zákoníku के अंतर्गत कवर करता है) और अधिकांश होस्ट्स/क्लाउड्स के लिए ToS का उल्लंघन है -- अच्छे इरादे की परवाह किए बिना। यह रेपो केवल वही डेटा पढ़ता है जो तृतीय-पक्ष स्कैनरों ने पहले ही अपने स्वयं के प्राधिकरण के अंतर्गत एकत्र किया और प्रकाशित/बेचा है। देखें SCOPE.md।

यदि आप किसी विशिष्ट निष्कर्ष को सत्यापित करना चाहते हैं (पुष्टि करें कि कोई होस्ट वास्तव में भेद्य है, न कि केवल "उजागर दिखता है"), तो इसके लिए स्वामी की अनुमति आवश्यक है -- डिस्क्लोज़र टेम्पलेट देखें, जो ठीक इसी की माँग करता है।