PaperCut की दो कमजोरियों पर सक्रिय हमला—Emergency Patch 2 ही जाँचें
PaperCut NG और PaperCut MF की दो कमजोरियों—CVE-2026-81578 और CVE-2026-82078—का सक्रिय हमलों में इस्तेमाल दर्ज हुआ है। कनाडाई साइबर सुरक्षा केंद्र की 28 अगस्त 2026 की सलाह के अनुसार संस्करण 24, 25 और 26 की वे स्थापनाएँ प्रभावित हैं जिन पर Emergency Patch Release 2 नहीं लगाया गया है।
प्रशासकों के लिए तत्काल उत्तर स्पष्ट है: केवल यह देखना पर्याप्त नहीं कि कोई “आपात सुधार” लगाया गया था। प्रत्येक PaperCut NG/MF नोड पर Emergency Patch Release 2 की अलग पुष्टि करें, क्योंकि पहला आपात सुधार बाद में मिले वैकल्पिक हमले के रास्ते को पूरी तरह बंद नहीं करता। सुधार की स्थिति और पैच लगने से पहले संभावित भेदन की जाँच भी अलग-अलग करनी होगी।
दो कमजोरियाँ सर्वर पर कोड चलाने का रास्ता बना सकती हैं
CVE-2026-81578 वेब-आधारित प्रबंधन अंतरफलक में अभिगम नियंत्रण से जुड़ी कमजोरी है। कुछ परिस्थितियों में बिना प्रमाणीकरण वाला दूरस्थ अनुरोध प्रशासनिक क्रिया शुरू करके तंत्र-विन्यास बदल सकता है। इसलिए इंटरनेट से सीधे उपलब्ध प्रबंधन अंतरफलक सबसे अधिक प्राथमिकता वाला जाँच-बिंदु है।
CVE-2026-82078 डेटाबेस संयोजक द्वारा गतिशील Java श्रेणी लोड करने के तरीके से संबंधित है। तंत्र-विन्यास पर नियंत्रण मिलने के बाद हमलावर अनुप्रयोग के श्रेणी-पथ पर उपलब्ध दुर्भावनापूर्ण Java बाइटकोड को PaperCut सर्वर प्रक्रिया के अधिकारों के साथ चला सकता है। NHS England की तकनीकी चेतावनी अभिगम नियंत्रण पार करने, विन्यास बदलने और दूरस्थ कोड निष्पादन तक पहुँचने के इस संयुक्त जोखिम को दर्ज करती है।
व्यावहारिक रूप से घटना को केवल किसी प्रशासनिक सेटिंग में अनधिकृत बदलाव मानना गलत होगा। पहली कमजोरी आवश्यक नियंत्रण तक पहुँच बना सकती है, जबकि दूसरी उस पहुँच को सर्वर पर मनमाना कोड चलाने में बदल सकती है। सफल हमला प्रिंट-प्रबंधन सेवा तक सीमित न रहकर उस सर्वर और उससे जुड़े संसाधनों को प्रभावित कर सकता है।
पहला आपात सुधार पर्याप्त क्यों नहीं है
PaperCut ने पहले आपात सुधार के बाद सुरक्षा शोधकर्ताओं से मिले अतिरिक्त निष्कर्षों के आधार पर दूसरा सुधार जारी किया। PaperCut के अद्यतन सुरक्षा बुलेटिन में संस्करण 24, 25 और 26 के लिए Emergency Patch Release 2 चुनने तथा पहला आपात सुधार लगा चुके ग्राहकों को भी नया पैकेज लगाने का निर्देश है।
यही वह अंतर है जो सामान्य संस्करण-पट्टी में आसानी से छूट सकता है। “Emergency Patch” लिखा पुराना पैकेज, पहले सुधार की सफल स्थापना या सेवा का सामान्य रूप से चलना दूसरे सुधार का प्रमाण नहीं है। सत्यापन में उत्पाद, प्रमुख संस्करण, संचालन तंत्र और पैकेज की सुधार-संख्या—चारों का मेल आवश्यक है।
संस्करण 23 या उससे पुराने संस्करण दूसरे आपात सुधार के लक्षित पैकेजों में शामिल नहीं हैं। ऐसी स्थापना को किसी असंगत पैकेज से सुधारित मानने के बजाय विक्रेता द्वारा समर्थित नवीनतम संस्करण में उन्नत करने की योजना चाहिए। यह काम प्रभावित नई शाखाओं पर दूसरा सुधार लगाने की प्राथमिकता को नहीं टालता।
चार चरणों में सुधार और बाहरी पहुँच जाँचें
- प्रभावित नोडों की सूची बनाएँ: PaperCut NG और MF के मुख्य अनुप्रयोग सर्वर, साइट सर्वर तथा द्वितीयक या प्रिंट सर्वर दर्ज करें। हर प्रविष्टि के सामने उत्पाद, प्रमुख संस्करण और संचालन तंत्र लिखें; केवल मुख्य सर्वर देखकर पूरी स्थापना को सुरक्षित न मानें।
- सही पैकेज की पुष्टि करें: संस्करण 24, 25 या 26 के अनुरूप Emergency Patch Release 2 पैकेज चुनें। डाउनलोड की SHA-256 जाँच-राशि को विक्रेता द्वारा प्रकाशित मान से मिलाएँ और प्रत्येक नोड के लिए पैकेज, स्थापना समय तथा पुनः आरंभ होने की स्थिति का अभिलेख रखें।
- लागू स्थिति को नोड-दर-नोड जाँचें: स्थापना प्रक्रिया पूरी होने के साथ संबंधित सेवा के दोबारा शुरू होने और नोड के स्वस्थ लौटने की पुष्टि करें। मुख्य अनुप्रयोग सर्वर पर सुधार लगना साइट सर्वर या द्वितीयक सर्वर की स्थिति का प्रमाण नहीं है।
- इंटरनेट से पहुँच घटाएँ: पैकेज सत्यापन पूरा होने तक प्रबंधन अंतरफलक को विश्वसनीय आंतरिक IP पतों या आवश्यक प्रशासनिक नेटवर्क तक सीमित करें। फ़ायरवॉल या समकक्ष अभिगम नियम से अविश्वसनीय बाहरी पतों को रोकना पैच का विकल्प नहीं, बल्कि हमले की उपलब्ध सतह घटाने का अस्थायी उपाय है।
जाँच का परिणाम दो स्पष्ट सूचियों में रखना उपयोगी है: किन नोडों पर दूसरा आपात सुधार सत्यापित हो चुका है और किन पर कार्रवाई बाकी है। इससे पहले सुधार को गलती से अंतिम सुधार मानने, किसी सहायक नोड को छोड़ने या असंगत पैकेज लगाने का जोखिम घटता है।
सुधार लगने और पहले हुए भेदन की पुष्टि अलग करें
दूसरा सुधार सफलतापूर्वक लग जाना भविष्य के शोषण का जोखिम घटाता है, लेकिन इससे यह सिद्ध नहीं होता कि सर्वर पहले सुरक्षित था। घटना-जाँच में PaperCut प्रक्रिया से शुरू हुई असामान्य उप-प्रक्रियाएँ, अप्रत्याशित तंत्र-विन्यास परिवर्तन, हटाई गई फ़ाइलें और हमले की अवधि से जुड़े नेटवर्क अभिलेख अलग से देखने होंगे।
CERT-FR की अद्यतन चेतावनी में अचानक छोटा, गायब या मिटाया गया server.log, संदिग्ध डेटाबेस संयोजक त्रुटियाँ और PaperCut की pc-app.exe प्रक्रिया से शुरू हुई आदेश-प्रक्रिया जैसे संकेत दिए गए हैं। सूची में “No suitable driver found for jdbc:no:x” जैसी विशिष्ट त्रुटि भी शामिल है, लेकिन इनमें से कोई संकेत न मिलना अपने आप में हमले की अनुपस्थिति सिद्ध नहीं करता।
हमलावर स्थानीय फ़ाइल या लॉग मिटा सकता है। इसलिए मौजूदा सर्वर अभिलेखों के साथ केंद्रीकृत सुरक्षा चेतावनियाँ, नेटवर्क लॉग और सुरक्षित पुरानी प्रतियों की समयरेखा मिलानी चाहिए। संदिग्ध उप-प्रक्रिया या मिटाए गए अभिलेख मिलने पर नोड को केवल सुधार लगाकर तुरंत सेवा में लौटाना पर्याप्त घटना-प्रतिक्रिया नहीं होगी।
भेदन का ठोस संदेह होने पर उपलब्ध साक्ष्य सुरक्षित करना, प्रभावित अनुप्रयोग सर्वर को अलग करना और संगठन की घटना-प्रतिक्रिया प्रक्रिया सक्रिय करना आवश्यक है। दोबारा निर्माण या स्वच्छ प्रति बहाल करने का निर्णय स्थानीय साक्ष्य और संगठन की पुनर्प्राप्ति नीति के आधार पर होना चाहिए।
31 अगस्त तक क्या स्पष्ट है और क्या अज्ञात है
31 अगस्त 2026 तक दोनों कमजोरियों का सक्रिय शोषण दर्ज है और प्रभावित संस्करण 24–26 के लिए आवश्यक आपात सुधार Emergency Patch Release 2 है। पहला सुधार लगा होना पर्याप्त सुरक्षा प्रमाण नहीं है; प्रत्येक नोड पर सुधार-संख्या की पुष्टि और पुराने भेदन की स्वतंत्र जाँच जरूरी है।
सार्वजनिक परामर्शों में किसी विशिष्ट हमलावर समूह या अभियान को आधिकारिक रूप से जिम्मेदार नहीं ठहराया गया है। आगे की महत्वपूर्ण जानकारी स्थायी सामान्य संस्करण, नए सत्यापित भेदन-संकेत और प्रभावित घटनाओं के दायरे से जुड़ी होगी। तब तक प्रशासकों को दो अलग निष्कर्ष दर्ज रखने चाहिए: दूसरा आपात सुधार कहाँ सत्यापित है और उपलब्ध साक्ष्य में सुधार से पहले हुए हमले के संकेत कहाँ मिले हैं।
यह भी पढ़ें:
हमारे न्यूज़लेटर की सदस्यता लें
Web3, AI और क्रिप्टो की नवीनतम खबरें सीधे अपने इनबॉक्स में पाएँ।