2026 ഒക്ടോബർ 22 വരെ പരിശോധിച്ച ഉറവിടങ്ങൾ. പ്രേക്ഷകർ: 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. I പെട്ടെന്നുള്ള അപ്‌ഗ്രേഡ് അസാധ്യമാണെങ്കിൽ: PHP-ൽ എത്തുന്നതിന് മുമ്പ് വിശ്വസനീയമല്ലാത്ത ട്രാഫിക് നിയന്ത്രിക്കുക. സെക്ഷൻ 5-ൽ വിവരിച്ചിരിക്കുന്നതുപോലെ അപ്‌ലോഡ് പുരോഗതിയും PHP 8.5 മാരകമായ ബാക്ക്‌ട്രെയിസുകളും അപ്രാപ്‌തമാക്കുന്നത് വിലയിരുത്തുക. കോൺഫിഗറേഷൻ ലഘൂകരണങ്ങൾക്കും WAF നിയമങ്ങൾക്കും പരിമിതമായ കവറേജ് ഉണ്ട്, ഒരു നവീകരണത്തിന് പകരം വയ്ക്കാൻ കഴിയില്ല. S1S2S3

1. വൾനറബിലിറ്റി അവലോകനവും റിസ്ക് വിധിയും

ഈ ലേഖനത്തിലെ PHP2Shell, 2026 ഒക്ടോബർ 21-ന് PHP ഔദ്യോഗികമായി വെളിപ്പെടുത്തിയ രണ്ട് 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 അൺലിമിറ്റഡിലേക്ക് മാറ്റുന്നത് ഈ കേടുപാടുകൾ ഉൾക്കൊള്ളുന്നില്ല.

”പ്രാരംഭത്തിന് മുമ്പ്” പ്രത്യേകം പരിഗണിക്കേണ്ടതുണ്ട്

സ്ഥിരീകരിച്ച രണ്ട് തരം ഉപഭോക്താക്കളുടെ സമയം വ്യത്യസ്തമാണ്:

  • Arely INI ഡയഗ്നോസ്റ്റിക്സ്: സാധാരണ എക്സിക്യൂട്ടർ ഇനീഷ്യലൈസേഷന് മുമ്പുള്ള അഭ്യർത്ഥന പ്രശ്ന മുന്നറിയിപ്പ്, അറിയിപ്പ് അല്ലെങ്കിൽ ഒഴിവാക്കൽ എന്നിവയിൽ ചില കോൺഫിഗറേഷനുകൾ പ്രയോഗിച്ചു, കൂടാതെ ഡയഗ്നോസ്റ്റിക് പ്രോസസ്സിംഗ് പഴയ പിശക് നിലയിലേക്ക് ആക്സസ് ചെയ്തേക്കാം.
  • സെഷൻ അപ്‌ലോഡ് പുരോഗതി: അഭ്യർത്ഥന ബോഡി പാഴ്‌സിംഗ് പ്രക്രിയയിൽ സെഷൻ മുൻകൂട്ടി പ്രോസസ്സ് ചെയ്തേക്കാം, എന്നാൽ പതിവ് മൊഡ്യൂൾ 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-ൻ്റെ ഔദ്യോഗിക പ്രഖ്യാപനത്തെ അടിസ്ഥാനമാക്കിയുള്ളതാണ്, സമയ അടിസ്ഥാനം 2026 ഒക്ടോബർ 22 ആണ്. 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 കോൺഫിഗറേഷൻ ടെംപ്ലേറ്റ്

php.ini-ൽ പദാനുപദമല്ല, അഭ്യർത്ഥനകൾ നൽകുന്നFPM pool കോൺഫിഗറേഷൻ വിഭാഗത്തിൽ ഇനിപ്പറയുന്ന ക്രമീകരണങ്ങൾ സ്ഥാപിക്കുക. 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

