PHP2Shell व्यापक रूप से इस्तेमाल होने वाले सॉफ़्टवेयर की सुरक्षा और उसे सुरक्षित रखने के लिए ज़रूरी मेहनत—दोनों के बारे में एक गंभीर चेतावनी थी। अक्टूबर 2026 में PHP की दो गंभीर खामियों के चलते आपातकालीन अपडेट जारी किए गए। एक रिपोर्ट के मुताबिक, PHP का इस्तेमाल 70% तक वेबसाइटों में होता है।
11 इस घटना ने एक बड़ा सवाल भी सामने रखा: क्या ओपन-सोर्स परियोजनाओं के पास उस सॉफ़्टवेयर की समीक्षा, पैच और नियमित देखभाल के लिए पर्याप्त क्षमता है, जिस पर वेब का बड़ा हिस्सा निर्भर है?
22
PHP2Shell में क्या हुआ
CVE-2026-109618 और CVE-2026-109619 नाम की खामियों से बिना लॉगिन किए हमलावर प्रभावित PHP सिस्टम पर दूर से कोड चला सकता था। रिपोर्टों में दोनों को 9.2 की गंभीरता रेटिंग दी गई।
9
17 ये PHP रनटाइम की खामियां थीं; इनके सामने आने का मतलब यह नहीं कि हर PHP ऐप असुरक्षित था।
PHP ने 21 अक्टूबर 2026 को सुधार वाले संस्करण जारी किए: 8.5.12, 8.4.27, 8.3.36 और 8.2.35।
18
27 Calif की शोध रिपोर्ट के अनुसार, इन खामियों की खोज Calif, OpenAI और Wiz ने की।
15 रिपोर्टों में समन्वित खुलासे की प्रक्रिया में गड़बड़ी की बात भी आई: PHP के रखरखावकर्ताओं ने Chainguard पर तय समय से पहले जानकारी सार्वजनिक करने का आरोप लगाया। इसके बाद परियोजना ने पैच तय समय से पहले जारी किए।
35
37
PHP के इस्तेमाल का व्यापक स्तर बताता है कि इस पर इतनी जल्दी कार्रवाई क्यों ज़रूरी थी। समाचार रिपोर्टों के अनुसार, PHP का इस्तेमाल 70% तक वेबसाइटों में होता है—लेकिन यह इसके प्रसार का अनुमान है, असुरक्षित या हैक हुई वेबसाइटों की गिनती नहीं।
11 उपलब्ध स्रोत इस विशिष्ट दावे की भी पुष्टि नहीं करते कि EFF के अनुमान के मुताबिक 23 अक्टूबर तक 3.3 करोड़ से अधिक सिस्टम असुरक्षित थे।
हमले की कोशिशें, सफल सेंधमारी का सबूत नहीं
रिपोर्टों के मुताबिक, Amazon ने 17 अक्टूबर को—सार्वजनिक पैच जारी होने से पहले—खामी का फायदा उठाने की एक कोशिश देखी थी। बाद में कंपनी ने इन खामियों का फायदा उठाने की व्यापक कोशिशों का ज़िक्र किया।
34 अन्य रिपोर्टों में ऐसी कोशिशों की संख्या लाखों में बताई गई।
6 अलग से, रिपोर्टों में बताया गया कि खामियों से निपटने के दौरान कुछ संगठनों ने एहतियातन अपनी सेवाएं बंद कीं। इनमें जापान के वित्त मंत्रालय और रॉटरडैम बंदरगाह से जुड़ी सेवाएं शामिल थीं।
12
लेकिन कोशिश होना और सेंधमारी की पुष्टि होना अलग बातें हैं। 22 अक्टूबर की BBC रिपोर्ट के अनुसार, सफल शोषण की कोई सूचना नहीं थी। Security Affairs ने भी 23 अक्टूबर को सफल शोषण की पुष्टि न होने की बात कही।
9
31 इन रिपोर्टों में अंतर उनकी निगरानी की अलग-अलग समय-सीमा या “शोषण” की अलग परिभाषाओं की वजह से हो सकता है। यहां दिए गए साक्ष्य हमले की गतिविधि को लेकर चिंता का आधार देते हैं—यह निष्कर्ष नहीं कि लाखों सिस्टम सफलतापूर्वक हैक हुए।
ओपन-सोर्स सुरक्षा का सबक: खामी खोजना शुरुआत भर है
PHP2Shell दिखाता है कि पुराने और स्थापित प्रोजेक्टों के मुख्य सॉफ़्टवेयर में भी खामियां खोज निकालना कितना अहम है। साथ ही, खामी मिलना पूरी प्रक्रिया का सिर्फ एक चरण है: सुधार की समीक्षा और उसे जारी करना होता है, फिर सिस्टम चलाने वालों को प्रभावित सेवाएं पहचानकर अपडेट लागू करना पड़ता है। Sovereign Tech ने साफ़ तौर पर इस घटना को गंभीर ओपन-सोर्स सुरक्षा के लिए फंडिंग की कमी उजागर करने वाला बताया।
22
इसलिए चिंता का केंद्र सिर्फ यह नहीं कि कितनी खामियां मिल रही हैं, बल्कि उन्हें ठीक करने की क्षमता भी है। अधिक खामियां मिलने से रखरखावकर्ताओं और सुरक्षा टीमों का काम बढ़ सकता है। लेकिन रिपोर्ट की गई कमजोरियों की संख्या बढ़ना अपने-आप में यह साबित नहीं करता कि सॉफ़्टवेयर कम सुरक्षित हो रहा है या इसकी वजह AI है। खामी ढूंढ लेने से उसे परखने, खुलासे का तालमेल बैठाने और भरोसेमंद सुधार जारी करके इंस्टॉल करवाने के लिए ज़रूरी मानवीय क्षमता नहीं मिल जाती।
संतुलित निष्कर्ष यह नहीं कि PHP स्वभाव से असुरक्षित है। बात यह है कि वेब के बड़े हिस्से में इस्तेमाल होने वाले सॉफ़्टवेयर की सुरक्षा समीक्षा और देखभाल लगातार होनी चाहिए—और खामियां तेज़ी से खोजे जाने पर यह काम और भी ज़रूरी हो जाता है।
11
22
PHP चलाने वाले संगठनों को क्या करना चाहिए
PHP इस्तेमाल करने वाले संगठनों के लिए व्यावहारिक कदम:
- इंटरनेट से सीधे जुड़े सिस्टमों की सूची बनाएं। पता करें कि किन सेवाओं में PHP है और वे वास्तव में किस रनटाइम संस्करण पर चल रही हैं।
- लागू पैच इंस्टॉल करें। इस्तेमाल की जा रही PHP शाखा के लिए सही अपडेट लगाएं। अगर रनटाइम किसी विक्रेता के पैकेज में है या वही उसकी देखभाल करता है, तो उसकी सत्यापित सलाह मानें। PHP ने 21 अक्टूबर को सुधार वाले संस्करण जारी किए थे।
18
27
- चल रही सेवा की जांच करें। पुष्टि करें कि तैनात सेवाएं और वर्कर अपडेटेड रनटाइम इस्तेमाल कर रहे हैं। जारी ऑपरेशनल मार्गदर्शन में अपडेट के बाद PHP वर्कर रीस्टार्ट करने की सलाह भी दी गई है।
32
- घटना की जानकारी सटीक रखें। प्रभावित सिस्टम, हमले की कोशिश, पुष्ट सेंधमारी और अपुष्ट दावों को अलग-अलग बताएं। एहतियातन सेवा बंद करना या हमले का ट्रैफ़िक दिखना यह साबित नहीं करता कि सिस्टम हैक हुआ।
PHP2Shell का स्थायी सबक पूरी सुरक्षा-श्रृंखला के बारे में है: खामी की खोज, समीक्षा, समन्वित खुलासा, पैच जारी करना और उसे सिस्टमों पर लागू करना—हर कदम मायने रखता है। इस श्रृंखला को चलाने वाले रखरखाव के लिए फंडिंग देना महत्वपूर्ण ओपन-सोर्स ढांचे की सुरक्षा का हिस्सा है, कोई वैकल्पिक अतिरिक्त खर्च नहीं।
22