PHP2Shell साइबर अलर्ट: PHP की गंभीर कमजोरियों से लाखों सर्वरों पर खतरे की आशंका, पुराने वेबसाइट सिस्टम बन सकते हैं बड़ी चुनौती

काउंटरइंडिया | टेक्नोलॉजी एवं साइबर सुरक्षा रिपोर्ट

नई दिल्ली, 24 अक्टूबर 2026। इंटरनेट पर वेबसाइट और वेब एप्लिकेशन बनाने के लिए इस्तेमाल होने वाली लोकप्रिय प्रोग्रामिंग भाषा PHP में सामने आईं दो गंभीर सुरक्षा कमजोरियों ने वैश्विक साइबर सुरक्षा समुदाय का ध्यान आकर्षित किया है। PHP2Shell नाम से चर्चित इन कमजोरियों के जरिए प्रभावित सिस्टम पर हमलावर बिना प्रमाणित लॉगिन के रिमोट कोड एक्जीक्यूशन (Remote Code Execution या RCE) करने में सक्षम हो सकते हैं। इसका अर्थ है कि किसी असुरक्षित सर्वर पर दूर से दुर्भावनापूर्ण निर्देश चलाने का रास्ता खुल सकता है।

PHP सुरक्षा टीम ने 21 अक्टूबर 2026 को संबंधित सुरक्षा अपडेट जारी किए। भारत की कंप्यूटर इमरजेंसी रिस्पॉन्स टीम (CERT-In) ने 23 अक्टूबर को PHP2Shell से जुड़ी कमजोरियों पर एडवाइजरी जारी करते हुए प्रभावित सिस्टमों को प्राथमिकता के आधार पर अपडेट करने की सलाह दी। <Cite refs={["turn985742search0","turn985742search15"]}/>

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

क्या है PHP2Shell?

PHP एक ओपन-सोर्स सर्वर-साइड प्रोग्रामिंग भाषा है। इसका उपयोग डायनामिक वेबसाइटों, ई-कॉमर्स प्लेटफॉर्म, बिजनेस एप्लिकेशन, कंटेंट मैनेजमेंट सिस्टम और अनेक ऑनलाइन सेवाओं में किया जाता है।

WordPress, Drupal और Joomla जैसे लोकप्रिय प्लेटफॉर्म PHP पर आधारित हैं। इन प्लेटफॉर्म पर चलने वाली वेबसाइटों की सुरक्षा उनके एप्लिकेशन, प्लगइन्स, सर्वर कॉन्फिगरेशन और PHP रनटाइम सहित कई स्तरों पर निर्भर करती है।

Wiz Research की रिपोर्ट में PHP के मूल इंजन से संबंधित कमजोरियों को दो CVE पहचान संख्याओं के अंतर्गत दर्ज किया गया है:

• CVE-2026-109618

• CVE-2026-109619

इन कमजोरियों का संबंध मेमोरी मैनेजमेंट और कुछ परिस्थितियों में अनुरोध (request) के दौरान PHP की आंतरिक स्थिति के गलत प्रबंधन से है। शोधकर्ताओं ने दिखाया कि इनका दुरुपयोग करके प्रभावित वातावरण में बिना लॉगिन के कोड चलाया जा सकता है। अलग परिस्थितियों में PHP प्रक्रिया की मेमोरी से संवेदनशील जानकारी उजागर होने का जोखिम भी है। <Cite refs={["turn985742search15","turn985742search1"]}/>

कितना गंभीर है खतरा?

इन कमजोरियों की गंभीरता का एक प्रमुख कारण यह है कि हमला सामान्य एप्लिकेशन लॉजिक तक सीमित नहीं रह सकता। यदि किसी इंटरनेट-सामने वाले सर्वर पर प्रभावित PHP रनटाइम मौजूद है, तो हमलावर के पास एप्लिकेशन के सामान्य लॉगिन या प्रमाणीकरण चरण से पहले ही हमला करने का अवसर हो सकता है।

