"अभी तक कोई नुकसान की पुष्टि नहीं" फिर भी निश्चिंत नहीं हो सकते - PHP की कमजोरी के कारण साइट बंद, वर्तमान में क्या हो रहा है

हमेशा उपयोग की जाने वाली साइट अचानक खुलना बंद हो गई। लेकिन अगर इसका कारण साइबर हमले के कारण नष्ट होना नहीं बल्कि हमले से बचाने के लिए अस्थायी रोकथाम था, तो आप इसे कैसे समझेंगे?

वेबसाइट और वेब एप्लिकेशन को सपोर्ट करने वाली प्रोग्रामिंग भाषा PHP में गंभीर कमजोरी का पता चला है, जिसके चलते जर्मनी में प्रशासनिक संस्थानों ने एहतियातन साइट को बंद कर दिया।

BUSINESS-PANORAMA द्वारा प्रकाशित 22 अक्टूबर के AFP लेख के अनुसार, जर्मनी के संघीय सूचना सुरक्षा कार्यालय (BSI) ने बताया कि इस कमजोरी का दुरुपयोग करने के मामले उस समय तक पुष्टि नहीं की गई थी। हालांकि, यह नहीं कहा जा सकता कि हमले सफल नहीं हुए होंगे।

इस समाचार को पढ़ते समय महत्वपूर्ण बात यह है कि, "नुकसान की पुष्टि नहीं हुई" और "सुरक्षा की पुष्टि हुई" एक ही बात नहीं है।

BSI की घोषणा "समाप्ति घोषणा" नहीं है

मूल लेख के अनुसार, BSI ने 21 अक्टूबर की दोपहर को PHP की कमजोरी के बारे में चेतावनी दी और उसी दिन 16:00 बजे सुरक्षा अपडेट की योजना बनाई गई थी।

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

अगले दिन 22 तारीख को, BSI ने बताया कि एहतियातन बंद की गई संघीय प्रशासनिक संस्थानों की अधिकांश साइटें बहाल हो गई हैं। बिना किसी उल्लंघन के रिपोर्ट की स्थिति के बारे में, कई ऑपरेटरों ने अनुशंसा के अनुसार अपडेट पूरा कर लिया हो सकता है।

हालांकि, यह ज्ञात जानकारी के आधार पर एक मूल्यांकन है। यह सभी साइटों की जांच खत्म करने और यह सुनिश्चित करने का दावा नहीं करता कि कोई घुसपैठ नहीं हुई।

साइट की बहाली उपयोगकर्ताओं के लिए अच्छी खबर है, लेकिन केवल इसी आधार पर समस्या के पूरी तरह से हल होने का निर्णय लेना जल्दबाजी होगी।

समस्या वेबसाइट के "आधार" में है

इस बार, PHP पक्ष ने "PHP2Shell" नामक दो गंभीर कमजोरियों को सुधारा है। पहचान संख्या CVE-2026-109618 और CVE-2026-109619 है। गंभीरता को दर्शाने वाली CVSS v4.0 की रेटिंग दोनों के लिए 9.2 है, और इसे "Critical" के रूप में वर्गीकृत किया गया है।

PHP Foundation ने 21 अक्टूबर को घोषणा की कि जब शर्तें पूरी होती हैं, तो एक अनधिकृत हमलावर PHP को चलाने वाले सर्वर पर कोड चला सकता है, इस समस्या को ठीक कर दिया गया है।

सामान्य उपयोगकर्ताओं के लिए PHP एक ऐसी चीज है, जिसे वे आमतौर पर ध्यान नहीं देते। यह स्क्रीन के डिज़ाइन या लेख के बजाय, उसके पीछे की प्रक्रिया को संभालता है।

इसलिए, इस बार की प्रतिक्रिया पर विचार करते समय, केवल साइट की उपस्थिति या प्रबंधन स्क्रीन पर ध्यान केंद्रित करना पर्याप्त नहीं है। एप्लिकेशन को चलाने वाले आधार की सुधार स्थिति की जांच करना आवश्यक है।

