PHP2Shell, PHP में मिली दो गंभीर कमजोरियों—CVE-2026-109618 और CVE-2026-109619—को दिया गया नाम है। इनका सफलतापूर्वक दुरुपयोग होने पर हमलावर बिना लॉगिन किए प्रभावित सर्वर पर कोड चला सकता है। PHP प्रोजेक्ट ने 21 अक्टूबर 2026 को पैच जारी किए। सुरक्षा कंपनियों ने हमले के प्रयास भी दर्ज किए, लेकिन प्रयास और किसी सर्वर में सफल सेंध—दो अलग बातें हैं।
11
14
19
PHP2Shell की कमजोरियां क्या करती हैं?
ये कमजोरियां PHP के अपने रनटाइम में हैं—किसी एक वेबसाइट, CMS या प्लगइन में नहीं। Red Hat के मुताबिक, एक खामी अनुरोध (request) पढ़ते समय मेमोरी आवंटित न हो पाने पर PHP की स्थिति को ठीक से संभालने में चूक से जुड़ी है। दूसरी में गंभीर त्रुटि के कारण सफाई की प्रक्रिया बीच में रुक सकती है और पुरानी स्थिति बनी रह सकती है।
7
इन खामियों से रिमोट कोड एक्ज़ीक्यूशन (RCE) का रास्ता बन सकता है। आसान शब्दों में, इसका अर्थ है कि हमलावर को पहले खाते में लॉगिन किए बिना प्रभावित सर्वर पर कोड चलाने का मौका मिल सकता है।
11
13
दोनों को CVSS v4.0 पर 9.2 का स्कोर मिला है, जिसे गंभीर श्रेणी में रखा जाता है। संभावित नतीजों में सर्वर पर नियंत्रण खोना, डेटा उजागर होना या सेवा बाधित होना शामिल है। हालांकि, खामी मौजूद होने का अर्थ यह नहीं कि हर PHP वेबसाइट पर हमला हुआ है या वह हैक हो चुकी है।
4
13
यह मामला इतना सुर्खियों में क्यों आया?
रिपोर्टों के अनुसार, ये कमजोरियां सामने आने से पहले कई साल तक PHP में मौजूद थीं।
42 लेकिन लंबे समय तक किसी खामी का मौजूद रहना अपने-आप यह साबित नहीं करता कि हमलावरों को उसकी जानकारी थी या उन्होंने इतने समय तक उसका इस्तेमाल किया।
इसकी खोज में AI की भूमिका ने भी ध्यान खींचा। रिपोर्टों के मुताबिक, Calif और Wiz ने अपनी जांच में AI टूल इस्तेमाल किए, जबकि OpenAI भी शोध और खुलासे की प्रक्रिया में शामिल था।
34
44 AI सुरक्षा शोधकर्ताओं को सॉफ्टवेयर की जांच में मदद दे सकता है; लेकिन इस खोज से अकेले यह निष्कर्ष नहीं निकलता कि हमलावर ऐसे टूल कितनी तेजी से इस्तेमाल कर पाएंगे या किस पक्ष को बढ़त मिलेगी।
खबरों में PHP के व्यापक इस्तेमाल का भी उल्लेख हुआ—कुछ अनुमानों के मुताबिक यह करीब 70% वेबसाइटों में इस्तेमाल होता है।
20 यह आंकड़ा PHP की बताई गई पहुंच का है, न कि उन सर्वरों की संख्या का जो निश्चित रूप से असुरक्षित हैं या जिनमें सेंध लगी है। वास्तविक जोखिम PHP के संस्करण, कॉन्फ़िगरेशन, सर्वर की तैनाती और पैच लगाए जाने पर निर्भर करता है।
पैच और हमले के प्रयास: अब तक क्या पता है?
PHP प्रोजेक्ट ने 21 अक्टूबर को संस्करण 8.2.35, 8.3.36, 8.4.27 और 8.5.12 में सुधार जारी किए।
19 यह सूची PHP 8.2 से 8.5 तक के संस्करणों को कवर करती है। पुराने संस्करण चलाने वाले संगठनों को अपने ऑपरेटिंग सिस्टम या होस्टिंग प्रदाता की सुरक्षा सूचनाएं देखकर सत्यापित पैच या बैकपोर्ट की पुष्टि करनी चाहिए—यह मानकर नहीं चलना चाहिए कि पैच उपलब्ध है या नहीं है।
हमले के प्रयासों की रिपोर्टें भी आईं। SecurityWeek के मुताबिक, Amazon ने पैच जारी होने से चार दिन पहले, 17 अक्टूबर को एक प्रयास देखा था।
14 Cloudflare ने कमजोरियां सार्वजनिक होने के बाद अपने नेटवर्क पर ऐसे ट्रैफिक में तेज बढ़ोतरी बताई; बाद की रिपोर्टों में प्रयासों की संख्या लाखों तक पहुंचने का उल्लेख है।
27
38 ये आंकड़े दर्ज किए गए प्रयासों के हैं, सफल घुसपैठों के नहीं।
हमले के पैमाने को लेकर रिपोर्टें एक जैसी नहीं हैं: कुछ स्रोत सक्रिय प्रयासों की बात करते हैं, जबकि एक अन्य आकलन में बड़े पैमाने पर सफल दुरुपयोग की आशंका शुरुआती अनुमान से कम बताई गई।
3
4 उपलब्ध जानकारी व्यापक रूप से सफल सेंध की पुष्टि नहीं करती। हमले की विश्वसनीय रिपोर्ट को गंभीरता से लें, लेकिन स्कैनिंग या प्रयास को किसी खास सर्वर के हैक होने का प्रमाण न मानें।
2
3
कुछ सेवाएं अस्थायी रूप से बंद क्यों हुईं?
सुरक्षा उपाय लागू करने के दौरान कुछ संस्थानों ने सार्वजनिक सेवाएं अस्थायी रूप से बंद कीं। रिपोर्टों में जापान, फ्रांस, फ़िनलैंड और नीदरलैंड में वेबसाइटों या अन्य ऑनलाइन सेवाओं को कुछ समय के लिए ऑफलाइन करने या रखरखाव में डालने का उल्लेख है। अमेरिका और यूरोप की एजेंसियों ने भी संगठनों से कार्रवाई करने को कहा।
18
20
35 किसी सेवा को अस्थायी रूप से बंद करना जोखिम घटाने का कदम हो सकता है; यह अपने-आप में इस बात का सबूत नहीं कि उस सेवा में सेंध लगी थी।
इस लेख के लिए उपलब्ध स्रोत Microsoft CEO Satya Nadella के कोलोन में एक कार्यक्रम के दौरान कथित बयान, उसकी शब्दावली या संदर्भ की स्वतंत्र पुष्टि नहीं करते। इसलिए उस बयान को घटना की व्याख्या या कार्रवाई की वजह बताने के लिए आधार नहीं बनाया गया है।
PHP चलाने वाली टीमों को क्या करना चाहिए?
- सिर्फ ऐप नहीं, PHP रनटाइम भी जांचें। PHP2Shell रनटाइम की कमजोरी है। CMS या प्लगइन अपडेट करने से यह साबित नहीं होता कि सर्वर पर चल रहा PHP भी ठीक हो गया है।
13
- सत्यापित पैच लगाएं। उपयुक्त पैच वाला PHP संस्करण इंस्टॉल करें या अपने विक्रेता के निर्देशों के अनुसार बैकपोर्टेड पैच लगाएं। उत्पादन (production) में वास्तव में चल रहे संस्करण की पुष्टि करें।
19
- सेंध के संकेत तलाशें। पैच कमजोरी को ठीक करता है, लेकिन यह साबित नहीं करता कि सर्वर पहले कभी एक्सेस नहीं हुआ। सेवा सामान्य करने से पहले संबंधित लॉग की समीक्षा करें और संदिग्ध गतिविधि की जांच करें।
- अस्थायी उपायों को सावधानी से अपनाएं। PHP अनुरक्षकों या अपने विक्रेता के मौजूदा निर्देशों का पालन करें। किसी एक कॉन्फ़िगरेशन बदलाव या वेब एप्लिकेशन फ़ायरवॉल (WAF) को सत्यापित रनटाइम पैच का विकल्प न मानें।
15
27
- खातों की सुरक्षा को अतिरिक्त परत समझें। अलग-अलग मजबूत पासवर्ड और बहु-कारक प्रमाणीकरण (MFA) खातों की सुरक्षा में मदद करते हैं, लेकिन बिना लॉगिन सर्वर पर कोड चलाने वाली कमजोरी को ठीक नहीं करते।
IT टीमों के लिए कमजोरी, हमले के प्रयास और पुष्टि की गई सेंध के बीच फर्क समझना जरूरी है। इससे जरूरी पैचिंग पर तेज़ी से काम किया जा सकता है—बिना अपुष्ट दावों को किसी संगठन में सेंध का निष्कर्ष बनाए।