PHP की दो गंभीर सुरक्षा खामियों (PHP2Shell) से दुनिया भर में सरकारी और निजी वेबसाइटें ऑफ़लाइन हुईं। जानिए घटनाक्रम, खामी का असर, पैच वाले PHP वर्ज़न और वेबसाइट मालिकों व आम यूज़र के लिए ज़रूरी कदम।
Table of Contents
Table of Contents
PHP security vulnerabilities
इंटरनेट पर रोज़ कोई न कोई सुरक्षा खामी सामने आती है, लेकिन कुछ मामले ऐसे होते हैं जो पूरी दुनिया की वेबसाइटों को एक साथ हिला देते हैं। 20 और 21 अक्टूबर 2026 को ऐसा ही हुआ। PHP नाम की प्रोग्रामिंग भाषा में दो बेहद गंभीर कमज़ोरियाँ उजागर हुईं, जिसके बाद कई देशों में सरकारी सेवाएँ, समाचार साइटें और अस्पतालों तक की वेबसाइटें एहतियातन बंद करनी पड़ीं। ब्रिटेन के साइबर सुरक्षा अधिकारी ने इसके पैमाने को “अभूतपूर्व” कहा, पर साथ ही यह भी कहा गया कि अब तक किसी सफल सेंधमारी के संकेत नहीं मिले।
1. क्या हुआ: PHP की दो खामियाँ और घटनाक्रम
सबसे पहले यह समझें कि PHP क्या है। PHP एक सर्वर-साइड प्रोग्रामिंग भाषा है, यानी वह भाषा जो वेबसाइट के पीछे चलकर डेटा इकट्ठा करती है और उसे ऐसे रूप में पेश करती है जिसे आप ब्राउज़र में पढ़ सकें। PHP वेब डेवलपमेंट में इस्तेमाल होने वाली भाषा है और दुनिया भर की लाखों वेबसाइटें इसी पर चलती हैं। साइबर सुरक्षा कंपनी विज़ के हवाले से बताया गया कि PHP दुनिया की करीब 70 प्रतिशत वेबसाइटों को ताकत देता है। WordPress जैसे लोकप्रिय प्लेटफ़ॉर्म भी PHP पर ही बने हैं, इसलिए इस भाषा में आई कोई भी गंभीर खामी इंटरनेट के बहुत बड़े हिस्से को छू लेती है।
अब घटनाक्रम देखें, जो अलग-अलग रिपोर्टों में थोड़े अलग रूप में मिलता है पर मोटे तौर पर एक जैसा है। 20 अक्टूबर को PHP के रखवालों ने 9.2 गंभीरता वाली दो कमज़ोरियों की सूचना जारी की, और पैच करीब 12 घंटे बाद आने तय थे। इसी बीच खबर आई कि “PHP2Shell” नाम का एक एक्सप्लॉइट टूल ऑनलाइन उपलब्ध हो गया है, और उसके इस्तेमाल का वीडियो गाइड भी डाल दिया गया। इसी लीक ने पूरे मामले को आपातकाल में बदल दिया, क्योंकि पैच आने से पहले ही हमलावरों के पास हथियार पहुँच गया था।
21 अक्टूबर को हालात तेज़ी से बदले। ब्रिटेन के NCSC, अमेरिका की NSA, CERT-EU और ऑस्ट्रेलिया तथा जापान की एजेंसियों ने तुरंत पैच लगाने या सिस्टम ऑफ़लाइन करने की अपील की, और फ़िनलैंड, नीदरलैंड, फ़्रांस और डेनमार्क में कई साइटें बंद कर दी गईं। उसी दिन पैच भी आया। पैचस्टैक की रिपोर्ट के अनुसार PHP ने 13:52 UTC पर PHP 8.5.12, 8.4.27, 8.3.36 और 8.2.35 जारी किए, जिनसे दोनों खामियाँ ठीक होती हैं। यानी जिन्होंने अपने सर्वर पर इन या इनसे नए वर्ज़न नहीं लगाए हैं, वे अब भी जोखिम में हैं।
2. खामी असल में क्या है: आसान भाषा में
तकनीकी बारीकियों में जाए बिना इसे समझने की कोशिश करते हैं। सैंसेक की रिपोर्ट में इन्हें CVE-2026-109618 और CVE-2026-109619 के रूप में दर्ज किया गया है और कहा गया है कि ये PHP 5.4 या उसके बाद के हर वर्ज़न पर चल रहे वेब सर्वर पर असर डालती हैं। इसी स्रोत के अनुसार इन्हें खोजकर PHP को बताने वाली विज़ रिसर्च का कहना है कि PHP 5.4 तक के सभी वर्ज़न इन दोनों में से कम से कम एक समस्या से प्रभावित हैं। यानी बहुत पुराने सॉफ़्टवेयर पर चल रही साइटें भी निशाने पर हैं।
इन कमज़ोरियों का सबसे चिंताजनक पहलू यह है कि ये “अनऑथेंटिकेटेड रिमोट कोड एक्ज़ीक्यूशन” (RCE) की श्रेणी में आती हैं। इसका मतलब है कि कोई बाहरी व्यक्ति बिना लॉगिन किए, इंटरनेट से ही किसी सर्वर पर अपना कोड चलवा सकता है। यह साइबर सुरक्षा की सबसे खतरनाक श्रेणियों में गिना जाता है, क्योंकि कोड चलने के बाद हमलावर डेटा चुरा सकता है, वेबसाइट बदल सकता है या सर्वर पर कब्ज़ा जमाकर आगे के हमले कर सकता है। NCSC ने इसे ऐसी स्थिति बताया है जिसमें हमलावर मेमोरी को बिगाड़ने वाली स्थिति पैदा करता है और कुछ शर्तों के तहत बिना प्रमाणीकरण के रिमोट कोड चलाने तक पहुँच सकता है।
एक और बात ध्यान देने योग्य है। पैचस्टैक के अनुसार खामियाँ किसी एक ऐप में नहीं, बल्कि PHP इंटरप्रेटर में हैं, इसलिए पुराने PHP वर्ज़न पर चल रही कोई भी साइट असुरक्षित है, चाहे उसका अपना कोड कितना भी सुरक्षित क्यों न हो। यही कारण है कि समाधान ऐप के बजाय PHP को अपडेट करना है। शोधकर्ताओं ने Magento 2.4.9 समेत दस और PHP ऐप्लिकेशन पर बिना लॉगिन रिमोट कोड एक्ज़ीक्यूशन की पुष्टि की है। यहाँ एक अंतर साफ़ रखना चाहिए: यह शोधकर्ताओं द्वारा परीक्षण में खामी की पुष्टि है, असल हमलों में सेंधमारी का सबूत नहीं।
सैंसेक की रिपोर्ट एक और बात बताती है, जो आम पाठक के लिए चिंता की बात है। उसके मुताबिक इनमें से एक खामी अकेले भी मेमोरी लीक करती है, जो हार्टब्लीड जैसी समस्या की याद दिलाती है। यानी एक्सप्लॉइट के बिना भी सर्वर की मेमोरी का कुछ हिस्सा बाहर निकल सकता है। हार्टब्लीड 2014 की वह खामी थी जिसने कई सेवाओं के पासवर्ड और संवेदनशील डेटा के उजागर होने का खतरा पैदा किया था। दोनों की तुलना सिर्फ़ प्रकृति के लिहाज़ से है, असर की गहराई के लिहाज़ से नहीं, क्योंकि वह आकलन अभी चल रहा है।
3. कौन-सी सेवाएँ बंद हुईं और “कोई सेंध नहीं” का क्या मतलब है
इस खामी का सबसे दिखाई देने वाला असर वेबसाइटों का बंद होना रहा। दुनिया भर में कंपनियों, संगठनों और सरकारों ने खामी ठीक करते समय वेबसाइटें ऑफ़लाइन कर दीं। यूके के एक मंत्री के अनुसार 32 सरकारी सेवाएँ इस वैश्विक साइबर-सुरक्षा समस्या के कारण अनुपलब्ध रहीं। नीदरलैंड में NCSC-NL, रॉटरडैम बंदरगाह, Overheid.nl, कई अस्पताल और संसद की साइट प्रभावित बताई गईं, फ़्रांस में गृह मंत्रालय की वेबसाइटें और फ़िनलैंड में सरकारी आईटी प्रदाता वाल्टोरी की सेवाएँ एहतियातन बंद की गईं। डेनमार्क में स्कूल संवाद का राष्ट्रीय प्लेटफ़ॉर्म और फ़्रांस की स्थानीय प्रशासनिक वेबसाइटें भी अस्थायी रूप से बंद की गईं।
यहाँ यह समझना ज़रूरी है कि यह बंदी हमले के कारण नहीं, ज़्यादातर बचाव के कारण हुई। जब पैच तैयार न हो और एक्सप्लॉइट ऑनलाइन घूम रहा हो, तो सबसे सुरक्षित तरीका सिस्टम को इंटरनेट से हटा लेना है। CERT-EU ने सलाह दी कि जो संगठन तुरंत पैच नहीं लगा सकते, वे इंटरनेट-फेसिंग ऐप्लिकेशन को सार्वजनिक नेटवर्क से अलग करने पर विचार करें, और NCSC ने भी कुछ ऐसी ही सलाह दी। जिन साइटों को आपने इन दो दिनों में “मेंटेनेंस मोड” में देखा, उनके पीछे यही वजह रही होगी। मालवेयरबाइट्स ने भी कहा कि यूज़र इस दौरान ऐसी साइटें देख सकते हैं जो प्रशासकों के सुरक्षा अपडेट लगाने की वजह से मेंटेनेंस मोड में हैं।
अब वह सवाल, जो हेडलाइन में उठा था: क्या कोई सेंध लगी? NCSC के CTO ओली व्हाइटहाउस ने कहा कि पैमाना अभूतपूर्व है, पर एक साइबर सुरक्षा अधिकारी के अनुसार अब तक किसी भी सफल सेंध के संकेत नहीं हैं। दूसरी ओर हांगकांग की CERT एजेंसी HKCERT ने चेतावनी दी कि कमज़ोरियाँ “असल में इस्तेमाल हो रही हैं”। इन दोनों बयानों में विरोधाभास नहीं है। हमले की कोशिशें हो सकती हैं और फिर भी अब तक पुष्ट सफल सेंध की जानकारी न हो।
साथ ही, अलग-अलग समाचार स्रोतों में कुछ वेबसाइटों के “प्रभावित या बंद” होने की बात आई है, पर वे हमेशा सेंधमारी की पुष्टि नहीं करतीं। ऐसी घटनाओं में पूरी तस्वीर आने में अक्सर हफ़्ते या महीने लगते हैं, क्योंकि कई कंपनियाँ जाँच के बाद ही बताती हैं कि उनके सिस्टम में सेंध लगी थी या नहीं। इसलिए “अब तक कोई सेंध नहीं” को पक्का आश्वासन न मानें, बल्कि सावधानी का संकेत समझें।
4. पैच, समय-सीमा और एआई की भूमिका पर चर्चा
इस पूरे प्रकरण का एक दिलचस्प पहलू इसकी खोज से जुड़ा है। कंप्यूटरवीक्ली ने इन्हें “एआई द्वारा खोजी गई दो खामियाँ” कहा है। सैंसेक की समयरेखा के अनुसार 11 अगस्त 2026 को कैलिफ़ ने पहली खामी की सूचना PHP को दी, 24 अगस्त को विज़ रिसर्च ने इन्हें रिपोर्ट किया, 20 अक्टूबर को जानकारी लीक हुई और watchTowr ने रिमोट कोड एक्ज़ीक्यूशन की पुष्टि की, और 21 अक्टूबर को फ़िक्स जारी हुए।
यानी जिम्मेदार तरीके से सूचना देने की प्रक्रिया दो महीने से चल रही थी, पर प्रकटीकरण से पहले ही जानकारी बाहर आ गई। एक डेवलपर ब्लॉग में तो यहाँ तक दावा है कि फ्रंटियर एआई मॉडलों ने स्वतंत्र रूप से कोड का तर्क समझकर एक्सप्लॉइट तैयार किया और खामी खोजने से हमले तक की अवधि घट गई। ऐसे दावों को सावधानी से पढ़ें, क्योंकि बड़ी समाचार एजेंसियों ने खामी की खोज में एआई की भूमिका का विस्तृत ब्योरा नहीं दिया है और रिपोर्टों में अलग-अलग बातें आ रही हैं।
फिर भी, इस घटना से एक बड़ा सवाल उठता है। अगर एआई टूल कोड में छिपी खामियाँ तेज़ी से खोज सकते हैं, तो यह रक्षकों के लिए वरदान है, पर हमलावरों के लिए भी हथियार बन सकता है। सुरक्षा समुदाय में अब यह बहस है कि खामी की जानकारी बाहर आने और पैच तैयार होने के बीच का समय कैसे घटे। पारंपरिक “कोऑर्डिनेटेड डिस्क्लोज़र” में हफ़्ते या महीने लग जाते हैं, पर अगर एआई की मदद से कोई भी इसी रफ़्तार से खामी खोज सके, तो यह समय-सीमा बेमानी हो सकती है। इस पर अभी कोई सर्वमान्य हल नहीं है।
समय का दबाव पैच लगाने वालों पर भी पड़ा। एथिकल हैकर केन मंरो के अनुसार पैच लगाना कुछ-कुछ विंडोज़ अपडेट चलाने जैसा है। बयान सुनने में आसान लगता है, पर बड़ी संस्थाओं में यह उतना सरल नहीं होता। जिन पर सैकड़ों ऐप्लिकेशन और पुराने PHP वर्ज़न चल रहे हों, उन्हें पहले यह पता लगाना पड़ता है कि कहाँ-कहाँ PHP चल रहा है, फिर अपडेट से ऐप्लिकेशन के टूटने का जोखिम परखना पड़ता है।
इसीलिए एजेंसियों ने पहला कदम यही बताया है कि हर उस सिस्टम की पहचान करें जिस पर PHP चल रहा है, और इंटरनेट से जुड़े सिस्टम को प्राथमिकता दें।
5. वेबसाइट मालिकों और आम यूज़र के लिए
अगर आप वेबसाइट या ऑनलाइन स्टोर चलाते हैं
सबसे पहले पता करें कि आपकी साइट किस PHP वर्ज़न पर चल रही है। होस्टिंग के कंट्रोल पैनल, जैसे cPanel, या अपने डेवलपर से पूछ सकते हैं। फिर इन सुरक्षित वर्ज़नों में से अपनी शाखा का अपडेट लगवाएँ: PHP 8.5.12, 8.4.27, 8.3.36 या 8.2.35 (या इनसे नए वर्ज़न)। अगर आपकी साइट इनसे पुरानी शाखाओं, जैसे 7.x या उससे पुराने वर्ज़न पर चल रही है, तो अपने होस्टिंग प्रदाता से पूछें कि उस शाखा के लिए सुरक्षा पैच उपलब्ध है या नहीं, और न हो तो समर्थित वर्ज़न पर जाने की योजना बनाएँ। पुराने वर्ज़न पर चलते रहना अपने आप में जोखिम है।
अगर आप तुरंत अपडेट नहीं कर सकते और आपकी साइट संवेदनशील है, जैसे ऑनलाइन भुगतान या ग्राहकों का डेटा, तो एजेंसियों की सलाह के अनुसार साइट को मेंटेनेंस मोड में या ऑफ़लाइन रखने पर विचार करें, जब तक आप अपडेट न कर लें। इसके साथ पैच लगाने से पहले और बाद में लॉग देखें। अजीब अपलोड, अनजान फ़ाइलें, अचानक बने नए एडमिन खाते या सर्वर का असामान्य व्यवहार किसी सेंध का संकेत हो सकते हैं।
ऐसी स्थिति में केवल पैच लगाना काफ़ी नहीं, पूरी जाँच, पासवर्ड और कुंजियाँ बदलना और बैकअप से साफ़ वर्ज़न बहाल करना ज़रूरी हो सकता है। जहाँ सुरक्षा विशेषज्ञ उपलब्ध हों, वहाँ उनसे जाँच करवाना बेहतर है। यह लेख कोई एक्सप्लॉइट-निर्देश नहीं देता, और किसी भी तरह की जाँच केवल अपने या अधिकृत सिस्टम पर ही करें।
WordPress जैसे प्लेटफ़ॉर्म वाले मालिक अपने होस्ट से यह भी पूछें कि सर्वर-स्तर पर PHP अपडेट हुआ है या नहीं, क्योंकि प्लगइन और थीम अपडेट करने से यह समस्या हल नहीं होती। खामी सर्वर की भाषा में है, इसलिए समाधान भी वहीं का है।
अगर आप सिर्फ़ एक आम इंटरनेट यूज़र हैं
आपको सर्वर पैच नहीं करना है, यह जिम्मेदारी वेबसाइट चलाने वालों की है। फिर भी कुछ सावधानियाँ समझदारी भरी हैं।
पहली, अगर कोई साइट बंद या धीमी मिले, तो घबराएँ नहीं। हो सकता है वह अपडेट के कारण ऑफ़लाइन हो। दोबारा कोशिश करें, पर सरकारी सेवाओं जैसे ज़रूरी कामों के लिए आधिकारिक घोषणाएँ देख लें।
दूसरी, इस हफ़्ते फ़िशिंग से ज़्यादा सावधान रहें। ऐसी बड़ी घटनाओं के बाद ठग “अपना अकाउंट सुरक्षित करें” वाले नकली ईमेल, एसएमएस और लिंक भेजते हैं। किसी लिंक पर क्लिक करने के बजाय सीधे आधिकारिक वेबसाइट या ऐप खोलें। कोई भी वास्तविक संस्था ईमेल से आपका पासवर्ड, OTP या UPI पिन नहीं माँगती।
तीसरी, अपने महत्वपूर्ण खातों के पासवर्ड मज़बूत और अलग-अलग रखें, और दो-स्तरीय सत्यापन (2FA) चालू करें। अगर किसी सेवा ने कहा हो कि आपका डेटा प्रभावित हो सकता है, तो उसी सेवा का पासवर्ड बदल लें और जहाँ वही पासवर्ड दोबारा इस्तेमाल किया हो, वहाँ भी बदल दें।
चौथी, अपने फ़ोन, ब्राउज़र और ऐप्स को अपडेट रखें। इस खामी का असर सीधे आपके फ़ोन पर नहीं है, पर अपडेट रखना हर तरह के हमलों से बचाव की बुनियादी आदत है।
पाँचवीं, भारत के यूज़र और संस्थाएँ CERT-In (भारतीय कंप्यूटर इमरजेंसी रिस्पॉन्स टीम) की सूचनाओं पर नज़र रखें। इस समय मुझे इस खामी पर CERT-In की कोई विशिष्ट सूचना नहीं मिली, इसलिए उसकी वेबसाइट पर ताज़ा सलाह देखते रहें।
PHP2Shell प्रकरण एक चेतावनी है कि इंटरनेट का बड़ा हिस्सा कुछ साझा बुनियादी तकनीकों पर टिका है, और उनमें आई एक खामी करोड़ों वेबसाइटों को प्रभावित कर सकती है। अच्छी खबर यह है कि पैच जारी हो चुका है, एजेंसियाँ तेज़ी से सक्रिय रहीं और अब तक किसी सफल बड़ी सेंध की पुष्टि नहीं हुई है। बुरी खबर यह है कि एक्सप्लॉइट सार्वजनिक हो चुका है, हमलों की कोशिशों की रिपोर्टें हैं और जो वेबसाइटें अब तक अपडेट नहीं हुईं, वे जोखिम में हैं।
वेबसाइट मालिकों के लिए संदेश सरल है: PHP का सुरक्षित वर्ज़न लगाएँ, न लगा सकें तो साइट को सुरक्षित मोड में रखें, और लॉग की जाँच करें। आम यूज़र के लिए संदेश है: घबराएँ नहीं, पर फ़िशिंग से सावधान रहें और अपने खातों की बुनियादी सुरक्षा मज़बूत रखें। स्थिति तेज़ी से बदल रही है, इसलिए PHP की आधिकारिक सूचना और NCSC, CERT-EU तथा CERT-In जैसी एजेंसियों की ताज़ा सलाह देखते रहें।
डिस्क्लेमर: यह लेख केवल सामान्य जानकारी और जागरूकता के लिए है। घटना तेज़ी से बदल रही है, इसलिए कुछ विवरण बाद में अपडेट हो सकते हैं। किसी भी सिस्टम पर कदम उठाने से पहले अपने होस्टिंग प्रदाता या योग्य सुरक्षा विशेषज्ञ की सलाह लें।
1 thought on “PHP2Shell संकट: Breaking दुनिया की 70% वेबसाइटों को चलाने वाली PHP में गंभीर खामी, क्या है पूरा मामला और आप क्या करें”