PHP Foundation द्वारा प्रकाशित सुधारित संस्करण PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 हैं। ऑपरेटरों को अपने वातावरण को प्रदान करने वाले सेवा प्रदाताओं की सलाह सहित, सुधार की स्थिति की पुष्टि करनी होगी।

"हमले का प्रयास" और "घुसपैठ की सफलता" को भ्रमित न करें

BSI के बारे में मूल लेख के साथ-साथ AWS द्वारा किए गए अवलोकन रिपोर्ट को भी ध्यान में रखना चाहिए।

AWS ने हमले का अवलोकन करने के लिए "MadPot" नामक प्रणाली के माध्यम से 17 अक्टूबर को PHP2Shell के दुरुपयोग के प्रयास की पुष्टि की। यह समय सीमा उस समय से पहले की है जब कमजोरी का विवरण सार्वजनिक किया गया था।

दूसरी ओर, AWS ने कहा कि यह स्पष्ट नहीं है कि अवलोकित प्रयास वास्तविक सिस्टम पर सफल हुआ या नहीं।

इसका मतलब है कि BSI के "दुरुपयोग के मामलों की पुष्टि नहीं" की रिपोर्ट और AWS के "हमले के प्रयास का अवलोकन" की रिपोर्ट अलग-अलग हैं। केवल एक पक्ष को उठाकर "कोई हमला नहीं हुआ" या "बड़े पैमाने पर घुसपैठ की पुष्टि हुई" का निष्कर्ष नहीं निकाला जा सकता।

उपयोगकर्ता और ऑपरेटर दोनों के रूप में, कमजोरी की उपस्थिति, हमले का अवलोकन, घुसपैठ की सफलता, और सूचना के लीक की पुष्टि को अलग-अलग पढ़ने की आवश्यकता है।

सोशल मीडिया पर, त्वरित सुधार की सराहना की जा रही है

सोशल मीडिया और ऑनलाइन समुदायों में, केवल संकट की भावना ही नहीं, बल्कि रिपोर्ट को समझने के तरीके पर भी विचार व्यक्त किए जा रहे हैं।

Reddit के PHP समुदाय में पोस्ट किए गए "Has PHP2Shell borne fruit?" में, डर पैदा करने वाले लेखों और PHP की आलोचना का उल्लेख करते हुए, सुधार और प्रमुख लिनक्स वितरण की त्वरित प्रतिक्रिया की सराहना की गई।

यह, कमजोरी की गंभीरता से अलग, डेवलपर्स और वितरकों की प्रतिक्रिया को भी देखने का एक तरीका है। हालांकि, पोस्टर द्वारा किए गए नुकसान की स्थिति का मूल्यांकन, दुनिया की समग्र सुरक्षा को नहीं दर्शाता।

दूसरी ओर, मेल एलियास सेवा addy.io के बारे में Reddit पोस्ट में, PHP2Shell के जवाब में वेब सिस्टम को अस्थायी रूप से बंद करने की जानकारी साझा की गई। वहां बताया गया कि मेल वितरण जारी रहेगा और बाद में सुधार लागू करके बहाली की गई।

"सेवा का उपयोग नहीं किया जा सकता" कहकर समाप्त नहीं करना चाहिए, बल्कि यह बताना चाहिए कि क्या बंद है, क्या उपयोग किया जा सकता है, और कब बहाल किया गया। इस तरह की जानकारी साझा करना उपयोगकर्ताओं की चिंता को कम करने में सहायक हो सकता है।

यहां प्रस्तुत की गई जानकारी व्यक्तिगत पोस्ट पर आधारित है और यह सोशल मीडिया की व्यापक राय या जनमत सर्वेक्षण को नहीं दर्शाती।

साइट को बंद करने के निर्णय में भी स्पष्टीकरण की आवश्यकता होती है