ini_set() വഴിയുള്ള ആപ്ലിക്കേഷനുകൾക്ക് മാനേജ്‌മെൻ്റ്-ലെവൽ php_admin_* ക്രമീകരണങ്ങൾ അസാധുവാക്കാൻ കഴിയില്ല. യഥാർത്ഥ അഭ്യർത്ഥനകളിലെ മൂല്യങ്ങൾ പ്രതീക്ഷിച്ചതുപോലെയാണെന്ന് സ്ഥിരീകരിക്കുന്നതിന് എല്ലാ പൂൾ, ഡയറക്‌ടറി ലെവൽ, ഫ്രണ്ട്-എൻഡ് ഇൻകമിംഗ് കോൺഫിഗറേഷനുകളും ഇപ്പോഴും അവലോകനം ചെയ്യണം. പരിഷ്ക്കരണത്തിന് ശേഷം, നിലവിലുള്ള പ്രക്രിയകൾ പഴയ അവസ്ഥയിൽ തുടരുന്നത് തടയാൻ എല്ലാ തൊഴിലാളികളെയും പുനർനിർമ്മിക്കുക.

നിങ്ങൾ 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

കണ്ടെയ്നർ അല്ലെങ്കിൽ 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 കവറേജ് പരിധികൾ

Free പ്ലാൻ ഉൾപ്പെടെ PHP2Shell-നെതിരെയുള്ള സംരക്ഷണത്തിനായി Cloudflare വിന്യാസ ക്രമീകരണങ്ങൾ പ്രഖ്യാപിച്ചു. അതിൻ്റെ സേവനങ്ങൾ ഉപയോഗിക്കുമ്പോൾ, യഥാർത്ഥ ട്രാഫിക് പ്രോക്സിയിലൂടെ കടന്നുപോകുന്നുണ്ടോ, പരിരക്ഷണ നിയമങ്ങൾ പ്രാബല്യത്തിൽ ഉണ്ടോ, ഉത്ഭവ സൈറ്റ് നേരിട്ട് ബൈപാസ് ചെയ്യാൻ കഴിയുമോ എന്ന് നിങ്ങൾ പരിശോധിക്കണം; പണമടച്ചുള്ള പ്ലാനുകൾക്കായി, നിങ്ങൾ ബന്ധപ്പെട്ട നിയന്ത്രിത നിയമങ്ങളുടെ കോൺഫിഗറേഷനും ഒഴിവാക്കലുകളും പരിശോധിക്കേണ്ടതുണ്ട്. 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 എക്‌സിറ്റ് മെക്കാനിസം ക്രമീകരിക്കുന്നതിനും സമാരംഭ ഘട്ടത്തിൽ ആക്‌സസ് ചെയ്യാവുന്ന ആഗോള നില പരിഹരിക്കുന്നതിനും ഈ പ്രതിബദ്ധത രണ്ട് CVE-കളെ വ്യക്തമായി ബന്ധപ്പെടുത്തുന്നു. പൂർണ്ണ വ്യത്യാസത്തോടെ പേജ് സമർപ്പിക്കുക 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

ഒരു ഡിസൈൻ വീക്ഷണകോണിൽ, പ്രധാനപ്പെട്ട മാറ്റങ്ങൾ ഇവയാണ്: 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

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 സംഭവിക്കുന്നത് അത് ചൂഷണം ചെയ്യപ്പെട്ടുവെന്ന് അർത്ഥമാക്കുന്നില്ല, കൂടാതെ അലാറങ്ങളുടെ അഭാവം ചൂഷണം നടന്നിട്ടില്ലെന്ന് തെളിയിക്കുന്നില്ല. നവീകരണം ഭാവിയിൽ എത്തിച്ചേരാവുന്ന അപകടസാധ്യതയുള്ള പാതകൾ പരിഹരിക്കുന്നു; ഫയലിൽ കൃത്രിമം കാണിക്കുകയോ ക്രെഡൻഷ്യൽ ചോർച്ചയോ പോലുള്ള അപാകതകൾ കണ്ടെത്തിയാൽ, സംഭവത്തിൽ പ്രത്യേക അന്വേഷണം നടത്തണം.

അനുബന്ധം: ഉദ്ധരിച്ച ഉറവിടങ്ങളും ലിങ്കുകളും

എല്ലാ ഉറവിട ലിങ്കുകളും ചുവടെ ശേഖരിക്കുന്നു. ഉപദേശങ്ങൾ, പാച്ചുകൾ, വെണ്ടർ മാർഗ്ഗനിർദ്ദേശങ്ങൾ എന്നിവ 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