मुख्य सामग्री पर जाएँ
लिंक प्रबंधित करें

PHP2Shell: PHP की दो गंभीर कमियाँ और आवश्यक कार्रवाई

PHP ने21अक्टूबर को CVE-2026-109618 और CVE-2026-109619 सुधारे। पैकेज, होस्टिंग और वास्तविक चालू प्रक्रियाओं में सुधार की पुष्टि करें।

WikiURL · प्रबंधन · प्रकाशित

दो खराब मेमोरी हिस्सों और सही प्रतिस्थापन हिस्सों वाला सर्वर।

क्या प्रकाशित हुआ और कार्रवाई क्यों जरूरी है

22अक्टूबर2026 तक की जानकारी। PHP ने21अक्टूबर को CVE-2026-109618 और CVE-2026-109619 के सुरक्षा अपडेट जारी किए, जिन्हें PHP2Shell कहा जाता है। समस्या केवल CMS प्लगइन नहीं, वेब अनुरोध संभालने वाले PHP इंजन की है। संवेदनशील सर्वर में बिना प्रमाणीकरण कोड चल सकता है। तत्काल कार्रवाई जरूरी है, लेकिन इससे कोई विशेष वेबसाइट पहले से हैक हुई साबित नहीं होती।

आधिकारिक सूची में PHP-FPM, Apache mod_php, php-cgi, FrankenPHP और LiteSpeed हैं। PHPmod_php में सबसे अधिक जोखिम बताता है और ऐप कोड से पहले प्रदर्शित शोषण दर्ज करता है। छोटी वेबसाइट, लॉगिन न होना या अद्यतन प्लगइन पर्याप्त आश्वासन नहीं। वास्तव में वेब अनुरोध संभालने वाला PHP और उसका सुधार पहचानें। जोखिम संस्करण, प्रदाता और विन्यास पर निर्भर है; यह लेख किसी खास सर्वर की स्थिति तय नहीं करता।

दो कमियाँ और सुधरे संस्करण

CVE-2026-109618 मेमोरी की कमी संभालते समय मेमोरी भ्रष्ट होने से जुड़ा है। CVE-2026-109619 में अंदरूनी स्थिति संबंधित मेमोरी मुक्त होने के बाद बचकर उसी वर्कर के अगले अनुरोध में इस्तेमाल हो सकती है। PHP Foundation कारण और सुधार समझाता है। फर्क जानने से एक सार्वभौमिक सेटिंग को इलाज मानने से बचते हैं। अपडेट तय करने को हमला दोहराना जरूरी नहीं; यहाँ सार्वजनिक सेवा पर हमला या जानबूझकर विफल करने के आदेश नहीं हैं।

21अक्टूबर के सुधरे संस्करण8.5.12,8.4.27,8.3.36 और8.2.35 हैं। काम से पहले नवीनतम सूचना देखें; बाद में नया संशोधन आ सकता है। वितरण दूसरे मूल नंबर में पैच बैकपोर्ट कर सकता है; UbuntuUSN-8948-1 में अपने पैकेज बताता है। केवल इंटरप्रेटर स्ट्रिंग नहीं, पैकेज और प्रदाता सूचना जाँचें। PHP 8.1 और पुराने परियोजना समर्थन से बाहर हैं; वितरक का सुधार ऊपर के आधिकारिक समर्थन को बहाल नहीं करता।

CVE-2026-109618 / CVE-2026-109619
PHP 8.2.35 | 8.3.36 | 8.4.27 | 8.5.12

होस्टिंग से क्या पूछें और प्रशासक क्या जाँचे

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

स्थापना के बाद प्रदाता निर्देश से प्रक्रियाएँ नवीनीकृत करें, चालू संस्करण या पैकेज देखें, जरूरी कार्य जाँचें और समय दर्ज करें। केवल CMS अपडेट या कैश साफ करना रनटाइम सुधार नहीं है। घुसपैठ संकेत हों तो प्रमाण बचाकर घटना प्रतिक्रिया शुरू करें: पैच हमलावर के पुराने बदलाव वापस नहीं करता। ये संचालन पूर्णता जाँच हैं, दूरस्थ निदान नहीं। होमपेज लौटना भी तकनीकी पुष्टि और कार्यात्मक परीक्षण की जरूरत नहीं हटाता।

तुरंत अपडेट न हो और WikiURL की सीमा

PHP स्पष्ट करता है कि केवल अपडेट पूरा समाधान है। अस्थायी उपाय खास रास्ते घटाते हैं, सुरक्षित स्थापना की गारंटी नहीं। मेमोरी या सत्र सेटिंग प्रभाव समझे बिना न कॉपी करें। ENISA खुले सिस्टम प्राथमिकता और जरूरत पर सार्वजनिक नेटवर्क से अलग करने पर विचार कहता है। प्रशासक के साथ सुरक्षित प्रबंधन पहुँच और रुकावट सूचना तय करें। WAF नियम या चलता ऐप पैच का विकल्प और पूर्ण सुरक्षा नहीं है।

WikiURL रखरखाव बाद सार्वजनिक पते की HTTP प्रतिक्रिया और अंतिम गंतव्य देख सकता है, वास्तविक PHP याCVE सुधार प्रमाणित नहीं करता।200 याHTTPS ताला भेद्यता मूल्यांकन नहीं है। रहस्य न भेजें, प्रमाण के लिएphpinfo सार्वजनिक न करें। प्रदाता पुष्टि, प्रक्रिया जाँच और सेवा परीक्षण अलग रखें। तत्काल अपडेट और परिणाम सत्यापन चाहिए, बिना प्रमाण हैक का दावा या केवल खुलते पृष्ठ से झूठा आश्वासन नहीं। लेख किसी खास स्थापना को सुधरा घोषित नहीं करता।

उपकरण खोलें →

स्रोत और दस्तावेज़

← सभी गाइड