स्रोतों की जाँच 22 अक्टूबर, 2026 तक की गई। दर्शक: PHP एप्लिकेशन ऑपरेटर, सुरक्षा उत्तरदाता, और कस्टम PHP बिल्ड बनाए रखने वाले इंजीनियर।

यह आलेख PHP2Shell भेद्यता के कारण, प्रभाव के दायरे, औपचारिक मरम्मत प्रक्रिया, अस्थायी शमन उपायों और आधिकारिक पैच कार्यान्वयन का सारांश देता है। मुख्य पाठ को S1 जैसे संख्याओं का उपयोग करके उद्धृत किया गया है; सभी स्रोत लिंक पाठ के अंत में परिशिष्ट में सूचीबद्ध हैं। कॉन्फ़िगरेशन खंड एक परिनियोजन टेम्पलेट है, जिसे वास्तविक संस्करण, व्यावसायिक क्षमता और कॉन्फ़िगरेशन इनहेरिटेंस संबंध के आधार पर समायोजित करने की आवश्यकता है।

TL;DR: मरम्मत चरण और सुझाव

  1. PHP रनटाइम को अपग्रेड करें: संबंधित शाखा को कम से कम 8.2.35, 8.3.36, 8.4.27 या 8.5.12 पर अपग्रेड करें। वितरण पैकेजों के लिए, पूर्ण पैकेज संस्करण का उपयोग करें जिसकी विक्रेता पुष्टि करता है कि दोनों सीवीई को ठीक करता है। S1S10
  2. सभी पुरानी प्रक्रियाओं को बदलें: अपग्रेड करने के बाद प्रत्येक PHP worker, होस्टिंग सेवा और कंटेनर को पुनरारंभ करें या रोल करें, और पुष्टि करें कि पुराने इंस्टेंस बाहर निकल गए हैं।
  3. वास्तविक Web अनुरोध पथ के माध्यम से सत्यापित करें: Web SAPI, पूर्ण पैकेज संस्करण और चल रहे उदाहरण की जांच करें। अकेले php -v की जाँच करने से यह स्थापित नहीं होता है कि लाइव सेवा ठीक हो गई है।
  4. व्यवसाय प्रतिगमन जांच चलाएं और सामान्य संसाधन बजट पुनर्स्थापित करें: परीक्षण लॉगिन, सत्र प्रबंधन, अपलोड, आयात और त्रुटि प्रबंधन। यदि PHP मेमोरी सीमा अस्थायी रूप से हटा दी गई थी, तो पैचिंग के बाद उचित सीमित बजट पुनर्स्थापित करें।
  5. यदि तत्काल अपग्रेड असंभव है: PHP तक पहुंचने से पहले अविश्वसनीय ट्रैफ़िक को प्रतिबंधित करें। धारा 5 में बताए अनुसार अपलोड प्रगति और PHP 8.5 घातक बैकट्रैस को अक्षम करने का मूल्यांकन करें। कॉन्फ़िगरेशन शमन और WAF नियमों में सीमित कवरेज है और अपग्रेड को प्रतिस्थापित नहीं किया जा सकता है। S1S2S3

1. भेद्यता अवलोकन और जोखिम निर्णय

इस लेख में PHP2Shell 21 अक्टूबर, 2026 को PHP द्वारा आधिकारिक तौर पर प्रकट की गई दो Critical स्तर की कमजोरियों को संदर्भित करता है। दोनों PHP इंजन की मेमोरी और अनुरोध जीवनचक्र प्रबंधन से संबंधित हैं, जो अप्रमाणित रिमोट कोड निष्पादन का खतरा पैदा करते हैं। S1S2S3

प्रोजेक्टCVE-2026-109618CVE-2026-109619
आधिकारिक नामRCE via OOM corruptionRCE via stale global state
मुख्य मुद्देअपर्याप्त मेमोरी एक असामान्य उछाल का कारण बनती है, जिससे ऐसी स्थिति बनती है जिसने अभी तक आरंभीकरण पूरा नहीं किया है।कार्यकर्ता में शेष वैश्विक स्थिति जारी अनुरोध स्मृति को इंगित करती है।
विशिष्ट घटना समयवर्तमान अनुरोध की आरंभीकरण, निष्पादन या सफ़ाई प्रक्रियापिछला अनुरोध स्थिति छोड़ देता है, और बाद के अनुरोध इसे पहले से ही उपभोग कर लेते हैं।
क्या OOM एक आवश्यक शर्त है?भेद्यता के मूल ट्रिगरिंग तंत्र से संबंधित हैनहीं; अन्य घातक त्रुटियाँ और निदान के बाद सफ़ाई भी इसमें शामिल हो सकती है
मौलिक मरम्मत दिशाआवंटन विफलताओं और अनुरोध समाप्ति को सुरक्षित रूप से संभालेंराज्य का स्वामित्व, सफ़ाई का समय और शीघ्र आरंभीकरण ठीक करें
निपटान आवश्यकताएँमरम्मत होनी चाहिएउसी समय मरम्मत की जानी चाहिए

आधार: दो आधिकारिक सुरक्षा बुलेटिन और फिक्स सबमिशन। S2S3S4

1.1 प्रभावित तैनाती को समझना

PHP आधिकारिक तौर पर all PHP तैनाती को Web अनुरोध को जोखिम में मानता है, जिसमें PHP-FPM, Apache mod_php, php-cgi, FrankenPHP और शामिल हैं। LiteSpeed. प्रदर्शित mod_php हमला एप्लिकेशन कोड चलने से पहले हो सकता है, इसलिए लॉगिन जांच, फ्रेमवर्क मिडलवेयर और एप्लिकेशन अपलोड सत्यापन उस पथ को कवर नहीं कर सकते हैं। S1

“तैनाती को ठीक करने की आवश्यकता है” और “एक निश्चित हमले की श्रृंखला पूरी तरह से सिद्ध हो चुकी है” के बीच अंतर करना आवश्यक है। CVE-2026-109618 की घोषणा: अनुरोध स्टार्टअप विफल होने के बाद FPM चाइल्ड प्रक्रिया से बाहर निकल जाएगा, स्टार्टअप विफलता के बाद mod_php के संबंधित सफाई पथ को अवरुद्ध कर देगा; हालाँकि, सफल स्टार्टअप के बाद OOM पथ अभी भी जोखिम में है। घोषणा में यह भी कहा गया है कि इस CVE के लिए पूर्ण FPM शोषण अभी तक प्रदर्शित नहीं किया गया है। इस प्रतिबंध का उपयोग यह निष्कर्ष निकालने के लिए नहीं किया जा सकता है कि FPM सुरक्षित है, विशेष रूप से CVE-2026-109619 को नजरअंदाज नहीं किया जा सकता है। S2S3

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

सामान्य एक बार की CLI स्क्रिप्ट में समान HTTP प्रविष्टि नहीं होती है; लेकिन ऐसी प्रक्रियाएं जो CLI या एम्बेडेड मोड में लंबे समय तक बाहरी कार्यों को संभालती हैं, उन्हें अभी भी रनटाइम और जीवन चक्र सूची में शामिल किया जाना चाहिए। केवल CMS, फ्रेमवर्क या Composer निर्भरताएँ अद्यतन की जाती हैं और अंतर्निहित PHP इंजन स्वचालित रूप से प्रतिस्थापित नहीं होता है।

2. कारण विश्लेषण

2.1 पहले दो जीवन चक्रों को समझें

PHP worker अक्सर एक के बाद एक कई अनुरोधों को संभालता है। अनुरोध के दौरान आवंटित मेमोरी को अनुरोध के अंत में समान रूप से जारी किया जा सकता है, जबकि कार्यकर्ता स्वयं और उसके कुछ वैश्विक क्षेत्र मौजूद रहते हैं।

