स्रोतहरू अक्टोबर 22, 2026 को रूपमा जाँच गरियो। Audience: PHP एप्लिकेसन अपरेटरहरू, सुरक्षा प्रतिक्रियाकर्ताहरू, र अनुकूलन PHP निर्माणहरू कायम गर्ने इन्जिनियरहरू।

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

TL; DR: मर्मतका चरणहरू र सुझावहरू

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

1. जोखिम अवलोकन र जोखिम निर्णय

यस लेखमा PHP2Shell ले PHP द्वारा अक्टोबर 21, 2026 मा आधिकारिक रूपमा खुलासा गरिएको दुई Critical स्तरको कमजोरीहरूलाई जनाउँछ। दुबै मेमोरीसँग सम्बन्धित छन् र PHP इन्जिनको लाइफसायकल व्यवस्थापनसँग सम्बन्धित छन्, जसले कोडको पुन: काट्ने जोखिम निम्त्याउँछ। S1S2S3

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

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

1.1 प्रभावित परिनियोजनहरू बुझ्दै

PHP आधिकारिक रूपमा मानिन्छ सबै 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 प्राय: क्रमशः धेरै अनुरोधहरू ह्यान्डल गर्दछ। अनुरोधको समयमा आवंटित मेमोरी अनुरोधको अन्त्यमा समान रूपमा जारी गर्न सकिन्छ, जबकि कार्यकर्ता आफैं र यसका केही विश्वव्यापी क्षेत्रहरू अवस्थित छन्।

त्यसकारण, इन्जिनले दुई बाधाहरू राख्नुपर्छ:

  • प्रारम्भिक बाधा : अन्य कोडहरूमा देखिने डाटा सुरक्षित रूपमा पढ्न, पार गर्न र नष्ट गर्न सकिने अवस्थामा हुनुपर्छ।
  • Lifecycle constraint: एक पटक अनुरोध मेमोरी खाली गरिसकेपछि, लामो समयसम्म बाँच्ने क्षेत्रहरूले त्यो मेमोरी भित्र ठेगानाहरूलाई वैध अवस्थाको रूपमा व्यवहार गर्न जारी राख्नु हुँदैन।

यी दुई बाधाहरू कमजोरीहरूको दुई समूहहरूको मुख्य विफलता मोडहरूसँग मेल खान्छ। निम्न प्रक्रिया घोषणाहरू र प्याच संकलन संयोजन गर्ने संयन्त्र विवरण हो। यसको मतलब यो होइन कि हरेक डिप्लोइमेन्टमा ठ्याक्कै एउटै पहुँचयोग्य बाटो छ। 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 लाई असीमितमा परिवर्तन गर्दा कमजोरीहरूको यो सेट समेट्दैन।

“सुरुवात गर्नु अघि” अलग उपचार गर्न आवश्यक छ

दुई प्रकारका पुष्टि भएका उपभोक्ताहरूको समय फरक छ:

  • Early INI diagnostics: केही कन्फिगरेसनहरू अनुरोध मुद्दा चेतावनी, सूचना वा ह्रास सामान्य कार्यकारी प्रारम्भिकरण अघि लागू गरियो, र निदान प्रक्रियाले पुरानो त्रुटि अवस्था पहुँच गर्न सक्छ।
  • सत्र अपलोड प्रगति: अनुरोधको मुख्य भाग पार्सिङ प्रक्रियाको क्रममा सत्र अग्रिम प्रक्रिया हुन सक्छ, तर नियमित मोड्युल RINIT अझै पूरा भएको छैन; यो अनुमान गर्न सकिँदैन कि मार्ग अवस्थित छैन किनभने अनुप्रयोगले स्पष्ट रूपमा session_start() लाई कल गर्दैन। S3

सबै होइन INI कन्फिगरेसनहरूमा समान जोखिम समय हुन्छ। को निर्देशिका-स्तर कन्फिगरेसन mod_php र PHP_VALUE / PHP_ADMIN_VALUE द्वारा पारित गरियो FPM अगाडि-अन्तलाई सामान्यबाट छुट्याउन आवश्यक छ 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

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

5.3 PHP मेमोरी सीमा हटाउनको लागत व्यवस्थापन गर्नुहोस्

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

