नकली CVE, AI-जनित रिपोर्टें और सत्यापन की ज़रूरत

कमज़ोरियों की विश्वसनीय लगने वाली रिपोर्टें तैयार करना अब सस्ता होता जा रहा है, जिससे सॉफ़्टवेयर का रखरखाव करने वालों और सुरक्षा टीमों के सामने चुनौतियाँ बढ़ रही हैं। जुलाई 2026 में SQLite के संबंध में छह सामान्य कमज़ोरियों और जोखिमों (CVE) को प्रकाशित किया गया, जिनमें से दो को 9.8 की गंभीरता रेटिंग मिली। ये रिपोर्टें विश्वसनीय लग रही थीं: उनमें मेमोरी सुरक्षा से जुड़ी खामियों का वर्णन था और तकनीकी स्पष्टीकरणों के साथ अवधारणा के प्रमाण वाला कोड भी शामिल था।

लेकिन JFrog के शोधकर्ताओं ने पाया कि इन रिपोर्टों में जिन कुछ फ़ंक्शनों का ज़िक्र था, वे प्रभावित संस्करणों में मौजूद ही नहीं थे। इतना ही नहीं, अवधारणा के प्रमाण (PoC) में से किसी ने भी बताई गई कमज़ोरियों को दोहराकर नहीं दिखाया। SQLite के अपने CVE पृष्ठ पर अब कहा गया है कि ये छह रिपोर्टें बग नहीं हैं; बाद में CVE रिकॉर्ड खारिज कर दिए गए।

यह समस्या SQLite तक ही सीमित नहीं है। curl का रखरखाव करने वाले Daniel Stenberg ने पिछले साल अनुमान लगाया था कि आने वाली सुरक्षा रिपोर्टों में से लगभग 20% AI-जनित कचरा थीं। GitHub के CVE नंबरिंग प्राधिकरण (CNA) को मई 2026 में लगभग 4,000 CVE अनुरोध मिले; यह साल-दर-साल संख्या में करीब 10 गुना वृद्धि है। GitHub ने इस वृद्धि के लिए AI को ज़िम्मेदार नहीं ठहराया और न ही सबमिशन की गुणवत्ता में गिरावट की बात कही, लेकिन संख्या में हुई भारी बढ़ोतरी कमज़ोरियों के खुलासे की प्रक्रिया पर बढ़ते दबाव को रेखांकित करती है।

AI की मदद से कमज़ोरियों के विस्तृत दावे करना आसान होता जा रहा है, लेकिन यह तय करने में समय लगता है कि ये दावे सही हैं या नहीं। और जब कोई CVE सुरक्षा फ़ीड और सार्वजनिक डेटाबेस में दर्ज हो जाता है, तो मूल रिकॉर्ड को ठीक करने भर से यह सुनिश्चित नहीं होता कि उसकी हर प्रति भी ठीक कर दी जाएगी। इससे रिपोर्ट की गई कमज़ोरी और तकनीकी रूप से सत्यापित कमज़ोरी के बीच फ़र्क करना लगातार ज़्यादा ज़रूरी होता जा रहा है।

“नकली” CVE क्या होता है?

लोग अक्सर “नकली CVE” शब्द का इस्तेमाल ऐसे CVE के लिए करते हैं, जिसकी रिपोर्ट संभवतः ग़लत तरीके से की गई हो। लेकिन नकली होने का मतलब यह नहीं कि किसी ने जान-बूझकर गुमराह किया हो। ऐसा स्थिर विश्लेषण के कारण हो सकता है, जो किसी सत्यापन जाँच को नज़रअंदाज़ कर दे या इनपुट को हमलावर के नियंत्रण में मानने की ग़लत व्याख्या करे। किसी रिपोर्ट में वास्तविक फ़ंक्शन का विस्तृत वर्णन हो सकता है, लेकिन हमले का अमान्य रास्ता बताया गया हो। यदि रिपोर्ट की गई स्थिति वास्तव में कमज़ोरी नहीं थी, तो पहचानकर्ता (CVE ID) आवंटित होने के बाद भी उसे रद्द किया जा सकता है। यह जान-बूझकर गढ़ी गई रिपोर्ट से अलग बात है।

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