इसलिए, इंजन को दो बाधाएँ बनाए रखनी चाहिए:

  • प्रारंभिक बाधा: अन्य कोड के लिए दृश्यमान डेटा ऐसी स्थिति में होना चाहिए जिसे सुरक्षित रूप से पढ़ा जा सके, पार किया जा सके और नष्ट किया जा सके।
  • जीवनचक्र बाधा: एक बार अनुरोध मेमोरी मुक्त हो जाने के बाद, लंबे समय तक रहने वाले फ़ील्ड को उस मेमोरी के पते को वैध स्थिति के रूप में जारी नहीं रखना चाहिए।

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

2.2 CVE-2026-109618: OOM ने अधूरे स्टेटस अपडेट को बाधित किया

पुराना कार्यान्वयन OOM को संभालने के लिए longjmp() प्रकार के एक गैर-स्थानीय जंप का उपयोग करता है, और संबंधित पथ zend_bailout() के माध्यम से वर्तमान निष्पादन संदर्भ से बाहर निकलता है। खतरा यह है कि C कोड के एक टुकड़े ने एक नई वस्तु, सरणी, या अन्य कोड के लिए अनुरोध स्थिति प्रकाशित की हो सकती है, लेकिन अभी तक सभी फ़ील्ड आरंभीकरण पूरा नहीं किया है; इस समय, प्रासंगिक समय पर किसी भी आवंटन विफलता के कारण सामान्य समापन चरणों को छोड़ दिया जा सकता है। S2

विफलता प्रक्रिया को चार चरणों में विभाजित किया जा सकता है:

  1. अनुरोध की आंतरिक संरचना बनाएं या अपडेट करें और इसे पहुंच योग्य बनाएं।
  2. बाद में मेमोरी आवंटन विफल हो जाता है और OOM ट्रिगर हो जाता है।
  3. निष्पादन प्रवाह वर्तमान फ़ंक्शन से दूर चला जाता है, और मूल रूप से आरंभीकरण को पूरा करने या स्थिति को पुनर्स्थापित करने के लिए उपयोग किया जाने वाला कोड निष्पादित नहीं होता है।
  4. अनुरोध क्लीनअप इन संरचनाओं को संसाधित करना जारी रखता है और अमान्य सामग्री को वैध फ़ील्ड या पते के रूप में मानता है।

मुद्दा यह नहीं है कि मेमोरी खत्म होने से हमेशा RCE होता है। बल्कि, मेमोरी थकावट नियंत्रण प्रवाह को बदल देती है और वैध संरचनाओं के बारे में इंजन की धारणाओं का उल्लंघन करती है। विफल आवंटन में सीधे तौर पर उस संरचना को शामिल करने की आवश्यकता नहीं है जो अंततः गलत तरीके से पढ़ी जाती है। S2

क्यों छोटे अनुरोधों की भी मेमोरी ख़त्म हो सकती है?

अनुरोध निकाय में बाइट्स की संख्या और पार्सिंग के बाद ढेर का उपयोग एक ही बात नहीं है। A फ़ील्ड PHP के अंदर कई स्ट्रिंग्स, सरणी तत्वों और मेटाडेटा ऑब्जेक्ट के अनुरूप हो सकता है; इनपुट संरचनात्मक जटिलता मेमोरी प्रवर्धन की डिग्री को प्रभावित करेगी।

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

इससे दो सुरक्षात्मक निष्कर्ष निकाले जा सकते हैं:

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

एप्लिकेशन प्रमाणीकरण में बहुत देर क्यों हो सकती है?

mod_php में, अनुरोध आरंभीकरण चरण के दौरान अनुरोध निकाय को स्वचालित रूप से पार्स किया जा सकता है; भले ही स्टार्टअप विफल हो जाए, फिर भी संबंधित अनुरोध क्लीनअप किया जाएगा। इसलिए पुष्टि किए गए आक्रमण पथ एप्लिकेशन कोड से पहले हो सकते हैं। इस स्तर पर एक्सपोज़र को कम करने के लिए, रिवर्स प्रॉक्सी, Web सर्वर, या PHP अनुरोध प्रसंस्करण से पहले की अन्य सीमा पर प्रतिबंध लगाने की आवश्यकता है। S1S2

2.3 CVE-2026-109619: अनुरोध मेमोरी जारी कर दी गई है, वैश्विक संदर्भ अभी भी जीवित है

इस समस्या में त्रुटि, सत्र, ऑब्जेक्ट या एक्सटेंशन स्थिति शामिल है: फ़ील्ड को कार्यकर्ता दीर्घकालिक पहुंच स्थान में संग्रहीत किया जाता है, लेकिन फ़ील्ड द्वारा संदर्भित डेटा एकल अनुरोध से संबंधित होता है। जब तक अनुरोध ढेर जारी होने से पहले संदर्भ को ठीक से साफ़ नहीं किया जाता है, तब तक बाद के अनुरोधों को लटकने की स्थिति का सामना करना पड़ सकता है, जिससे उपयोग-बाद-मुक्त हो सकता है। S3

आधिकारिक विश्लेषण शोषण की स्थितियों को “उत्पादकों” और “उपभोक्ताओं” में विभाजित करता है:

भूमिका या स्थितिअर्थसुरक्षा के लिए निहितार्थ
राज्य निर्माताइस अनुरोध के स्वामित्व वाले राज्य को ऐसे स्थान पर रखें जिस तक बाद में भी पहुंचा जा सकेयह जांचने के लिए कि क्या असामान्य निकास के बाद संबंधित सफाई पूरी हो गई है
स्थिति बनी हुई हैइसे साफ़ नहीं किया गया था, या इसे साफ़ कर दिया गया था और फिर देर से ऑपरेशन द्वारा पुनः भर दिया गया था।पहले शटडाउन चरण में केवल एक बार साफ़ करना पर्याप्त नहीं हो सकता है
कार्यकर्ता पुन: उपयोगवही कार्यकर्ता बाद के अनुरोधों को संसाधित करना जारी रखता हैएकाधिक कार्यकर्ता केवल एक शेड्यूलिंग अंतर है, मेमोरी सुरक्षा की गारंटी नहीं
अग्रिम उपभोक्तासंबंधित स्थिति सामान्य रूप से प्रारंभ होने से पहले अवशिष्ट मान को पढ़ें, जारी करें या निर्धारित करें।आरंभीकरण से पहले INI, सत्र और अन्य पथों की जाँच अवश्य करें

इन शर्तों को संयोजन में पूरा करने की आवश्यकता है; कोई भी त्रुटि लॉग स्वयं यह साबित नहीं करता है कि भेद्यता का सफलतापूर्वक शोषण किया गया है। S3

इसके लिए आवश्यक शर्त के रूप में OOM की आवश्यकता नहीं है

घातक त्रुटियाँ युग्मित राज्य प्रकाशन और पुनर्स्थापना को बाधित कर सकती हैं। संकलन या पार्सिंग विफलताएं, न पकड़ी गई त्रुटियां, require विफलताएं, और निष्पादन टाइमआउट विशेष स्थितियों को पीछे छोड़ सकते हैं। सफ़ाई में देर से किए गए गैर-घातक निदान भी त्रुटि जानकारी को फिर से भर सकते हैं जो पहले ही साफ़ कर दी गई थी। S3

इसलिए, memory_limit को अनलिमिटेड में बदलने से कमजोरियों का यह सेट कवर नहीं होता है।

“आरंभीकरण से पहले” को अलग से व्यवहार करने की आवश्यकता है

दो प्रकार के पुष्ट उपभोक्ताओं का समय अलग-अलग है:

  • प्रारंभिक INI डायग्नोस्टिक्स: अनुरोध पर लागू कुछ कॉन्फ़िगरेशन सामान्य निष्पादक आरंभीकरण से पहले चेतावनी, नोटिस या बहिष्करण जारी करते हैं, और डायग्नोस्टिक प्रसंस्करण पुरानी त्रुटि स्थिति तक पहुंच सकते हैं।
  • सत्र अपलोड प्रगति: अनुरोध बॉडी पार्सिंग प्रक्रिया के दौरान सत्र को पहले से संसाधित किया जा सकता है, लेकिन नियमित मॉड्यूल RINIT अभी तक पूरा नहीं हुआ है; यह अनुमान नहीं लगाया जा सकता कि पथ मौजूद नहीं है क्योंकि एप्लिकेशन स्पष्ट रूप से session_start() को कॉल नहीं करता है। S3

