अगर आपने PHP2Shell कमजोरी के बाद अपनी कंपनी की वेबसाइट को PHP 8.5.12, 8.4.27, 8.3.36 या 8.2.35 पर अपडेट कर लिया है, तो आपने सही किया, लेकिन इससे सब कुछ कवर नहीं होता। 23 अक्टूबर 2026 को PHP प्रोजेक्ट ने एक तीसरी कमजोरी CVE-2026-115560 के बारे में नई चेतावनी प्रकाशित की, जिसे 21 अक्टूबर का अपडेट ठीक नहीं करता। इसके लिए एक असामान्य कॉन्फ़िगरेशन चाहिए और PHP इसे हमले का कम संभावित रास्ता मानता है, लेकिन अस्थायी उपाय सरल है: आज ही अपनी टीम या होस्ट से कहें कि session.upload_progress.enabled को 0 पर सेट करें और PHP को रीस्टार्ट करें, फिर लिखित में पुष्टि लें कि 21 अक्टूबर का अपडेट सच में लागू हुआ है।

PHP ने 23 अक्टूबर को क्या घोषणा की?

आपातकालीन रिलीज के दो दिन बाद प्रोजेक्ट ने सेशन में «अपलोड प्रगति» ट्रैकिंग के बारे में एक छोटी सूचनात्मक चेतावनी जारी की। यह वह फीचर है जो उपयोगकर्ता को दिखाता है कि बड़ी फाइल कितनी अपलोड हो चुकी है। चेतावनी के अनुसार यह फीचर एक खास स्थिति में दूर से कोड चलाने का रास्ता खोल सकता है, और इसका सुधार आपातकालीन अपडेट के रूप में नहीं, बल्कि अगली नियमित रिलीज में आएगा, साथ में इस कमजोरी की पूरी एडवाइजरी भी।

व्यवसाय मालिक के लिए दो बातें अहम हैं। पहली, यह एक अलग कमजोरी है, इसलिए ऊपर बताए गए चार वर्जनों में से कोई एक चलाना अपने आप में काफी नहीं है। दूसरी, यही अस्थायी उपाय 21 अक्टूबर को CVE-2026-109619 की एडवाइजरी में पहले से दर्ज था। अगर आपकी टीम ने उसे तभी लागू कर दिया था, तो कुछ नया करने की जरूरत नहीं है: उसे वैसे ही रहने दें।

क्या आपकी साइट खतरे में है?

PHP की चेतावनी के अनुसार समस्या तभी आती है जब तीन शर्तें एक साथ पूरी हों:

  • PHP कॉन्फ़िगरेशन session.serialize_handler को php_binary या php_serialize पर सेट करता है।
  • एप्लिकेशन का कोड सेशन शुरू होने से पहले ini_set() से रनटाइम पर इसे php में बदल देता है।
  • सेशन अपलोड प्रगति ट्रैकिंग अब भी चालू है, जो डिफ़ॉल्ट रूप से चालू रहती है।

ज्यादातर साइटें ऐसा नहीं करतीं। दिक्कत यह है कि मालिक को शायद ही पता होता है कि सालों पहले बने सिस्टम या किसी पुराने प्लगइन की हर लाइन क्या करती है। इसलिए सबसे सुरक्षित विकल्प यह है: अगर आपकी साइट फाइल अपलोड करते समय प्रगति बार नहीं दिखाती, तो इस फीचर को बंद करने से कुछ नहीं टूटता और दरवाजा बंद हो जाता है। अगर साइट इस पर निर्भर है, तो अपने डेवलपर्स से पूछें कि क्या कोड रनटाइम पर यह सेटिंग बदलता है।

तीन दिन बाद: जांचें कि 21 अक्टूबर का अपडेट सच में लागू हुआ

मूल कमजोरियां CVE-2026-109618 और CVE-2026-109619 अब भी बड़ा खतरा हैं। सऊदी अरब के राष्ट्रीय साइबर सुरक्षा प्राधिकरण (NCA) ने इन पर चेतावनी संख्या 2026-7949 जारी की, और अमेरिकी एजेंसी CISA ने सलाह दी कि सभी PHP सिस्टम की सूची बनाएं, इंटरनेट से जुड़े सिस्टम पहले पैच करें, और जिस सिस्टम को तुरंत पैच न किया जा सके उसे ऑफलाइन कर दें। CISA ने कहा कि प्रकाशन के समय तक उसने कोई सफल हमला नहीं देखा था, लेकिन इसका मतलब यह नहीं कि समय आपके पक्ष में है।

