‘ब्लैक अक्टूबर’ किसी एक हमले का नाम नहीं था। यह अक्टूबर 2026 में सामने आई साइबर सुरक्षा घटनाओं और खामियों के तेज़ सिलसिले के लिए इस्तेमाल हुआ नाम था। इस हड़बड़ी का बड़ा कारण PHP2Shell था—PHP में मिली दो गंभीर कमजोरियां, जिनसे बिना लॉगिन किए किसी हमलावर को प्रभावित सर्वर पर कोड चलाने का मौका मिल सकता था। खामियों की AI-सहायता से खोज, विवरण का समय से पहले लीक होना और पैच से पहले संदिग्ध जांच-पड़ताल की खबरों ने चिंता बढ़ाई।
3
27
45
PHP2Shell में क्या जोखिम था?
CVE-2026-109618 और CVE-2026-109619 नाम की ये कमजोरियां उन PHP इंस्टॉलेशन को प्रभावित करती थीं जो वेब अनुरोध संभालते हैं। इनमें PHP-FPM और Apache के साथ mod_php जैसे आम सेटअप भी शामिल हैं।
1 दोनों खामियों को CVSS v4.0 पर 9.2 का स्कोर मिला था और इनके जरिए बिना प्रमाणीकरण के दूर से कोड चलाया जा सकता था।
18
रिपोर्टों के मुताबिक, शोधकर्ताओं ने खामियां खोजने में AI मॉडल की मदद ली।
45 इसका अर्थ यह नहीं कि हमले AI ने किए: बुनियादी जोखिम कमजोर PHP सॉफ्टवेयर और उस तक पहुंचने वाले खास तौर पर बनाए गए अनुरोधों से जुड़ा था।
लीक, शुरुआती जांच और आपातकालीन पैच
SecurityWeek और VulnCheck की रिपोर्टों के अनुसार, खामियों की जानकारी नियोजित खुलासे से पहले 20 अक्टूबर को ऑनलाइन आ गई।
27
38 Amazon Threat Intelligence ने अपने honeypot नेटवर्क पर 17 अक्टूबर को संभावित शोषण-प्रयास दर्ज करने की बात कही—यानी PHP के पैच जारी होने से चार दिन पहले।
27 यह संभावित प्रयास या जांच-पड़ताल का संकेत है; अपने आप में यह इस बात का प्रमाण नहीं कि किसी वास्तविक सिस्टम में सेंध लग गई थी।
PHP ने 21 अक्टूबर 2026 को सुरक्षा अपडेट जारी किए। ठीक किए गए संस्करण थे PHP 8.5.12, 8.4.27, 8.3.36 और 8.2.35।
18 CISA—अमेरिका की साइबर सुरक्षा और अवसंरचना सुरक्षा एजेंसी—ने तुरंत पैच लगाने की सलाह दी। 26 अक्टूबर को उसने दोनों खामियों को अपने Known Exploited Vulnerabilities (KEV) कैटलॉग में भी जोड़ा।
1
जोखिम गंभीर था, लेकिन कोशिश और सफल सेंध एक बात नहीं
VulnCheck ने बताया कि उसने CVE-2026-109618 के लिए काम करने वाला exploit तैयार किया था। उसके परीक्षण में PHP 8.4.26 पर, x86-64 सिस्टम में, मेमोरी लीक को दूर से कोड चलाने के साथ जोड़ा गया—यहां तक कि ASLR चालू होने और display_errors=off होने पर भी।
43 यह नतीजा दिखाता है कि मेमोरी सुरक्षा उपाय पैच का विकल्प नहीं हैं। हालांकि, यह VulnCheck के बताए गए खास सेटअप का परीक्षण था; इससे यह साबित नहीं होता कि हर PHP सिस्टम पर शोषण उतना ही आसान था।
कुछ रिपोर्टों में PHP2Shell को Linux kernel की Fragnesia खामी के साथ जोड़कर एक सरकारी-संबद्ध वातावरण के फायरवॉलों पर root access पाने की बात कही गई।
21 अलग रिपोर्टिंग में इंटरनेट पर खुले PAN-OS प्रबंधन इंटरफेस को निशाना बनाने वाले हमलों का भी उल्लेख था।
25 ये रिपोर्टें वास्तविक जोखिम की ओर इशारा करती हैं, लेकिन अपने आप में यह नहीं दिखातीं कि हर PHP इंस्टॉलेशन पर बड़े पैमाने पर सफल सेंध लगी।
यह फर्क अहम है: स्कैनिंग या हमला करने की कोशिश, सफल घुसपैठ का प्रमाण नहीं होती। 23 अक्टूबर की एक सुरक्षा चेतावनी ने उस समय तक PHP2Shell के बड़े पैमाने पर सफल शोषण की पुष्टि न होने की बात कही थी; वहीं VulnCheck ने एक खास कॉन्फ़िगरेशन में काम करने वाला exploit दिखाया था।
33
43
संगठनों को क्या करना चाहिए?
- प्रभावित PHP संस्करण अपडेट करें। अपनी PHP शाखा का ठीक किया हुआ संस्करण—या उसके बाद का लागू सुरक्षा अपडेट—इंस्टॉल करें। CISA ने तुरंत पैच करने को कहा है।
1
18
- वेबसाइटों के अलावा भी PHP खोजें। वे सभी इंस्टॉलेशन जांचें जो वेब अनुरोध संभालते हैं। CISA की चेतावनी में अलग-अलग सर्वर और एप्लिकेशन सेटअप शामिल हैं।
1 जहां लागू हो, उपकरणों और प्रबंधन इंटरफेस की भी सूची बनाएं।
- बिना पैच वाले इंटरनेट-सामना करते सिस्टम को प्राथमिकता दें। अगर तुरंत अपडेट संभव न हो, तो सुधार होने तक पहुंच सीमित करने या सेवा को अलग रखने पर विचार करें।
- पहले की संभावित गतिविधि की जांच करें। पैच से पहले जांच-पड़ताल की खबरें आई थीं; इसलिए अपडेट लगा देना इस बात का प्रमाण नहीं कि सिस्टम पहले कभी प्रभावित नहीं हुआ।
27
PHP2Shell का सीधा सबक यही है: जब आम तौर पर इस्तेमाल होने वाले सर्वर सॉफ्टवेयर में गंभीर खामी सामने आए, तो यह जानना कि वह कहां-कहां चल रहा है और तेजी से कार्रवाई करना—दोनों उतने ही जरूरी हैं जितना पैच लगाना।