सभी INI कॉन्फ़िगरेशन में समान जोखिम समय नहीं है। mod_php की निर्देशिका-स्तरीय कॉन्फ़िगरेशन और FPM फ्रंट-एंड द्वारा पारित PHP_VALUE / PHP_ADMIN_VALUE को सामान्य php.ini, FPM pool स्टार्टअप कॉन्फ़िगरेशन और FPM .user.ini से अलग करने की आवश्यकता है। बाद वाले का कॉन्फ़िगरेशन समय अलग-अलग होता है और उन्हें सामूहिक रूप से समान प्रारंभिक उपभोक्ता नहीं कहा जा सकता है। S3

display_errors, log_errors को बंद करना, error_reporting को कम करना, या @ का उपयोग करना केवल निदान की दृश्यता को प्रभावित करता है; लॉग को आउटपुट करना है या नहीं, यह तय करने से पहले प्रासंगिक आंतरिक स्थिति तक पहुंच प्राप्त की जा सकती है। S3

3. मरम्मत संस्करण और पैच चयन

3.1 आधिकारिक अपस्ट्रीम फिक्स बेसलाइन

वर्तमान PHP शाखाइस आधिकारिक सुधार को शामिल करने वाला पहला संस्करणसुझाव
8.28.2.35इस संस्करण या समान सुधार वाले अगले संस्करण में अपग्रेड करें
8.38.3.36ऊपर जैसा ही
8.48.4.27ऊपर जैसा ही
8.58.5.12ऊपर जैसा ही
8.1 और पुराने संस्करणअपस्ट्रीम सामान्य समर्थन समाप्त हो गया हैसमर्थित शाखाओं में स्थानांतरण को प्राथमिकता दें; अल्पकालिक चेक रिलीज़ या LTS निर्माता बैकपोर्ट

संस्करण और समर्थन स्थिति PHP की आधिकारिक घोषणा पर आधारित है, और समय आधार रेखा 22 अक्टूबर, 2026 है। S1

ये शाखा-विशिष्ट फिक्स थ्रेशोल्ड हैं। उन्हें इस कथन से प्रतिस्थापित नहीं किया जा सकता है कि 8.5.12 के नीचे का प्रत्येक संस्करण असुरक्षित है: अन्य शाखाओं में 8.2.35 और 8.4.27 जैसे संस्करणों में पहले से ही सुधार मौजूद हैं।

3.2 पूर्ण वितरण पैकेज संस्करण की जाँच करें

डिस्ट्रोज़ अक्सर पुराने अपस्ट्रीम संस्करणों के आधार पर सुरक्षा सुधार जोड़ते हैं। स्वीकृति के लिए रिलीज़ संस्करण, रिपॉजिटरी स्रोत, पूर्ण पैकेज संस्करण और सुरक्षा बुलेटिन की भी जाँच करनी चाहिए।

उदाहरण के लिए, Ubuntu USN-8948-1 के लिए सूचीबद्ध Ubuntu 24.04 LTS फिक्स पैकेज संस्करण है:

8.3.6-0ubuntu0.24.04.13

इसका अपस्ट्रीम भाग अभी भी 8.3.6 है, लेकिन उस वितरण का पूर्ण पैकेज संस्करण इस फिक्स घोषणा में शामिल है। यह निष्कर्ष केवल संबंधित वितरण और पैकेज स्रोत पर लागू होता है, और इसे किसी भी बिल्ड के लिए सामान्यीकृत नहीं किया जा सकता है जो 8.3.6 भी प्रदर्शित करता है। S10

3.3 सही पैच चुनना

दृश्यप्राथमिकता योजनास्वीकृति हेतु मुख्य बिंदु
वितरण PHP पैकेज का उपयोग करनानिर्माता द्वारा जारी सुरक्षा अद्यतन स्थापित करेंघोषणा में CVE दोनों शामिल हैं; संपूर्ण पैकेज संस्करण सही है
आधिकारिक PHP कंटेनर या स्व-निर्मित छवि का उपयोग करेंबेस रनटाइम को अपडेट करें, पुनर्निर्माण करें और तैनात करेंचल रहा उदाहरण नई छवि का उपयोग करता है; सभी पुरानी प्रतियाँ बाहर हो गई हैं
स्व-संकलित समर्थित शाखाएँइस शाखा के आधिकारिक सुरक्षा संस्करण या पूर्ण आधिकारिक पैच सेट का उपयोग करेंशाखा मिलान, निर्भरता पूर्णता, विस्तार अनुकूलता और प्रतिगमन पासिंग
7.4, 8.0, 8.1 के अधीनविक्रेता बैकपोर्ट को प्राथमिकता दें; यदि आवश्यक हो तो आधिकारिक आपातकालीन स्रोत कोड शाखा का मूल्यांकन करेंव्यवहारिक परिवर्तनों की पहचान करें और समर्थित संस्करणों में माइग्रेशन शेड्यूल करें

आधिकारिक पैच जारी कर दिए गए हैं, और वास्तविक सुधार इन पैच से शुरू होने चाहिए। धारा 6 में कोड स्निपेट का उद्देश्य डिज़ाइन को चित्रित करना और हाइलाइट्स की समीक्षा करना है और यह एक पूर्ण पैच का गठन नहीं करता है जिसे स्वतंत्र रूप से लागू किया जा सकता है। S1S4S6

4. औपचारिक मरम्मत प्रक्रिया

4.1 रनटाइम की सूची जो वास्तव में अनुरोधों को संभालती है

कम से कम रिकॉर्ड करने के लिए एक संक्षिप्त खाता बनाने की अनुशंसा की जाती है:

  • प्रविष्टि डोमेन नाम या सेवा, रिवर्स प्रॉक्सी बैकएंड, PHP SAPI।
  • PHP शाखा, पूर्ण पैकेज संस्करण या छवि डाइजेस्ट, स्रोत बनाएँ।
  • FPM pool, वास्तविक सेवा इकाई, कंटेनर या Pod, प्रतिकृतियों की संख्या।
  • एक्सटेंशन, मुख्य कॉन्फ़िगरेशन और अतिरिक्त कॉन्फ़िगरेशन फ़ाइलें लोड कर दी गई हैं।
  • क्या अन्य PHP संस्करण, पुरानी परिनियोजन प्रतियां, या मूल पोर्टल हैं जिन तक सीधे पहुंचा जा सकता है?

ये कार्यान्वयन सुझाव हैं ताकि “अपग्रेड” प्रत्येक वास्तविक ट्रैफ़िक प्रविष्टि के अनुरूप हो सके। विशेष रूप से जांचें कि क्या कमांड लाइन PHP और Web PHP विभिन्न संस्करणों का उपयोग करते हैं, छवि बनाई गई है लेकिन पुराना कंटेनर अभी भी चल रहा है, पूल का हिस्सा या प्रतिलिपि प्रतिस्थापित नहीं की गई है, आदि।

4.2 सही अद्यतन का चयन करें और तैनात करें

धारा 3 के अनुसार फिक्स संस्करण की पुष्टि करें, अधिमानतः मौजूदा विश्वसनीय पैकेज स्रोत या नियंत्रित बिल्ड श्रृंखला का उपयोग करें। अद्यतन दायरे में वह घटक शामिल होना चाहिए जो वास्तव में अनुरोध को होस्ट करता है, जैसे FPM पैकेज, Apache PHP मॉड्यूल, CGI बाइनरी, या सेवा बिल्ड जिसमें PHP एम्बेडेड है।

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

4.3 चल रहे इंस्टेंस को पुनरारंभ करें या रोल ओवर करें

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