तीन बातें जिन्हें बहुत लोग भूल जाते हैं:

  • रीलोड नहीं, रीस्टार्ट। Red Hat के बुलेटिन में कहा गया है कि कॉन्फ़िगरेशन बदलाव के लिए PHP प्रोसेस को रीस्टार्ट करना जरूरी है और सिर्फ रीलोड काफी नहीं है।
  • Linux सर्वर पर वर्जन नंबर अलग हो सकता है। PHP की घोषणा कहती है कि Linux वितरणों को पैच पहले ही मिल गए थे, इसलिए सुधार लागू होने के बावजूद आपको उदाहरण के लिए 8.5.12 से अलग नंबर दिख सकता है। अपने होस्ट से सिर्फ नंबर नहीं, लिखित पुष्टि मांगें। Red Hat बताता है कि RHEL 8, 9 और 10 सभी प्रभावित हैं।
  • PHP किस तरह चलता है, इससे खतरा बदलता है। PHP प्रोजेक्ट Apache पर mod_php के लिए खतरा सबसे ज्यादा मानता है, जबकि Red Hat कहता है कि डिफ़ॉल्ट PHP-FPM के साथ व्यवहार में हमला करना ज्यादा कठिन है। कठिन का मतलब असंभव नहीं, इसलिए दोनों स्थितियों में अपडेट जरूरी है।

आज अपने होस्ट या टीम को भेजने के लिए 5 सवाल

  1. हमारी हर साइट और हर सिस्टम पर PHP का कौन सा वर्जन चल रहा है, और क्या उसमें 21 अक्टूबर 2026 के सुधार शामिल हैं?
  2. क्या अपडेट के बाद PHP प्रोसेस रीस्टार्ट किए गए, सिर्फ रीलोड नहीं?
  3. क्या हमने session.upload_progress.enabled को 0 पर सेट किया है? अगर नहीं, तो क्या हमें सच में इस फीचर की जरूरत है?
  4. क्या हमारी साइट का कोड रनटाइम पर session.serialize_handler बदलता है?
  5. क्या हमारी कोई साइट 8.1 या उससे पुराने वर्जन पर है? इन शाखाओं को अब सपोर्ट नहीं मिलता, और समर्थित वर्जनों की तालिका दिखाती है कि 8.2 का सुरक्षा सपोर्ट 31 दिसंबर 2026 को खत्म हो रहा है।

Origami का नजरिया

किसी बड़ी कमजोरी के बाद तीन दिन में तीन चेतावनियां आना सामान्य है: जब शोधकर्ता भाषा के किसी हिस्से को खंगालते हैं तो उसके आसपास की चीजें भी मिलती हैं। लेकिन यह कंपनियों के बारे में भी कुछ बताता है। जिसने 21 तारीख को पैच लगाकर मामला बंद कर दिया, वह 23 तारीख की चेतावनी से चूक जाएगा। यहां सुरक्षा लगातार निगरानी है, एक बार में पूरा होने वाला काम नहीं।

सऊदी कंपनियों में हम देखते हैं कि कठिन सवाल «कमजोरी क्या है?» नहीं, बल्कि «हमारे यहां कौन शुक्रवार सुबह PHP की चेतावनी पढ़ता है और जानता है कि कौन सा सर्वर हमारा है?» होता है। Origami में हम वेबसाइट और सिस्टम बनाते हैं और पहले दिन से उनके अपडेट पर नजर रखते हैं। अगर आप अपनी साइट की जांच करवाना चाहते हैं, या सेवा रोके बिना ये सेटिंग्स लागू करवाना चाहते हैं, तो हमसे संपर्क करें।

निष्कर्ष

21 अक्टूबर का अपडेट जरूरी है और अब भी सबसे अहम है; नई चेतावनी इसे नहीं बदलती। आज इसमें एक सस्ता कदम जोड़ें: अगर जरूरत न हो तो अपलोड प्रगति ट्रैकिंग बंद करें, PHP रीस्टार्ट करें और अपने होस्ट से लिखित पुष्टि लें। फिर PHP की अगली नियमित रिलीज पर नजर रखें, जो CVE-2026-115560 का अंतिम सुधार लाएगी।

स्रोत