संभावित परिणामों में शामिल हैं:

1. रिमोट कोड एक्जीक्यूशन: प्रभावित सर्वर पर अनधिकृत कोड चलाने का प्रयास।

2. संवेदनशील जानकारी का खुलासा: PHP प्रक्रिया की मेमोरी में मौजूद कुछ डेटा, जैसे टोकन, पासवर्ड या API कुंजियां, जोखिम में आ सकती हैं।

3. वेबसाइट में अनधिकृत बदलाव: सफल हमले की स्थिति में वेबसाइट की फाइलें या एप्लिकेशन प्रभावित हो सकते हैं।

4. आगे के हमलों का रास्ता: सर्वर पर नियंत्रण मिलने के बाद हमलावर अन्य सिस्टम या डेटा तक पहुंचने का प्रयास कर सकता है।

5. व्यावसायिक नुकसान: वेबसाइट बंद होने, डेटा चोरी, ग्राहकों का भरोसा कम होने और सेवा बहाल करने की लागत बढ़ने का जोखिम।

ये संभावित प्रभाव हैं; हर प्रभावित सर्वर पर ये सभी परिणाम होंगे, ऐसा नहीं है। वास्तविक जोखिम PHP वर्जन, सर्वर कॉन्फिगरेशन, उपलब्ध सुरक्षा सुधारों और हमले की परिस्थितियों पर निर्भर करेगा। <Cite refs={["turn985742search15","turn985742search1"]}/>

क्या लाखों सर्वर जोखिम में हो सकते हैं?

साइबर सुरक्षा कंपनी Palo Alto Networks की Unit 42 रिपोर्ट के अनुसार, उसके Cortex Xpanse टेलीमेट्री डेटा में 22.6 मिलियन से अधिक ऐसे एक्सपोज्ड इंस्टेंस पहचाने गए, जो इन कमजोरियों के संदर्भ में संभावित रूप से प्रभावित हो सकते हैं। यह आंकड़ा एक सुरक्षा उत्पाद के टेलीमेट्री और इंटरनेट पर दिखने वाले इंस्टेंस पर आधारित है। इसे 22.6 मिलियन पुष्ट संक्रमित वेबसाइटों या सफलतापूर्वक हैक किए गए सर्वरों की संख्या नहीं समझना चाहिए। <Cite refs={["turn985742news9"]}/>

यह आंकड़ा समस्या के संभावित पैमाने को दर्शाता है, लेकिन प्रत्येक संगठन को अपने वास्तविक PHP वर्जन और पैच की स्थिति की अलग से जांच करनी होगी।

कौन-से PHP वर्जन सुरक्षित किए गए हैं?

PHP प्रोजेक्ट ने संबंधित कमजोरियों के समाधान के लिए निम्नलिखित अपडेट जारी किए हैं:

इन वर्जनों या इनके बाद उपलब्ध संबंधित सुरक्षा सुधारों को लागू करने से पहले यह सुनिश्चित करना जरूरी है कि अपडेट सही रनटाइम पर लागू हुआ है और सर्वर संबंधित सेवाओं को उसी पैच किए गए वर्जन के साथ चला रहा है। <Cite refs={["turn985742search1","turn985742search15"]}/>

PHP 8.1 और उससे पुराने वर्जन के मामले में क्या करें?

PHP प्रोजेक्ट से PHP 8.1 और पुराने वर्जनों को सामान्य अपस्ट्रीम सुरक्षा अपडेट नहीं मिलते। हालांकि, कुछ Linux वितरण, दीर्घकालिक समर्थन (LTS) प्रदाता या अन्य विक्रेता पुराने वर्जन के लिए सुरक्षा सुधार बैकपोर्ट कर सकते हैं। इसलिए पुराने वर्जन को चलाने वाली प्रत्येक वेबसाइट के बारे में एक जैसा निष्कर्ष निकालना उचित नहीं होगा।