mod_php के लिए, मॉड्यूल को होस्ट करने वाली Apache प्रक्रिया को पुनरारंभ करें। PHP को एम्बेड करने वाली सेवाओं को उनकी होस्टिंग प्रक्रिया को बदलने की आवश्यकता है। FPM के लिए, OPcache को साफ़ करना रनटाइम को अपडेट करने और पुराने कर्मचारियों को सेवानिवृत्त करने का स्थान नहीं लेता है।

ग्रेसफुल स्विचिंग का उपयोग करते समय, आपको यह जांचना होगा कि क्या पुरानी पीढ़ी की प्रक्रिया अभी भी लंबे कनेक्शन या बकाया अनुरोधों को संभाल रही है। स्वीकृति रिकॉर्ड में वास्तविक सेवा, परिनियोजन संस्करण, परिवर्तन पूरा होने का समय और पुराने उदाहरण के निकास परिणाम शामिल होने चाहिए।

4.4 वास्तविक Web अनुरोधों के माध्यम से सत्यापित करें

केवल एकल संस्करण कमांड पर निर्भर रहने के बजाय साक्ष्य के निम्नलिखित टुकड़ों को संयोजित करने की अनुशंसा की जाती है:

साक्ष्यक्या साबित किया जा सकता हैअकेले कुछ भी साबित नहीं कर सकते
पैकेज प्रबंधक या छवि मेटाडेटास्थापना स्रोत और पूर्ण निर्माणइस उदाहरण पर ट्रैफ़िक स्विच कर दिया गया है
प्रक्रिया एवं परिनियोजन स्थितिकर्मचारी या कंटेनर प्रतिस्थापन पूरा करता हैबाहरी प्रवेश द्वार को इसमें रूट किया जाना चाहिए
वास्तविक पोर्टल के माध्यम से प्रतिबंधित नैदानिक परिणाम प्राप्त किये जा सकते हैंवास्तविक Web SAPI और चालू कॉन्फ़िगरेशनक्या रिलीज़ बैकपोर्ट दो CVE को कवर करता है
विक्रेता की घोषणा या संपूर्ण पैच रिकॉर्डयह बग फिक्स इस बिल्ड में शामिल हैसभी प्रतिकृतियां तैनात हैं

PHP_VERSION, PHP_SAPI, लोड की गई कॉन्फ़िगरेशन फ़ाइलें और आपातकालीन कॉन्फ़िगरेशन को मौजूदा आंतरिक डायग्नोस्टिक क्षमताओं, या अस्थायी और एक्सेस-नियंत्रित डायग्नोस्टिक पोर्टल के माध्यम से जांचा जा सकता है। सुनिश्चित करें कि अनुरोध सीधे CDN या पेज कैश द्वारा वापस नहीं किया गया है; पूरा होने पर अस्थायी निदान प्रविष्टि हटा दें।

php -v आमतौर पर केवल शेल द्वारा वर्तमान में चयनित CLI बाइनरी को इंगित करता है; php-fpm -i जैसे आदेश ट्रैफ़िक प्राप्त करने वाले मौजूदा कर्मचारी को सत्यापित करने के बराबर नहीं हैं। पूरे phpinfo() पेज को लंबे समय तक सार्वजनिक नेटवर्क पर उजागर न करें।

4.5 बिजनेस रिग्रेशन जांच और आपातकालीन सेटिंग्स को हटाना

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

यदि memory_limit=-1 अस्थायी रूप से सेट किया गया है, तो आधिकारिक पैच प्रभावी होने के बाद व्यावसायिक क्षमता से मेल खाने वाला सीमित बजट बहाल किया जाएगा; यदि pm.max_requests=1 सेट है, तो मरम्मत की पुष्टि होने के बाद क्षमता-मूल्यांकन जीवन चक्र कॉन्फ़िगरेशन बहाल किया जाएगा। व्यावसायिक आवश्यकताओं के अनुसार इनपुट आकार सीमाएं और स्रोत पहुंच नियंत्रण बनाए रखा जा सकता है।

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

5. जब तत्काल उन्नयन संभव न हो तो शमन उपाय

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

5.1 PHP से पहले यातायात नियंत्रण को प्राथमिकता दें

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

ये प्रतिबंध PHP के सभी प्रवेश द्वारों को कवर करने के लिए हैं। केवल “अपलोड” नामक URL को इंटरसेप्ट करने से अन्य प्रविष्टियाँ छूट जाएंगी जो अभी भी अनुरोध निकाय में PHP द्वारा स्वचालित रूप से पार्स की जाती हैं। खंडित स्थानांतरण, उपलब्ध घोषित लंबाई की कमी आदि जैसे मामलों के लिए, सीमा वास्तविक पढ़ने के आकार पर आधारित होनी चाहिए; सामग्री को फिर से डीकंप्रेस या विस्तारित करते समय एप्लिकेशन के पास अपना स्वयं का आउटपुट आकार बजट भी होना चाहिए।

5.2 FPM pool कॉन्फ़िगरेशन टेम्पलेट

निम्नलिखित सेटिंग्स को FPM pool कॉन्फ़िगरेशन अनुभाग में रखें जो वास्तव में अनुरोधों को प्रस्तुत करता है, php.ini में शब्दशः नहीं। 8M और 4M मान कार्यभार के लिए समायोजित करने के उदाहरण हैं। संपूर्ण POST अनुरोध को सीमित करते समय फॉर्म फ़ील्ड और मल्टीपार्ट सीमाओं के लिए जगह छोड़ें। S11S12

; Temporary mitigation: evaluate capacity before applying.
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 4M
php_admin_flag[session.upload_progress.enabled] = off

केवल PHP 8.5, प्लस:

php_admin_flag[fatal_error_backtraces] = off

प्रत्येक के कार्य और सीमाएँ इस प्रकार हैं:

विन्यासअपेक्षित प्रभावउन प्रतिबंधों का विवरण जिन्हें बरकरार रखा जाना चाहिए
memory_limit=-1पूर्वानुमानित PHP अनुरोध मेमोरी ऊपरी सीमा ट्रिगर स्थिति को हटा देंयह अंतर्निहित आवंटन विफलता को नहीं रोकता है; मूल बजट रद्द करने से मेमोरी समाप्त होने और सेवा बाधित होने का खतरा बढ़ सकता है।
छोटा post_max_sizeपार्सिंग प्रक्रिया में प्रवेश करने वाले डेटा का आकार कम करेंअनफ़िक्स्ड पार्सर में ज्ञात गैप है; स्मृति प्रवर्धन को स्वतंत्र रूप से रोका नहीं जा सकता
upload_max_filesize < post_max_sizeएकल फ़ाइल आकार सीमित करें और अनुरोध ओवरहेड स्थान आरक्षित करेंसभी फ़ील्ड, मेटाडेटा, या इन-ऐप आवंटन को बाधित नहीं करता है
अपलोड प्रगति बंद करेंपुष्टि किए गए सत्र संबंधी पथ को ब्लॉक करेंअन्य वैश्विक राज्य वेरिएंट को कवर नहीं करता है
PHP 8.5 घातक बैकट्रेस बंद करेंब्लॉक ने संबंधित स्थिति उत्पादकों की पुष्टि कीसत्र जैसे अन्य पथों को कवर नहीं करता है

माप की सीमाएँ आधिकारिक घोषणा से आती हैं; पूल सिंटैक्स और प्रबंधन-स्तरीय कॉन्फ़िगरेशन शब्दार्थ के लिए, PHP मैनुअल देखें। S1S2S3S11

प्रबंधन-स्तर php_admin_* सेटिंग्स को ini_set() के माध्यम से अनुप्रयोगों द्वारा ओवरराइड नहीं किया जा सकता है। यह पुष्टि करने के लिए कि वास्तविक अनुरोधों पर मान अपेक्षित हैं, सभी पूल, निर्देशिका-स्तर और फ्रंट-एंड आने वाली कॉन्फ़िगरेशन की अभी भी समीक्षा की जानी चाहिए। संशोधन के बाद, मौजूदा प्रक्रियाओं को पुरानी स्थिति में बने रहने से रोकने के लिए सभी कार्यकर्ताओं का पुनर्निर्माण करें।

