PHP2Shell, PHP में मिली दो गंभीर कमजोरियों—CVE-2026-109618 और CVE-2026-109619—का सामूहिक नाम है। इनका फायदा उठाकर हमलावर बिना लॉगिन के प्रभावित सर्वर पर कोड चला सकता है। PHP ने 21 अक्टूबर 2026 को इनके लिए सुरक्षा अपडेट जारी किए। खतरे का आकलन करते समय एक जरूरी फर्क ध्यान में रखें: स्कैनिंग या हमले की कोशिशें, सफल सेंधमारी का प्रमाण नहीं होतीं।
4
7
18
PHP2Shell की खामियाँ क्या करती हैं?
ये कमजोरियाँ किसी एक वेबसाइट के प्लगइन या ऐप में नहीं, बल्कि PHP के मूल सॉफ़्टवेयर में हैं। एक खामी मेमोरी खत्म होने की स्थिति को संभालने से जुड़ी है; दूसरी पुराने ग्लोबल स्टेट से। खास परिस्थितियों में तैयार किया गया अनुरोध रिमोट कोड एक्ज़ीक्यूशन (RCE)—यानी दूर से सर्वर पर कोड चलाने—की गुंजाइश पैदा कर सकता है। इनमें से एक खामी संवेदनशील प्रोसेस मेमोरी भी उजागर कर सकती है।
4
11
कुछ रिपोर्टों के मुताबिक, दुनिया की 70% तक वेबसाइटें PHP का इस्तेमाल करती हैं। यह एक व्यापक अनुमान है—इसका मतलब यह नहीं कि हर PHP वेबसाइट प्रभावित थी या सभी पर जोखिम समान था। खतरा PHP के संस्करण, कॉन्फ़िगरेशन और इस बात पर निर्भर करता है कि कमजोर कोड-पथ तक पहुँचना संभव है या नहीं।
45
46
खोज, खुलासा और पैच की जल्दबाज़ी
रिपोर्टों में इन कमजोरियों को खोजने और उन पर काम करने का श्रेय Wiz, Calif और OpenAI की टीमों तथा शोधकर्ताओं को दिया गया है। कुछ कवरेज में शोध प्रक्रिया में AI की भूमिका का भी ज़िक्र है। उपलब्ध रिपोर्टें खोज की हर बारीकी की पुष्टि नहीं करतीं—मसलन, WordPress से Drupal पर जाने वाली किसी खास खोज-प्रक्रिया या हर CVE में अलग-अलग टीमों की सटीक भूमिका की।
14
45
रिपोर्टिंग के मुताबिक, मेमोरी संभालने से जुड़ी मूल समस्या पहले देखी गई थी, लेकिन उससे रिमोट कोड एक्ज़ीक्यूशन का व्यावहारिक रास्ता बाद में प्रदर्शित हुआ। किसी संदिग्ध बग को पहचान लेना और यह साबित करना कि उससे हमला किया जा सकता है—दो अलग बातें हैं।
22
38
योजनाबद्ध सार्वजनिक घोषणा से पहले जानकारी लीक हुई। इससे प्रतिक्रिया पर दबाव बढ़ा और पैच जारी करने की प्रक्रिया तेज़ हुई।
6
23 यह घटना दिखाती है कि जब खुलासा, जाँच और अपडेट लागू करने के लिए समय कम हो, तो साइबर सुरक्षा का मामला जल्दी ही सेवाओं के संचालन का मुद्दा भी बन सकता है।
पैच और हमले की रिपोर्टें क्या बताती हैं?
21 अक्टूबर को जारी किए गए फिक्स वाले PHP संस्करण थे: 8.2.35, 8.3.36, 8.4.27 और 8.5.12। सर्वर संचालकों को अपने होस्टिंग या ऑपरेटिंग-सिस्टम विक्रेता की सलाह भी देखनी चाहिए। कुछ विक्रेता मूल PHP संस्करण संख्या बदले बिना बैकपोर्ट के रूप में फिक्स देते हैं।
4
39
साइबर सुरक्षा कंपनियों ने खुलासे के आसपास स्कैनिंग या हमले की कोशिशें दर्ज कीं। Cloudflare से जुड़ी रिपोर्टिंग में कोशिशों की संख्या में तेज़ बढ़ोतरी का भी उल्लेख था। ऐसे आँकड़े किसी खास सेवा ने देखे गए अनुरोधों या कोशिशों की गिनती बताते हैं; इनसे यह पता नहीं चलता कि कितने सिस्टम में सफल सेंधमारी हुई।
5
36
सफल हमलों की पुष्टि को लेकर रिपोर्टों के आकलन अलग-अलग रहे। BBC ने 22 अक्टूबर तक किसी सफल शोषण की रिपोर्ट न होने की बात कही। बाद में Beazley की सलाह में व्यापक कोशिशों का ज़िक्र था, लेकिन बड़े पैमाने पर सफल शोषण की पुष्टि की जानकारी नहीं थी। Sansec ने भी अपना आकलन बदलकर कहा कि बड़े पैमाने पर शोषण की आशंका शुरुआती अनुमान से कम लगती है। ये आकलन अपने-अपने समय तक सीमित हैं—और इनमें से कोई भी बिना पैच वाले सर्वर को सुरक्षित नहीं बनाता।
7
9
18
कुछ सेवाएँ ऑफलाइन क्यों हुईं?
कुछ संगठनों ने जोखिम का आकलन करने और अपडेट तैयार करने के दौरान एहतियातन सेवाओं को अस्थायी रूप से बंद या सीमित किया। रिपोर्टों के अनुसार, ब्रिटेन की सरकार ने 32 सेवाएँ ऑफलाइन कीं। एक सेवा-स्थिति ट्रैकर ने पैच उपलब्ध होने से पहले 100 से अधिक सेवाओं के आउटेज, मेंटेनेंस नोटिस या PHP2Shell चेतावनियाँ दर्ज कीं। ये कदम आपातकालीन सुधार से हुई बाधा दिखाते हैं; अपने-आप में इस बात का सबूत नहीं कि उन सेवाओं पर हमला हुआ था।
22
34
अन्य रिपोर्टों में कुछ दूसरे देशों की सरकारों और संगठनों की प्रतिक्रियाओं का भी ज़िक्र था। लेकिन उपलब्ध जानकारी प्रभावित सेवाओं की पूरी, स्वतंत्र रूप से सत्यापित सूची स्थापित नहीं करती और न ही हर बताए गए स्थानीय आउटेज की पुष्टि करती है।
20
25
वेबसाइट संचालकों को अब क्या करना चाहिए?
- PHP के हर इंस्टॉलेशन की सूची बनाएँ। प्रोडक्शन सर्वर के साथ कंटेनर, बैकअप या सहायक सिस्टम और मैनेज्ड होस्टिंग भी जाँचें—सिर्फ मुख्य वेबसाइट नहीं।
- उचित फिक्स जल्द लागू करें। PHP का फिक्स वाला संस्करण या विक्रेता द्वारा पुष्टि किया गया बैकपोर्ट इंस्टॉल करें। जरूरत के अनुसार PHP वर्कर या सेवा रीस्टार्ट करें और फिर चल रहे संस्करण की पुष्टि करें। केवल PHP ऐप या प्लगइन अपडेट करने से PHP रनटाइम का फिक्स नहीं होता।
14
39
- समय पर पैच न लगा सकें तो पहुँच सीमित करें। सेवा के सार्वजनिक जोखिम और कारोबारी असर को देखकर उसे अस्थायी रूप से बंद करने या उसकी पहुँच सीमित करने पर विचार करें। नेटवर्क नियमों को अस्थायी सुरक्षा मानें, पैच का विकल्प नहीं।
- सेंधमारी के संकेत जाँचें। संबंधित लॉग देखें और अनजान फ़ाइलों, प्रोसेस या एडमिन खातों पर ध्यान दें। शक हो तो सबूत सुरक्षित रखें और जाँच करें—यह न मानें कि पैच लगाने से पहले की घुसपैठ अपने-आप ठीक हो गई।
- होस्टिंग प्रदाता से स्पष्ट पुष्टि लें। छोटी संस्थाएँ और व्यवसाय अपने होस्ट या मैनेज्ड-सर्विस प्रदाता से पूछें कि उनके काम के सभी PHP इंस्टॉलेशन पर फिक्स लागू हुआ है या नहीं।
NSA ने गंभीर पैच जल्द लगाने की सलाह दी और कहा कि वह PHP2Shell का फायदा उठाने की कोशिश कर रहे दुर्भावनापूर्ण साइबर हमलावरों की पहचान को प्राथमिकता दे रही है। FBI ने भी PHP इंस्टॉलेशन अपडेट करने को कहा। उपलब्ध स्रोत यह साबित नहीं करते कि FBI, NSA और CISA ने मिलकर ऐसा कोई एक आदेश जारी किया था जिसमें पैच न लगा पाने पर सभी संगठनों को सिस्टम बंद करने को कहा गया हो।
17
28
आम उपयोगकर्ता क्या कर सकते हैं—और क्या नहीं
अपने निजी डिवाइस, ऐप और राउटर अपडेट रखें। मल्टी-फैक्टर ऑथेंटिकेशन इस्तेमाल करें और हर खाते के लिए अलग, मजबूत पासवर्ड रखें। ये अच्छी सामान्य सुरक्षा आदतें हैं, लेकिन किसी वेबसाइट के PHP सर्वर को पैच नहीं करतीं—यह काम वेबसाइट संचालक या होस्टिंग प्रदाता का है।
PHP2Shell से व्यावहारिक सबक है: पैच जल्दी और पुष्टि करके लगाएँ, और कम समय में कार्रवाई की तैयारी रखें। यह घटना दिखाती है कि सुरक्षा शोध और हमले की कोशिशें तेजी से आगे बढ़ सकती हैं। लेकिन कोशिशों की गिनती को बड़े पैमाने पर सफल सेंधमारी का प्रमाण मानना या इसे पूरे वेब की सुरक्षा व्यवस्था के ढहने का संकेत बताना उपलब्ध सबूतों से आगे जाना होगा।