वेबसाइट मालिकों को अपने होस्टिंग प्रदाता या ऑपरेटिंग सिस्टम विक्रेता से लिखित रूप में पुष्टि करनी चाहिए कि संबंधित सुरक्षा सुधार उपलब्ध है और वास्तव में इंस्टॉल किया गया है। यदि सत्यापित पैच उपलब्ध नहीं है, तो समर्थित PHP शाखा पर माइग्रेशन की योजना बनानी चाहिए। <Cite refs={["turn985742search1","turn985742search0"]}/>

सबसे बड़ी चुनौती: पुरानी वेबसाइटों को नए PHP वर्जन के अनुकूल बनाना

PHP2Shell के बाद कई व्यवसायों के सामने केवल सर्वर अपडेट करने का नहीं, बल्कि पुराने वेब एप्लिकेशन को सुरक्षित और आधुनिक बनाने का प्रश्न भी खड़ा हो सकता है।

कई वेबसाइटें वर्षों पहले विकसित की गई थीं। उनके कोड में ऐसे फंक्शन, लाइब्रेरी, फ्रेमवर्क और प्रोग्रामिंग तरीके इस्तेमाल हो सकते हैं जो नए PHP वर्जन के साथ पूरी तरह संगत न हों।

ऐसे प्रोजेक्ट में PHP वर्जन बदलने पर निम्न समस्याएं सामने आ सकती हैं:

• पुराने फंक्शन और कोड: अप्रचलित फंक्शन या बदले हुए व्यवहार के कारण त्रुटियां आ सकती हैं।

• फ्रेमवर्क की समस्या: पुराना फ्रेमवर्क नए PHP वर्जन को सपोर्ट न करे।

• प्लगइन और लाइब्रेरी: थर्ड-पार्टी निर्भरताएं अपडेट मांग सकती हैं या उनका रखरखाव बंद हो चुका हो सकता है।

• डेटाबेस और बिजनेस लॉजिक: रिपोर्ट, फॉर्म, भुगतान, लॉगिन और अन्य प्रक्रियाओं का व्यवहार बदल सकता है।

• टेस्टिंग और डिप्लॉयमेंट: अपडेट के बाद वेबसाइट के प्रत्येक महत्वपूर्ण फीचर की जांच और सुरक्षित रिलीज की जरूरत हो सकती है।

इसका अर्थ है कि कुछ पुराने प्रोजेक्ट में डेवलपर को कोड का ऑडिट, निर्भरताओं का अपडेट, संगतता सुधार और व्यापक टेस्टिंग करनी पड़ सकती है। छोटे प्रोजेक्ट में यह सीमित काम हो सकता है, जबकि बड़े और वर्षों से चल रहे सिस्टम में यह एक महत्वपूर्ण माइग्रेशन प्रोजेक्ट बन सकता है।

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

क्या केवल PHP वर्जन बदलने से समस्या हल हो जाएगी?

यह सवाल महत्वपूर्ण है। सुरक्षा अपडेट लागू करना तत्काल प्राथमिकता है, लेकिन वेबसाइट की संपूर्ण सुरक्षा का मूल्यांकन केवल वर्जन नंबर देखकर नहीं किया जा सकता।

यदि होस्टिंग प्रदाता प्रभावित रनटाइम को पैच कर देता है, तो PHP2Shell के संबंधित दोषों के विरुद्ध यह सबसे महत्वपूर्ण कदम है। इसके बाद भी वेबसाइट में कमजोर प्लगइन, पुराने पासवर्ड, गलत सर्वर परमिशन, असुरक्षित API या अन्य एप्लिकेशन कमजोरियां मौजूद हो सकती हैं।

दूसरी ओर, बिना जांच के किसी पुराने एप्लिकेशन को नए PHP वर्जन पर ले जाने से वेबसाइट के महत्वपूर्ण फीचर टूट सकते हैं। इसलिए सुरक्षा पैचिंग और एप्लिकेशन संगतता परीक्षण को समन्वित तरीके से करना चाहिए।