यदि आप सीधे php.ini को संशोधित करना चुनते हैं, तो सिंटैक्स को इसमें बदला जाना चाहिए:

memory_limit = -1
post_max_size = 8M
upload_max_filesize = 4M
session.upload_progress.enabled = Off

पूल में php_admin_value के विपरीत, केवल php.ini में memory_limit=-1 सेट करने से ऐप को इसे दोबारा संशोधित करने से नहीं रोका जा सकता है। यह देखने के लिए फ्रेमवर्क, एप्लिकेशन कोड और अन्य कॉन्फ़िगरेशन की जांच की जानी चाहिए कि क्या उन्होंने सीमित मान को रीसेट कर दिया है; जब प्रवर्तन की आवश्यकता हो, तो वर्तमान SAPI के लिए उपयुक्त प्रबंधन-स्तरीय सेटिंग्स का उपयोग करें और वास्तविक प्रभावी मूल्य की जांच करें। S11S12

केवल PHP 8.5 के लिए fatal_error_backtraces = Off जोड़ें। अपलोड प्रगति को अक्षम करने के लिए वर्कअराउंड के रूप में एप्लिकेशन-स्तर ini_set() का उपयोग न करें, और अनुरोध पार्सिंग से पहले इसे प्रभावी बनाने के लिए FPM .user.ini पर भरोसा न करें। S1S3

5.3 PHP मेमोरी सीमाएं हटाने की लागत प्रबंधित करें

memory_limit=-1 अनिर्धारित वातावरण के लिए एक अस्थायी पथ शमन है और इसे दीर्घकालिक डिफ़ॉल्ट कॉन्फ़िगरेशन के रूप में कॉपी नहीं किया जाना चाहिए। जब कोई एप्लिकेशन या अनुरोध नियंत्रण से बाहर हो जाता है, तो यह होस्ट की अधिक मेमोरी का उपयोग कर सकता है। इसलिए, उपयोग करने से पहले, आपको संगामिति की संख्या, अधिकतम एकल कार्यकर्ता और कुल सेवा क्षमता का मूल्यांकन करना चाहिए और फ्रंट-एंड इनपुट सीमाओं को तैनात करना चाहिए। S2

कंटेनर या सीग्रुप मेमोरी सीमाएँ उपलब्धता सीमाएँ प्रदान कर सकती हैं लेकिन यह गारंटी नहीं देती हैं कि आवंटन कभी विफल नहीं होंगे; सीमा शुरू होने पर संपूर्ण कंटेनर, मास्टर और सभी श्रमिकों को भी समाप्त किया जा सकता है। अलगाव ग्रैन्युलैरिटी और समाप्ति रणनीतियों को तैनाती के साथ संयोजन में मूल्यांकन करने की आवश्यकता है और इन दो CVE के लिए पूर्ण सुरक्षा नहीं कहा जा सकता है। S2

उपरोक्त रणनीतियों को RLIMIT_AS, RLIMIT_DATA, या संबंधित प्रक्रिया पता स्थान प्रतिबंधों से प्रतिस्थापित न करें; वे सीधे तौर पर अंतर्निहित आवंटन को अभी भी समस्याग्रस्त OOM पथ में विफल कर सकते हैं। S2

5.4 Nginx कॉन्फ़िगरेशन उदाहरण

तैनाती के लिए लागू जहां Nginx अनुरोधों को PHP-FPM पर अग्रेषित करता है। इसे वास्तविक होस्टिंग सेवा के कॉन्फ़िगरेशन स्तर पर सेट किया जा सकता है:

client_max_body_size 8m;
fastcgi_request_buffering on;

client_max_body_size अनुरोध के मुख्य भाग के आकार को सीमित करता है; fastcgi_request_buffering on Nginx को पहले पूरा अनुरोध निकाय पढ़ने देता है और फिर इसे फास्टसीजीआई बैकएंड पर भेजता है। क्या यह किसी निश्चित server या location में प्रभावी होता है, इसे मौजूदा विरासत और कवरेज संबंधों के संयोजन में जांचने की आवश्यकता है। S13S14

केवल जब व्यवसाय को मल्टीपार्ट की आवश्यकता नहीं होती है, तो आप संबंधित सेवा प्रवेश में अस्वीकृति नियम जोड़ सकते हैं:

if ($http_content_type ~* "multipart/form-data") {
    return 403;
}

यह if और return का उपयोग करने वाला एक सरल प्रवेश प्रतिबंध टेम्पलेट है, पार्सर कमजोरियों के लिए सामान्य फ़िल्टरिंग नियम नहीं है। तैनाती से पहले कॉन्फ़िगरेशन सिंटैक्स और सामान्य अनुरोधों को सत्यापित करें, और जांचें कि कस्टम error_page 403 अनुरोधों को PHP पर रीडायरेक्ट करता है या नहीं। स्ट्रिंग मिलान सभी पार्सिंग अंतरों पर पूर्ण गारंटी प्रदान नहीं करता है। S15

इसके अलावा, ये कॉन्फ़िगरेशन स्वचालित रूप से डेटा की मात्रा, फ़ील्ड की संख्या, या PHP ऑब्जेक्ट की संख्या को सीमित नहीं करते हैं जिन्हें एप्लिकेशन द्वारा डीकंप्रेस किया जा सकता है; जिन व्यवसायों को अपलोड करने की आवश्यकता है, उन्हें अतिरिक्त प्रतिबंधों का उपयोग करना चाहिए जो उनके अनुरोधों की संरचना को समझते हैं।

5.5 वैकल्पिक शमन: प्रति FPM कार्यकर्ता एक अनुरोध

FPM परिनियोजन के लिए जो ओवरहेड वहन कर सकते हैं, अल्पकालिक सेटअप का मूल्यांकन किया जा सकता है:

pm.max_requests = 1

और मौजूदा कार्यकर्ता का पुनर्निर्माण करें। यह कार्यकर्ता के पुन: उपयोग स्तर पर वर्णित क्रॉस-अनुरोध श्रृंखला को अवरुद्ध करता है, लेकिन प्रक्रिया निर्माण और आरंभीकरण ओवरहेड को बढ़ा देगा; साथ ही, यह समान अनुरोध OOM और CVE-2026-109618 की सफाई समस्याओं की मरम्मत नहीं कर सकता है। जब मान छोटा होता है लेकिन 1 से अधिक होता है, तब भी एक अनुरोध पुन: उपयोग विंडो होती है। S3S11

5.6 WAF और Cloudflare कवरेज सीमाएं

Cloudflare ने Free योजना सहित PHP2Shell के खिलाफ सुरक्षा के लिए तैनाती व्यवस्था की घोषणा की है। इसकी सेवाओं का उपयोग करते समय, आपको यह जांचना चाहिए कि क्या वास्तविक ट्रैफ़िक प्रॉक्सी से होकर गुजरता है, क्या सुरक्षा नियम प्रभावी हैं, और क्या मूल साइट को सीधे बायपास किया जा सकता है; सशुल्क योजनाओं के लिए, आपको संबंधित प्रबंधित नियमों के कॉन्फ़िगरेशन और अपवादों की भी जांच करनी होगी। S16

विक्रेता द्वारा वर्णित कुछ जांचें प्रतिक्रिया संकेतों का उपयोग करती हैं, इसलिए सभी सुरक्षा की व्याख्या इस प्रकार नहीं की जा सकती है कि “प्रत्येक हमले को PHP तक पहुंचने से पहले अवरुद्ध कर दिया जाता है”। WAF जोखिम को कम करने और अवलोकन संबंधी जानकारी प्रदान करने में मदद कर सकता है, लेकिन PHP में निरंतर उन्नयन अभी भी आवश्यक है। S16