एहतियातन रोकथाम उपयोगकर्ताओं के लिए असुविधा का कारण बनती है। यदि संपर्क नहीं किया जा सकता, प्रक्रियाएं नहीं बढ़ सकतीं, या उत्पाद नहीं खरीदे जा सकते, तो यह ऑपरेटरों के लिए भी बोझ बन सकता है।

फिर भी, जब तक सुधार नहीं हो जाता, बाहरी पहुंच को सीमित करने से हमलों के जोखिम को कम करने में मदद मिलती है। CERT-EU ने भी सुझाव दिया है कि यदि तुरंत सुधार नहीं किया जा सकता, तो सार्वजनिक नेटवर्क से इंटरनेट पर प्रकाशित एप्लिकेशन को अलग करने पर विचार करें।

इसलिए, केवल यह देखना कि साइट बंद है या नहीं, संचालन की गुणवत्ता का आकलन करने के लिए पर्याप्त नहीं है।

बल्कि, यह देखा जाना चाहिए कि क्या बंदी का कारण बताया गया, प्रभावित कार्यों को स्पष्ट किया गया, और अगली सूचना कहां देखी जा सकती है।

बिना किसी स्पष्टीकरण के गायब हुई साइट और उपयोगकर्ताओं की सुरक्षा के लिए उठाए गए कदमों की जानकारी देने वाली साइट के बीच, एक ही बंदी के बावजूद प्रतिक्रिया में अंतर होता है।

जापानी ऑपरेटरों के लिए भी यह "विदेशी समाचार" नहीं है

PHP की समस्या केवल जर्मन भाषा की साइटों से संबंधित नहीं है। यदि वही तकनीक उपयोग की जा रही है, तो जापानी व्यवसायों को भी इसकी जांच करनी होगी।

इस मामले में, पहली चुनौती विशेषज्ञ सेटिंग परिवर्तनों से अधिक, यह स्पष्ट करना हो सकता है कि उनकी साइट का प्रबंधन कौन कर रहा है।

क्या उत्पादन कंपनी जिम्मेदार है? क्या रेंटल सर्वर कंपनी आधार को अपडेट करती है? या फिर, क्या कंपनी के अपने कर्मचारी को प्रतिक्रिया देनी होगी?

जांच के लिए बिंदुओं को निम्नलिखित तरीके से व्यवस्थित किया जा सकता है।

• क्या साइट के परिचालन वातावरण में PHP का उपयोग किया जा रहा है?
• क्या इस कमजोरी के लिए सुधार लागू किया गया है?
• क्या अपडेट के लिए जिम्मेदार व्यक्ति और प्रतिक्रिया की पुष्टि का तरीका तय किया गया है?
• यदि तुरंत सुधार नहीं किया जा सकता, तो सार्वजनिकता को सीमित करने का निर्णय कौन करेगा?

"आउटसोर्सिंग कंपनी ने प्रतिक्रिया दी होगी" और "प्रतिक्रिया की पुष्टि की गई" के बीच बड़ा अंतर है।

इसके अलावा, CERT-EU ने यह भी बताया है कि PHP 8.1 से पहले के समर्थन समाप्त श्रृंखला के लिए, PHP परियोजना से कोई अपडेट उपलब्ध नहीं है। यदि पुराना वातावरण उपयोग में है, तो उस वातावरण के प्रदाता द्वारा सुधार की उपस्थिति और स्थानांतरण की आवश्यकता की जांच करनी होगी।

रक्षा उपाय होने पर भी, यह अपडेट का विकल्प नहीं हो सकता

कभी-कभी ऐसा लगता है कि हमला रोकने की प्रणाली स्थापित है, इसलिए चिंता की कोई बात नहीं है।

हालांकि, AWS ने इस समस्या के बारे में स्पष्ट किया है कि WAF द्वारा उपाय जोखिम को कम करने का एक सहायक उपाय है, और यह PHP के अपडेट का विकल्प नहीं है।

महत्वपूर्ण यह है कि किसी भी रक्षा उत्पाद का उपयोग करने का तथ्य नहीं, बल्कि यह कि वह उपाय इस समस्या को कितनी हद तक कवर करता है।