सही रणनीति यह है कि उपलब्ध सुरक्षा पैच को प्राथमिकता से लागू किया जाए और साथ-साथ पुराने एप्लिकेशन की संगतता तथा दीर्घकालिक माइग्रेशन पर काम किया जाए। केवल इस वजह से पैचिंग को टालना उचित नहीं कि एप्लिकेशन अपग्रेड में समय लगेगा।

वेबसाइट मालिक और होस्टिंग कंपनियां तुरंत क्या करें?

CERT-In की सलाह और उपलब्ध तकनीकी मार्गदर्शन के आधार पर संगठनों को निम्न कदम उठाने चाहिए। <Cite refs={["turn985742search0","turn985742search1"]}/>

1. सभी PHP इंस्टॉलेशन की सूची बनाएं

वेबसाइट, सबडोमेन, स्टेजिंग सर्वर, कंटेनर और बैकग्राउंड वर्कर सहित सभी स्थानों पर इस्तेमाल हो रहे PHP वर्जन की पहचान करें।

2. इंटरनेट-सामने वाले सिस्टम को प्राथमिकता दें

वेबसाइटों और सार्वजनिक वेब एप्लिकेशन की पहले जांच करें, क्योंकि वे इंटरनेट से सीधे पहुंच योग्य होते हैं।

3. सुरक्षा पैच लागू करें

समर्थित PHP शाखा का संबंधित पैच इंस्टॉल करें। यदि PHP होस्टिंग प्रदाता द्वारा प्रबंधित है, तो उससे अपडेट की स्थिति की पुष्टि करें।

4. सेवाओं को सत्यापित करें

जहां आवश्यक हो, संबंधित PHP-FPM या वेब सर्वर सेवाओं को रीस्टार्ट करें और पुष्टि करें कि वास्तव में पैच किया गया रनटाइम उपयोग में है।

5. पुराने वर्जन के लिए समाधान तय करें

यदि PHP शाखा असमर्थित है, तो विक्रेता द्वारा दिए गए सुरक्षा बैकपोर्ट की पुष्टि करें या समर्थित वर्जन पर माइग्रेशन शुरू करें।

6. लॉग और फाइलों की जांच करें

असामान्य अनुरोध, बार-बार HTTP 500 त्रुटियां, अप्रत्याशित फाइल बदलाव, नए एडमिन अकाउंट, संदिग्ध प्रोसेस या असामान्य आउटबाउंड कनेक्शन की जांच करें।

7. बैकअप और रिकवरी की तैयारी रखें

सुरक्षित बैकअप बनाएं, उसकी बहाली का परीक्षण करें और प्रशासनिक खातों पर मजबूत पासवर्ड तथा जहां संभव हो मल्टी-फैक्टर ऑथेंटिकेशन लागू करें।

8. संदिग्ध गतिविधि मिलने पर घटना-प्रतिक्रिया शुरू करें

संबंधित लॉग सुरक्षित रखें, प्रभावित सिस्टम को नियंत्रित करें और जरूरत के अनुसार साइबर सुरक्षा विशेषज्ञों तथा CERT-In से संपर्क करें। केवल पैच लगा देना इस बात का प्रमाण नहीं है कि पहले कोई हमला नहीं हुआ था। <Cite refs={["turn985742search0","turn985742search1"]}/>

डेवलपर्स की भूमिका क्यों महत्वपूर्ण है?

PHP डेवलपर्स को केवल कोड लिखने तक सीमित नहीं रहना चाहिए। उन्हें यह समझना होगा कि उनके बनाए एप्लिकेशन किस PHP शाखा, फ्रेमवर्क और थर्ड-पार्टी लाइब्रेरी पर निर्भर हैं।

उनकी प्राथमिकताओं में शामिल होना चाहिए:

• एप्लिकेशन की वर्तमान PHP संगतता का आकलन करना।

• अप्रचलित फंक्शन और असमर्थित निर्भरताओं की पहचान करना।

• आवश्यक बदलावों को नियंत्रित टेस्टिंग के साथ लागू करना।