5.7 सामान्य उपाय अपर्याप्त क्यों हैं?

उपाय या निर्णयकमियाँ
केवल file_uploads बंद करेंसभी मल्टीपार्ट प्रोसेसिंग को कवर नहीं कर सकता और अपना स्वयं का OOM पथ लागू नहीं कर सकता
enable_post_data_reading=Off सेट करनाPOST/FILES को स्वचालित रूप से भरने का व्यवहार बदलें; अनुरोध का मुख्य भाग अभी भी एप्लिकेशन द्वारा पढ़ा जा सकता है और सामान्य व्यवसाय को बाधित कर सकता है
त्रुटि प्रदर्शन बंद करें, लॉग इन करें या @ का उपयोग करेंआंतरिक निदान प्रसंस्करण अभी भी लटकती स्थिति तक पहुंच सकता है
श्रमिकों की संख्या बढ़ाएँएक सुरक्षित राज्य सफाई तंत्र स्थापित न करें, न ही एकल कार्यकर्ता के पुन: उपयोग को समाप्त करें
केवल disable_functions या open_basedir कॉन्फ़िगर करेंये सीमाएँ C इंजन परत मेमोरी भ्रष्टाचार को ठीक नहीं करती हैं
किसी संस्करण या एकल प्रति को केवल एक बार जांचेंयह साबित नहीं किया जा सकता कि सभी प्रवेश द्वार और चालू इंस्टेंस बदल दिए गए हैं
कोई अपवाद लॉग नहीं देखा गयायह साबित नहीं कर सकता कि भेद्यता मौजूद नहीं है या इसका पहले शोषण नहीं किया गया है।

उनमें से, PHP का कॉन्फ़िगरेशन और भेद्यता तंत्र आधार S2S3S12 में पाया जा सकता है; कवरेज, स्वीकृति और अनुमति सीमाओं के बारे में निर्णय इन तंत्रों द्वारा प्रस्तुत कार्यान्वयन सुझावों पर आधारित हैं।

6. आधिकारिक पैच के कार्यान्वयन विचार और समीक्षा बिंदु

6.1 सही शाखा के लिए पूर्ण सुधार का उपयोग करें

PHP 8.5 के लिए प्रतिनिधि आधिकारिक प्रस्तुतिकरण है:

31c0ea7d7ff1d1fccb6492e52dab544011628065
Avoid state corruption via bailout

प्रतिबद्धता स्पष्ट रूप से दो सीवीई को जोड़ती है, दोनों OOM निकास तंत्र को समायोजित करने और वैश्विक स्थिति को ठीक करने के लिए जिसे आरंभीकरण चरण के दौरान एक्सेस किया जा सकता है। पूरे अंतर के साथ पेज सबमिट करें S4S5 देखें। अन्य शाखाओं को अपनी स्वयं की आधिकारिक सुरक्षा रिलीज़ या मिलान पैच का उपयोग करना चाहिए, और यह नहीं माना जा सकता है कि 8.5 में परिवर्तन सीधे किसी भी पुराने संस्करण पर लागू किया जा सकता है।

6.2 OOM मरम्मत: पहले प्रक्रिया योग्य स्थिति को पुनर्स्थापित करें, और फिर अनुरोध को समाप्त करें

औपचारिक कार्यान्वयन नरम और कठोर OOM प्रसंस्करण के दो स्तरों का परिचय देता है: जब नरम सीमा पूरी हो जाती है, तो लंबित स्थिति दर्ज की जाती है, और VM जैसे सुरक्षित स्थान पर एक नियंत्रित निकास किया जाता है; असफल आवंटन इंटरफ़ेस कॉलर को विफलता को स्पष्ट रूप से संभालने की अनुमति देता है। उन आवंटनों के लिए जो सीधे विफलता नहीं दे सकते हैं, यदि उच्च हार्ड सीमा पार होने की उम्मीद है, तो असुरक्षित मध्यवर्ती स्थिति में अनुरोधों को जारी रखने से बचने के लिए प्रक्रिया को सीधे समाप्त कर दिया जाएगा। S2S5

निम्नलिखित 8.5 अंतर में कुंजी कोड का एक अंश है जिसका उपयोग लंबित OOM को चिह्नित करने के लिए किया जाता है:

EG(delayed_oom).state = ZEND_OOM_STATE_PENDING;
zend_atomic_bool_store_ex(&EG(vm_interrupt), true);

VM इंटरप्ट हैंडलिंग और अन्य सुरक्षित स्थानों के लिए बाद में zend_handle_delayed_oom() पर कॉल करें। इसका उपयोगकर्ता कोड निष्पादन संदर्भ एक नियंत्रित अनवाइंड पथ का उपयोग करता है; कठिन OOM पथ _exit(137) को कॉल करता है। S5

डिज़ाइन के दृष्टिकोण से, महत्वपूर्ण परिवर्तन हैं: मनमाने ढंग से पार करने से बचता है C जब संरचना मध्यवर्ती स्थिति में हो तो स्टैक को कॉल करें और निकास को एक स्थान पर रखें जो राज्य की बाधाओं को बनाए रख सकता है। सॉफ्ट लिमिट ट्रिगर होने के बाद, प्रक्रिया को पूरा करने के लिए अतिरिक्त मेमोरी की आवश्यकता हो सकती है, इसलिए नई सॉफ्ट थ्रेशोल्ड को प्रक्रिया की कुल मेमोरी के लिए पूर्ण ऊपरी सीमा के रूप में नहीं समझा जा सकता है।

न ही इसे “PHP ने सभी zend_bailout() हटा दिया है” के रूप में संक्षेपित किया जा सकता है। पैच अभी भी विशिष्ट संदर्भों में प्रासंगिक तंत्र का उपयोग करता है; जो तय किया गया है वह खतरनाक निकास समय और उसके साथ जुड़ा राज्य प्रबंधन है। S5

6.3 आवंटन कॉलर्स और मल्टीपार्ट पार्सिंग को एक साथ अपडेट करें

यदि आप आवंटन फ़ंक्शन को केवल “विफलता पर शून्य लौटाएं” में बदलते हैं और मूल कॉलर अभी भी मानता है कि एक वैध सूचक हमेशा लौटाया जाता है, तो आप नए शून्य सूचक एक्सेस या अपूर्ण सफाई पेश करेंगे। पैच में विफल आवंटन इंटरफ़ेस की कॉलर जांच और अपवाद प्रसार के साथ समीक्षा की जानी चाहिए। S5

मल्टीपार्ट संबंधित सुधारों में वास्तविक रीड वॉल्यूम के आधार पर संचयी जांच करना, बेकार या डुप्लिकेट हेडर की प्रोसेसिंग को कम करना और OOM लंबित होने पर लगातार निकास और सफाई तर्क को अपनाना शामिल है। ये परिवर्तन संसाधन प्रवर्धन को कम करते हैं और पार्सर को नए OOM प्रोटोकॉल का अनुपालन करते हैं। S5

अपनी स्वयं की शाखाएँ बनाए रखने वाली टीमों के लिए, यह अनुशंसा की जाती है कि निम्नलिखित मुद्दों पर कोड समीक्षा का ध्यान केंद्रित किया जाए:

  • क्या राज्य पूरी तरह आरंभ होने से पहले बाहरी दुनिया को दिखाई देता है?
  • आवंटन विफलता या कॉलबैक अपवाद के बाद, क्या स्वामित्व अभी भी अद्वितीय और स्पष्ट है?
  • यदि आप बीच में असफल हो जाते हैं तो क्या आप एकीकृत सफाई निकास तक पहुँच सकते हैं?
  • क्या क्लीनअप फ़ंक्शन अप्रारंभीकृत या मुक्त फ़ील्ड को पहचान सकता है?
  • क्या पार्सिंग बजट वास्तविक प्रसंस्करण मात्रा पर आधारित है, न कि केवल विश्वास अनुरोध दावों पर?
  • क्या नया विफलता रिटर्न मान सभी कॉलर्स द्वारा प्रबंधित किया गया है?