कन्टेनर वा cgroup मेमोरी सीमाहरूले उपलब्धता सीमाहरू प्रदान गर्न सक्छ तर ग्यारेन्टी गर्दैन कि विनियोजन कहिल्यै असफल हुनेछैन; सम्पूर्ण कन्टेनर, मास्टर, र सबै कार्यकर्ता पनि समाप्त हुन सक्छ जब सीमा ट्रिगर हुन्छ। अलगाव ग्रेन्युलेरिटी र समाप्ति रणनीतिहरू परिनियोजनको संयोजनमा मूल्याङ्कन गर्न आवश्यक छ र यी दुई 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 लाई पहिले अनुरोधको पूर्ण भाग पढ्न र त्यसपछि FastCGI ब्याकइन्डमा पठाउन दिन्छ। यो कुनै निश्चित server वा location मा प्रभाव पर्छ कि छैन अवस्थित विरासत र कभरेज सम्बन्धहरूसँग संयोजनमा जाँच गर्न आवश्यक छ। S13S14

जब व्यवसायलाई multipart आवश्यक पर्दैन, तपाईले सम्बन्धित सेवा प्रवेशमा अस्वीकार गर्ने नियम थप्न सक्नुहुन्छ:

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

प्रतिबद्धताले स्पष्ट रूपमा दुई CVE हरू सम्बद्ध गर्दछ, दुबै OOM निकास संयन्त्र समायोजन गर्न र प्रारम्भिक चरणको समयमा पहुँच गर्न सकिने विश्वव्यापी अवस्थालाई ठीक गर्न। पूर्ण भिन्नता सहित पृष्ठ पेश गर्नुहोस् S4S5 हेर्नुहोस्। अन्य शाखाहरूले तिनीहरूको आफ्नै आधिकारिक सुरक्षा रिलीज वा मिल्दो प्याचहरू प्रयोग गर्नुपर्छ, र यो मान्न सकिँदैन कि 8.5 मा परिवर्तनहरू सीधा कुनै पनि पुरानो संस्करणमा लागू गर्न सकिन्छ।

6.2 OOM मर्मत: पहिले प्रशोधन योग्य अवस्था पुनर्स्थापना गर्नुहोस्, र त्यसपछि अनुरोध समाप्त गर्नुहोस्

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

पेन्डिङ OOM चिन्ह लगाउन प्रयोग गरिएको 8.5 भिन्नतामा रहेको कुञ्जी कोडको अंश निम्न छ:

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

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

न त यसलाई “PHP ले सबै zend_bailout() मेटाएको छ” भनेर संक्षेप गर्न सकिँदैन। प्याचले अझै पनि विशेष सन्दर्भहरूमा सान्दर्भिक संयन्त्रहरू प्रयोग गर्दछ; के निश्चित छ खतरनाक निकास समय र साथ राज्य व्यवस्थापन। S5

6.3 आवंटन कलरहरू र मल्टिपार्ट पार्सिङ सँगै अद्यावधिक गर्नुहोस्

यदि तपाईंले “असफलतामा NULL फिर्ता गर्नुहोस्” मा मात्र एक आवंटन प्रकार्य परिवर्तन गर्नुभयो र मूल कलरले अझै पनि मान्य पोइन्टर सधैं फर्काइन्छ भनी मान्दछ, तपाईंले नयाँ नल पोइन्टर पहुँच वा अपूर्ण सफाई परिचय गराउनुहुनेछ। प्याचमा असफल आवंटन इन्टरफेसलाई कलर जाँच र अपवाद प्रचारको साथ समीक्षा गर्न आवश्यक छ। 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]);

यी अंशहरूले दुई सिद्धान्तहरू चित्रण गर्दछ: initialize सकेसम्म चाँडो उपभोक्ताको अगाडि, र अन्तिम अपरेशन पछि अन्तिम सफाई गर्नुहोस् जसले राज्यलाई पुन: सिर्जना गर्न सक्छ। सामान्य RINIT को समयमा मात्र एक सूचक रिसेट गर्दा वा पहिलेको बन्द चरण पहिले वा पछिको पहुँच छुटाउन सक्छ। S5

6.5 किन तपाईंको आफ्नै “एक-लाइन मर्मत” बनाउन सिफारिस गरिएको छैन?

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

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

७. 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 को घटनाको मतलब यो शोषण गरिएको छैन, र अलार्मको कमीले कुनै शोषण भएको छैन भनेर प्रमाणित गर्दैन। अपग्रेडले भविष्यमा पुग्न सकिने भेद्यता मार्गहरू फिक्स गर्दछ; यदि फाइल छेडछाड वा प्रमाणपत्र चुहावट जस्ता विसंगतिहरू फेला परेमा, घटनाको छुट्टै अनुसन्धान गरिनु पर्छ।

परिशिष्ट: उद्धृत स्रोत र लिङ्कहरू

सबै स्रोत लिङ्कहरू तल सङ्कलन गरिएका छन्। October 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