मूल लेख में यह भी बताया गया है कि BSI ने सामान्य उपयोगकर्ताओं को सलाह दी है कि वे अपने राउटर को बाहरी स्थानों से एक्सेस करने योग्य न बनाएं और डाउनलोड और गोपनीय जानकारी प्रदान करने में सावधानी बरतें।

यह सभी उपयोगकर्ताओं के उपकरणों या राउटरों पर इस कमजोरी का सीधा प्रभाव नहीं दर्शाता। ऑपरेटरों की प्रतिक्रिया और उपयोगकर्ताओं द्वारा रोजमर्रा में की जाने वाली सावधानियों को अलग-अलग देखना चाहिए।

"कुछ नहीं हुआ" को समर्थन देने का काम होता है

बड़ी चेतावनी के बाद यदि कोई बड़ा नुकसान नहीं होता, तो कुछ लोग सोच सकते हैं कि "शायद यह अधिक था"।

हालांकि, नुकसान के न दिखने के पीछे का कारण यह हो सकता है कि शुरुआती अपडेट या एहतियाती रोकथाम ने काम किया हो, या यह भी हो सकता है कि अभी तक इसकी पहचान नहीं हुई हो। वर्तमान जानकारी के आधार पर, इनमें से किसी एक को तय करना संभव नहीं है।

इस PHP कमजोरी ने यह दिखाया है कि साइट को चालू रखना ही संचालन की जिम्मेदारी नहीं है। जब आवश्यक हो, उसे रोकना, सुधार करना, स्थिति की पुष्टि करना, और उपयोगकर्ताओं को समझाना भी सेवा को समर्थन देने का काम है।

"नुकसान की पुष्टि नहीं" की खबर प्रतिक्रिया को रोकने का कारण नहीं हो सकता। जब तक आप अपने वातावरण की स्थिति की पुष्टि नहीं कर लेते, तब तक समाचार पढ़ने का वास्तविक तैयारी से कोई संबंध नहीं होता।

स्रोत

1. BUSINESS-PANORAMA／AFP（22 अक्टूबर 2026）
   BSI द्वारा दुरुपयोग के मामलों की पुष्टि नहीं करने, घुसपैठ की संभावना को खारिज नहीं करने, प्रशासनिक साइटों की बहाली की स्थिति, और सामान्य उपयोगकर्ताओं के लिए चेतावनी की नींव।
   https://business-panorama.de/news.php?newsid=6715602

2. PHP Foundation "Today's PHP Security Release, and How We're Strengthening PHP Security"
   21 अक्टूबर को सुधारित संस्करण का प्रकाशन और कमजोरी से उत्पन्न खतरे के बारे में आधिकारिक स्पष्टीकरण।
   https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/thephp.foundation

3. CERT-EU "Critical Vulnerabilities in PHP"
   CVE संख्या, गंभीरता, प्रभावित वातावरण, समर्थन समाप्त श्रृंखला, और सुधार या अलगाव के बारे में आधिकारिक सलाह।
   https://www.cert.europa.eu/publications/security-advisories/2026-018Critical Vulnerabilities in PHP

4. AWS Security Blog: MadPot द्वारा PHP2Shell अवलोकन रिपोर्ट
   प्रकाशन से पहले हमले के प्रयास और वास्तविक वातावरण में सफलता के बारे में अनिश्चितता का स्पष्टीकरण। "हमले के अवलोकन" और "नुकसान की पुष्टि" को अलग करने का आधार।
   https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/aws.amazon.com

5. AWS Security Blog: PHP2Shell के लिए WAF के शमन उपाय
   WAF की स्थिति और PHP के अपडेट की आवश्यकता के बारे में आधिकारिक दस्तावेज।
   https://aws.amazon.com/blogs/security/using-aws-waf-to-apply-mitigations-for-php2shell-rce-vulnerabilities-cve-2026-109618-and-cve-2026-109619/aws.amazon.com