ये फिक्स मैकेनिज्म के आधार पर सारांशित किए गए समीक्षा प्रश्न हैं, और एक ऑडिट का निष्कर्ष नहीं है जो एक अप्रकाशित कोड आधार के लिए पूरा किया गया है।

6.4 क्रॉस-रिक्वेस्ट फिक्स: आरंभीकरण पहले, अंतिम सफाई बाद में

CVE-2026-109619 के अनुरूप, पैच एक ही समय में कई जीवन चक्र सीमाओं को समायोजित करता है। नीचे सूचीबद्ध फ़ाइलें और संचालन एक उदाहरण के रूप में PHP 8.5 आधिकारिक अंतर लेते हैं। S5

स्थानदिशा बदलेंसमस्या हल हो गई
Zend/zend_execute_API.c आदि।निष्पादक स्थिति जैसे त्रुटियाँ, अपवाद, हैंडलर, ऑब्जेक्ट आदि को रीसेट करें।अनुरोध समाप्त होने के बाद, अभी भी पुराने संदर्भ हैं जिन तक अगले अनुरोध तक पहुंचा जा सकता है।
main/main.c का स्टार्टअप पथSAPI सक्रिय होने से पहले php_basic_early_rinit() पर कॉल करेंजब कोई प्रारंभिक उपभोक्ता होता है, तो प्रासंगिक अंतर्निहित स्थिति अभी तक प्रारंभ नहीं की गई है।
main/main.c का रास्ता बंद करेंHTTP globals को नष्ट करें और इसे अपरिभाषित के रूप में चिह्नित करेंजारी मूल्य को अभी भी एक वैध वस्तु माना जाता है
अनुरोध ढेर अंततः मुक्त होने से पहलेअंतिम त्रुटि संदेश को दोबारा साफ़ करेंदेर से क्लीनअप डायग्नोस्टिक्स त्रुटि स्थिति को दोबारा दिखाता है
ext/session/session.cअपलोड प्रगति प्रारंभिक पथ प्रथम सत्र ग्लोबल्स प्रारंभ किया गया हैनियमित मॉड्यूल RINIT पहले पुरानी स्थिति तक पहुँचा
क्रमांकन संबंधी कोडप्रारंभिक प्रसंस्करण में क्लास पार्सिंग और उपयोगकर्ता कॉलबैक को सीमित करेंआरंभीकरण पूरा न होने पर अतिरिक्त उपयोगकर्ता कोड निष्पादित करें

उदाहरण के लिए, स्टार्टअप अनुक्रम में शामिल हैं:

zend_activate();
php_basic_early_rinit();
sapi_activate();

HTTP globals नष्ट हो जाने के बाद, स्थिति विफलता चिह्न जोड़ें:

zval_ptr_dtor(&PG(http_globals)[i]);
ZVAL_UNDEF(&PG(http_globals)[i]);

ये अंश दो सिद्धांतों का वर्णन करते हैं: XZ को जल्द से जल्द संभावित उपभोक्ता से पहले आरंभ करें, और अंतिम ऑपरेशन के बाद अंतिम सफाई करें जो स्थिति को फिर से बना सकता है। केवल सामान्य RINIT या पहले के शटडाउन चरण के दौरान एक पॉइंटर को रीसेट करने से पहले या बाद की पहुंच छूट सकती है। S5

6.5 अपनी खुद की “वन-लाइन मरम्मत” करने की अनुशंसा क्यों नहीं की जाती है?

सभी zend_bailout() को _exit() से बदलना, या बस एक निश्चित प्रविष्टि पर एक शून्य सूचक जांच जोड़ना, बड़ी संख्या में विभिन्न निष्पादन संदर्भों को फैलाएगा। वे अन्य स्थिति फ़ील्ड को छोड़ सकते हैं, या वे विनाश, विस्तारित कॉलबैक, प्रक्रिया होस्टिंग और अंतिम शब्दार्थ का अनुरोध बदल सकते हैं।

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

7. PHP 7.4, 8.0, 8.1 का आपातकालीन बैकपोर्ट

PHP आधिकारिक तौर पर गंभीरता के आधार पर तीन पुरानी शाखाओं का न्यूनतम स्रोत कोड बैकपोर्ट प्रदान करता है। शाखा के नाम हैं:

PHP-7.4-CVE-2026-109618-109619
PHP-8.0-CVE-2026-109618-109619
PHP-8.1-CVE-2026-109618-109619

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

7.1 उदाहरण के तौर पर PHP 8.1 बैकपोर्ट लें

PHP 8.1 के लिए प्रासंगिक प्रस्तुतियाँ हैं:

1d7dec178a094e6e75b229ce22754045f8c6070a

इसकी रणनीति तेजी से विफल होने का समर्थन करती है: संबंधित OOM पथ में डायग्नोस्टिक्स आउटपुट करने के बाद _exit(1) को कॉल करना, और वैश्विक स्थिति और अन्य प्रासंगिक सुधारों को शामिल करना; सत्र अपलोड प्रगति की संबंधित प्रोसेसिंग को आंतरिक रूप से अक्षम करते हुए। प्रासंगिक स्रोत कोड प्रस्तुत करने के लिए, S6 देखें।

यह समर्थित शाखा में अधिक पूर्ण विलंबित OOM डिज़ाइन से एक व्यवहारिक अंतर है। सिर्फ इसलिए कि कॉन्फ़िगरेशन अभी भी दिखाता है कि अपलोड प्रगति जारी है, इसका मतलब यह नहीं है कि इस बैकपोर्ट के बाद आंतरिक प्रसंस्करण व्यवहार अपरिवर्तित रहेगा।

7.2 वह कीमत जो आपको तैनात करते समय स्वीकार करनी होगी

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

इसलिए, पुराने संस्करणों के उपयोगकर्ताओं को क्रम में विचार करना चाहिए:

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

यहां “न्यूनतम बैकपोर्ट” अधिकारी द्वारा चयनित अनुकूलता और कार्यान्वयन दायरे का वर्णन करता है, और इसे स्वचालित रूप से “ज्ञात अपूर्ण भेद्यता समाधान” के रूप में व्याख्या नहीं किया जाना चाहिए। आपको संबंधित शाखा के स्रोत कोड और निर्माता की घोषणा के आधार पर निर्णय लेना चाहिए, और सहायक परिवर्तनों को स्वयं नहीं हटाना चाहिए। S1S6

8. स्वीकृति मानदंड और अनुवर्ती निरीक्षण

यह अनुशंसा की जाती है कि इस मरम्मत को पूरा करने के लिए निम्नलिखित परिणामों को आधार के रूप में उपयोग किया जाए:

स्वीकृति आइटमसमापन मानक
भेद्यता कवरेजबिल्ड या विक्रेता घोषणा स्पष्ट रूप से CVE-2026-109618 और CVE-2026-109619 को ठीक करती है
परिनियोजन कवरेजसभी पोर्टल, पूल, सेवाएँ और प्रतिकृतियाँ मरम्मत किए गए रनटाइम का उपयोग करती हैं
प्रक्रिया प्रभावी होती हैपुराना वर्कर, पुराना होस्ट प्रोसेस और पुराना कंटेनर सभी बाहर निकल जाते हैं
प्रामाणिक अनुरोध सत्यापनपुष्टिकृत SAPI, कैश गलत दिशा को खत्म करने के लिए वास्तविक Web लिंक के साथ निर्मित और कॉन्फ़िगर किया गया
व्यवसाय उपलब्धतासत्र, अपलोडिंग, आयात और त्रुटि प्रबंधन जैसे प्रमुख कार्य सामान्य रूप से वापस आ गए हैं।
अस्थायी उपायों की समाप्तिअसीमित मेमोरी और चरम कार्यकर्ता रीसाइक्लिंग कॉन्फ़िगरेशन को क्षमता योजना के अनुसार बहाल किया गया है या प्रतिधारण का स्पष्ट कारण है
बदलाव का सबूतपैकेज संस्करण या छवि डाइजेस्ट, अद्यतन दायरा, पूरा होने का समय और सत्यापन परिणाम रिकॉर्ड करें

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