नकली CVE समस्या क्यों हैं

हम जो समस्याएँ देख रहे हैं, उनमें से एक यह है कि लोग निष्कर्षों की ठीक से पुष्टि किए बिना AI से कमज़ोरियों की रिपोर्टें तैयार करवा रहे हैं। इन रिपोर्टों में विस्तृत तकनीकी स्पष्टीकरण, कोड के संदर्भ और यहाँ तक कि PoC भी हो सकते हैं, जिससे वे विश्वसनीय लग सकती हैं। लेकिन SQLite के CVE के मामले में हमने देखा कि जिन कुछ फ़ंक्शनों का संदर्भ दिया गया था, वे प्रभावित संस्करणों में मौजूद ही नहीं थे।

GitHub ने 2026 में कमज़ोरियों से जुड़ी सबमिशन में उल्लेखनीय वृद्धि की जानकारी दी, हालाँकि उसने इस वृद्धि का कारण AI को नहीं बताया और न ही सबमिशन की गुणवत्ता में गिरावट की बात कही। चिंता यह है कि रिपोर्टों की संख्या बढ़ने के साथ उनकी जाँच-पड़ताल में लगने वाला काम भी बढ़ता है—चाहे निष्कर्ष सही हों या नहीं।

जिन लोगों ने कमज़ोरियों की रिपोर्टों की छँटाई की है, वे इस काम की व्यावहारिक कठिनाई आसानी से समझ सकते हैं। AI मॉडल किसी संदिग्ध API कॉल की पहचान कर सकता है, किसी संभावित हमले का मोटा खाका बना सकता है और तेज़ी से पेशेवर दिखने वाली रिपोर्ट तैयार कर सकता है। यह तय करने के लिए कि वह हमला वास्तव में संभव है या नहीं, सटीक रिलीज़ की जाँच करनी पड़ सकती है, नियंत्रण प्रवाह का पता लगाना पड़ सकता है, यह समझना पड़ सकता है कि डेटा फ़ंक्शन तक कैसे पहुँचता है, परीक्षण का परिवेश बनाना पड़ सकता है और कथित हमले को चलाकर देखना पड़ सकता है। रिपोर्ट सही हो या ग़लत, प्रक्रिया वही रहती है और इसमें काफ़ी खर्च हो सकता है।

नकली CVE से प्रतिष्ठा को भी नुकसान पहुँच सकता है। कमज़ोरी की घोषणा स्कैनर फ़ीड, सुरक्षा डेटाबेस और खोज परिणामों में तेज़ी से फैल सकती है। लेकिन बाद में किया गया सुधार शायद उतनी दूर तक न पहुँचे। रिपोर्ट पर विवाद हो जाने या उसे खारिज कर दिए जाने के बाद भी, जिन ग्राहकों ने मूल रिपोर्ट देखी थी, उनके सामने विक्रेताओं को सफ़ाई देनी पड़ सकती है।

एक और जोखिम यह है कि ग़लत रिपोर्टों की जाँच में टीमों का समय लगने से वास्तविक कमज़ोरियों पर ध्यान नहीं जा पाता या उनकी जाँच में देरी होती है। जब रखरखाव करने वालों और सुरक्षा टीमों के संसाधन सीमित हों, तो झूठे सकारात्मक नतीजे को ग़लत साबित करने में बिताया गया हर घंटा ऐसा समय होता है जो किसी वास्तविक सुरक्षा समस्या की जाँच में लगाया जा सकता था।

स्वचालन से मुकाबला

रिपोर्टों की नई बाढ़ से निपटने के लिए कई जाँचकर्ता अब भी हाथ से छँटाई कर रहे हैं, लेकिन यह तरीका टिकाऊ नहीं है। किसी कमज़ोरी के दावे को वास्तव में प्रभावित रिलीज़ और कॉन्फ़िगरेशन के आधार पर सत्यापित करने में स्वचालन काफ़ी मददगार साबित हो सकता है। पूछने के लिए ये पाँच सवाल हैं:

• क्या कॉन्फ़िगरेशन और अनुमतियों सहित, हमले की पूर्वशर्तें विश्वसनीय हैं?
• क्या कथित फ़ंक्शन प्रभावित संस्करण में मौजूद है?
• क्या कोई हमलावर उस कोड तक पहुँच सकता है जिसमें भेद्यता है? पता लगाएँ कि क्या संबंधित कोड प्रभावित परिस्थितियों में चल सकता है और क्या कोई हमलावर ऐसा इनपुट दे सकता है जो उस तक पहुँचे।
• क्या परीक्षक नियंत्रित परीक्षण में या PoC के ज़रिए उस व्यवहार को दोहरा सकते हैं?
• क्या देखा गया व्यवहार सलाह-पत्र में बताए गए सुरक्षा प्रभाव को दर्शाता है?

एजेंट-आधारित उपकरण परीक्षण परिवेश बना सकते हैं, कोड के रास्तों का विश्लेषण कर सकते हैं, PoC तैयार कर सकते हैं और समीक्षा के लिए निष्पादन के साक्ष्य दर्ज कर सकते हैं। वे हर दावे का अपने-आप समाधान नहीं कर सकते। भले ही कोई भेद्यता वास्तविक हो, परिवेश अधूरा होने या ट्रिगर सही न होने पर PoC विफल हो सकता है। परीक्षक किसी क्रैश को दोहरा सकते हैं, लेकिन इससे दावे की शोषण-क्षमता साबित नहीं होती। इन्हीं सीमाओं के कारण मानवीय निर्णय अब भी बेहद अहम है। फिर भी, ये उपकरण टीमों को ऐसा जवाब पाने के करीब ला सकते हैं जिसे दोहराकर सत्यापित किया जा सके—इससे पहले कि कोई रिपोर्ट इंजीनियरिंग, भेद्यता प्रबंधन और ग्राहक सहायता से जुड़े लोगों का और समय ले।

CVE पारितंत्र में सूचनाओं की बाढ़ से निपटना

कोई भी संक्षिप्त नीति नकली CVE की समस्या को जादुई ढंग से हल नहीं कर सकती। लेकिन जमा किए गए दावों के साथ अधिक ठोस साक्ष्य अनिवार्य करना और उन्हें दोहराकर सत्यापित किए जाने की स्थिति को अधिक स्पष्ट बनाना मददगार होगा। विवादित रिकॉर्ड से निपटने के तरीके स्पष्ट करना और उनसे आगे प्रसारित हुए डेटा को तेज़ी से दुरुस्त करना भी उपयोगी होगा। शोधकर्ताओं को चाहिए कि वे AI की मदद से मिले अपने निष्कर्ष जमा करने से पहले उनकी पुष्टि करें।

सुरक्षा टीमों और विक्रेताओं को साक्ष्यों की जाँच पर ध्यान देना चाहिए। CVE का गंभीरता स्कोर यह नहीं बताता कि उनके परिवेश में भेद्यता वाला रास्ता सुलभ है या नहीं। PoC का विफल होना इस बात का प्रमाण नहीं कि सब कुछ ठीक है। और CVE ID मिल जाने से टीमों को किसी समस्या को समझने के लिए ज़रूरी तकनीकी जाँच करने की ज़िम्मेदारी से छूट नहीं मिलती।

AI भेद्यताएँ खोजने की क्षमता बढ़ा रहा है, और साथ ही ऐसे दावे गढ़ना भी संभव बना रहा है जो विश्वसनीय दिखते हैं, लेकिन गलत होते हैं। लगातार बढ़ती रिपोर्टों के इस दौर में संगठनों को सत्यापन में निवेश करना होगा। इसमें परीक्षण तैयार करना, नतीजों को दोहराकर देखना, मान्यताओं की जाँच करना और साक्ष्यों का आकलन आसान बनाना शामिल है। एजेंट-आधारित सुरक्षा परीक्षण इस क्षेत्र में अहम भूमिका निभा सकता है।