• भुगतान, लॉगिन, रिपोर्ट और डेटाबेस जैसी महत्वपूर्ण प्रक्रियाओं की जांच करना।

• सुरक्षा पैच के बाद स्टेजिंग और प्रोडक्शन वातावरण के बीच अंतर सत्यापित करना।

• माइग्रेशन के दौरान बैकअप और रोलबैक योजना बनाए रखना।

डेवलपर्स को यह भी ध्यान रखना चाहिए कि PHP2Shell का मूल दोष PHP इंजन में है। केवल एप्लिकेशन कोड में बदलाव करना संबंधित इंजन की सुरक्षा पैचिंग का विकल्प नहीं है।

DevOps और सिस्टम एडमिनिस्ट्रेटर क्या ध्यान रखें?

DevOps टीमों और सिस्टम एडमिनिस्ट्रेटरों को यह सुनिश्चित करना चाहिए कि सुरक्षा अपडेट केवल किसी एक सर्वर पर नहीं, बल्कि सभी संबंधित वातावरणों में लागू हो।

इसमें PHP-FPM, Apache के साथ mod_php, php-cgi, LiteSpeed और अन्य PHP रनटाइम कॉन्फिगरेशन की जांच शामिल हो सकती है। अपडेट के बाद सेवाओं के सही वर्जन पर चलने की पुष्टि करना और मॉनिटरिंग जारी रखना भी आवश्यक है। <Cite refs={["turn985742search1","turn985742search0"]}/>

यदि किसी सिस्टम को तुरंत पैच नहीं किया जा सकता, तो उपलब्ध विक्रेता-निर्देशित अस्थायी उपायों के साथ उसकी पहुंच सीमित करने पर विचार किया जा सकता है। लेकिन ऐसी व्यवस्था को पूर्ण समाधान नहीं माना जाना चाहिए।

निष्कर्ष: साइबर सुरक्षा को नियमित रखरखाव का हिस्सा बनाना होगा

PHP2Shell का मामला बताता है कि लोकप्रिय तकनीक में मौजूद एक गंभीर कमजोरी बड़ी संख्या में वेबसाइटों और ऑनलाइन सेवाओं के लिए चिंता पैदा कर सकती है। ऐसे मामलों में सुरक्षा पैचिंग, पुराने सिस्टम की पहचान, निर्भरताओं का रखरखाव और एप्लिकेशन माइग्रेशन सभी महत्वपूर्ण हैं।

वेबसाइट मालिकों को यह नहीं मानना चाहिए कि केवल वेबसाइट का सामान्य रूप से खुलना उसकी सुरक्षा का प्रमाण है। इसी तरह, किसी पुराने PHP वर्जन को देखकर बिना पैच की स्थिति जांचे उसे निश्चित रूप से असुरक्षित घोषित करना भी सही नहीं है।

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

आधिकारिक एवं तकनीकी स्रोत

1. भारत की CERT-In एडवाइजरी: https://www.cert-in.org.in/s2cMainServlet?VLCODE=CIAD-2026-0052&pageid=PUBVLNOTES02

2. PHP2Shell पर Wiz Research रिपोर्ट: https://www.wiz.io/blog/php2shell-php-rce

3. Palo Alto Networks Unit 42 की थ्रेट ब्रीफ: https://unit42.paloaltonetworks.com/cve-2026-109618-cve-2026-109619/

4. Plesk सुरक्षा एडवाइजरी: https://support.plesk.com/hc/en-us/articles/44397729587351-Vulnerability-CVE-2026-109618-and-CVE-2026-109619-PHP2Shell-Remote-code-execution-in-PHP-shipped-with-Plesk

काउंटरइंडिया का उद्देश्य पाठकों को तकनीक, डिजिटल सुरक्षा और महत्वपूर्ण साइबर खतरों के बारे में तथ्यपरक जानकारी उपलब्ध कराना है।

#PHP2Shell #CyberSecurity #PHP #WebSecurity #CERTIn #TechnologyNews #ApplicationSecurity #DevOps #CounterIndia