अद्यतन से पहले और बाद में PHP घातक, कार्यकर्ता दुर्घटना, असामान्य पुनरारंभ, अनुरोध त्रुटि दर और WAF घटनाओं की भी जाँच करें। लॉग केवल जांच सुराग प्रदान कर सकते हैं: OOM की घटना का मतलब यह नहीं है कि इसका शोषण किया गया है, और अलार्म की कमी यह साबित नहीं करती है कि कोई शोषण नहीं हुआ है। अपग्रेड उन भेद्यता पथों को ठीक करता है जिन तक भविष्य में पहुंचा जा सकता है; यदि फ़ाइल से छेड़छाड़ या क्रेडेंशियल लीक जैसी विसंगतियाँ पाई जाती हैं, तो अलग से घटना की जाँच की जानी चाहिए।

परिशिष्ट: उद्धृत स्रोत और लिंक

सभी स्रोत लिंक नीचे एकत्र किए गए हैं। सलाह, पैच और विक्रेता मार्गदर्शन अक्टूबर 22, 2026 तक की जाँच को दर्शाते हैं; बाद की तैनाती को विक्रेता अद्यतन की जांच करनी चाहिए। पाठ में क्रमांकित उद्धरण इन प्रविष्टियों को संदर्भित करते हैं।

S1 - PHP आधिकारिक सुरक्षा बुलेटिन और मरम्मत संस्करण

  • स्रोत: प्रोजेक्ट PHP, 21 अक्टूबर, 2026।
  • उद्देश्य: जोखिम का दायरा, चार आधिकारिक मरम्मत संस्करण, आधिकारिक अस्थायी उपाय और पुरानी शाखाओं के लिए आपातकालीन बैकपोर्ट निर्देश।
  • संदर्भ: PHP 2026 This security bulletin वार्षिक बुलेटिन संग्रह में है

S2 - CVE-2026-109618 आधिकारिक तकनीकी बुलेटिन

  • स्रोत: php/php-src GitHub Security Advisory, 21 अक्टूबर, 2026।
  • पहचान: GHSA-w8hw-w9fx-j79w.
  • उद्देश्य: OOM के लिए कवरेज सीमा, बहुखण्डीय प्रवर्धन, SAPI अंतर और शमन।
  • संदर्भ: RCE via OOM corruption

S3 - CVE-2026-109619 आधिकारिक तकनीकी बुलेटिन

  • स्रोत: php/php-src GitHub Security Advisory, 21 अक्टूबर, 2026।
  • पहचान: GHSA-6wmf-4rv5-p3rp.
  • उद्देश्य: क्रॉस-अनुरोध लटकती स्थिति, उत्पादक और उपभोक्ता, प्रारंभिक आरंभीकरण, कॉन्फ़िगरेशन शमन।
  • संदर्भ: RCE via stale global state

S4 - PHP 8.5 आधिकारिक फिक्स सबमिशन

  • स्रोत: php/php-src.
  • सबमिट करें: 31c0ea7d7ff1d1fccb6492e52dab544011628065.
  • उद्देश्य: एक ही समय में दो कमजोरियों को ठीक करने के लिए औपचारिक प्रस्तुतिकरण की पुष्टि करना, और समग्र परिवर्तन दिशा की व्याख्या करना।
  • संदर्भ: Avoid state corruption via bailout

S5 - PHP 8.5 आधिकारिक तौर पर बहाल और पूर्ण अंतर

  • स्रोत: उसी आधिकारिक प्रस्तुतिकरण से भिन्न।
  • उद्देश्य: आवंटनकर्ता, VM, HTTP globals, सत्र, क्रमांकन और अनुरोध जीवन चक्र के विशिष्ट कार्यान्वयन की जाँच करें।
  • संदर्भ: official complete diff

S6 - PHP 8.1 आधिकारिक आपातकालीन बैकपोर्ट सबमिशन

  • स्रोत: php/php-src.
  • सबमिट करें: 1d7dec178a094e6e75b229ce22754045f8c6070a.
  • उद्देश्य: पुरानी शाखाओं के त्वरित निकास की जाँच करना और प्रगति व्यवहार परिवर्तन अपलोड करना।
  • संदर्भ: PHP 8.1 Emergency backport submission
  • संदर्भ: corresponds to complete diff

S7 - PHP 7.4 आधिकारिक आपातकालीन बैकपोर्ट शाखा

  • स्रोत: php/php-src, PHP स्रोत कोड शाखाएँ आधिकारिक सुरक्षा बुलेटिन में सूचीबद्ध हैं।
  • संदर्भ: PHP-7.4-CVE-2026-109618-109619

S8 - PHP 8.0 आधिकारिक आपातकालीन बैकपोर्ट शाखा

  • स्रोत: php/php-src, PHP स्रोत कोड शाखाएँ आधिकारिक सुरक्षा बुलेटिन में सूचीबद्ध हैं।
  • संदर्भ: PHP-8.0-CVE-2026-109618-109619

S9 - PHP 8.1 आधिकारिक आपातकालीन बैकपोर्ट शाखा

  • स्रोत: php/php-src, PHP स्रोत कोड शाखाएँ आधिकारिक सुरक्षा बुलेटिन में सूचीबद्ध हैं।
  • संदर्भ: PHP-8.1-CVE-2026-109618-109619

S10 — Ubuntu सुरक्षा बुलेटिन USN-8948-1

  • स्रोत: Canonical / Ubuntu, 21 अक्टूबर, 2026।
  • उद्देश्य: बैकपोर्ट और पूर्ण पैकेज संस्करण उदाहरण जारी करें।
  • संदर्भ: USN-8948-1: PHP vulnerabilities

S11 - PHP-FPM Configuration मैनुअल

  • स्रोत: PHP आधिकारिक दस्तावेज़।
  • उद्देश्य: कॉन्फ़िगरेशन शब्दार्थ जैसे php_admin_value, php_admin_flag, pm.max_requests, आदि।
  • संदर्भ: PHP-FPM Configuration

S12 - PHP कोर INI कॉन्फ़िगरेशन मैनुअल

  • स्रोत: PHP आधिकारिक दस्तावेज़।
  • उद्देश्य: अनुरोध निकाय की परिभाषा और दायरा, अपलोड, मेमोरी और स्वचालित POST रीड कॉन्फ़िगरेशन।
  • संदर्भ: Description of core php.ini directives

S13 - Nginx शरीर के आकार की सीमा का अनुरोध करता है

  • स्रोत: Nginx आधिकारिक दस्तावेज़।
  • उद्देश्य: client_max_body_size का अर्थ और उपलब्ध कॉन्फ़िगरेशन स्तर।
  • संदर्भ: ngx_http_core_module / client_max_body_size

S14 - Nginx FastCGI अनुरोध बफ़र

  • स्रोत: Nginx आधिकारिक दस्तावेज़।
  • उद्देश्य: fastcgi_request_buffering का प्रसंस्करण क्रम और कार्य।
  • संदर्भ: ngx_http_fastcgi_module / fastcgi_request_buffering

S15 - Nginx स्थिति और वापसी निर्देश

  • स्रोत: Nginx आधिकारिक दस्तावेज़।
  • उद्देश्य: if और return का कॉन्फ़िगरेशन सिंटैक्स।
  • संदर्भ: ngx_http_rewrite_module

S16 - Cloudflare PHP2Shell सुरक्षा निर्देश

  • स्रोत: Cloudflare आधिकारिक ब्लॉग।
  • उद्देश्य: इसके WAF परिनियोजन दायरे, Free योजना व्यवस्था और पहचान तंत्र का विवरण।
  • संदर्भ: Cloudflare deploys protections against php2shell vulnerability