அக்டோபர் 22, 2026 முதல் சரிபார்க்கப்பட்ட ஆதாரங்கள். பார்வையாளர்கள்: PHP பயன்பாட்டு ஆபரேட்டர்கள், பாதுகாப்பு பதிலளிப்பவர்கள் மற்றும் தனிப்பயன் PHP பில்ட்களை பராமரிக்கும் பொறியாளர்கள்.

இந்தக் கட்டுரை PHP2Shell பாதிப்புக்கான காரணம், தாக்கத்தின் நோக்கம், முறையான பழுதுபார்ப்பு செயல்முறை, தற்காலிகத் தணிப்பு நடவடிக்கைகள் மற்றும் அதிகாரப்பூர்வ இணைப்புச் செயலாக்கம் ஆகியவற்றைச் சுருக்கமாகக் கூறுகிறது. S1 போன்ற எண்களைப் பயன்படுத்தி முக்கிய உரை மேற்கோள் காட்டப்பட்டுள்ளது; அனைத்து மூல இணைப்புகளும் உரையின் முடிவில் உள்ள பின்னிணைப்பில் பட்டியலிடப்பட்டுள்ளன. உள்ளமைவு துண்டு என்பது ஒரு வரிசைப்படுத்தல் டெம்ப்ளேட் ஆகும், இது உண்மையான பதிப்பு, வணிகத் திறன் மற்றும் உள்ளமைவு பரம்பரை உறவின் அடிப்படையில் சரிசெய்யப்பட வேண்டும்.

TL;DR: பழுதுபார்க்கும் படிகள் மற்றும் பரிந்துரைகள்

  1. PHP இயக்க நேரத்தை மேம்படுத்தவும்: தொடர்புடைய கிளையை குறைந்தபட்சம் 8.2.35, 8.3.36, 8.4.27 அல்லது மேம்படுத்தவும் 8.5.12. விநியோக தொகுப்புகளுக்கு, இரண்டு CVE களையும் சரிசெய்வதை விற்பனையாளர் உறுதிப்படுத்தும் முழுமையான தொகுப்பு பதிப்பைப் பயன்படுத்தவும். S1S10
  2. அனைத்து பழைய செயல்முறைகளையும் மாற்றவும்: ஒவ்வொரு PHP worker, ஹோஸ்டிங் சேவை மற்றும் கொள்கலனை மேம்படுத்திய பின் மறுதொடக்கம் செய்யவும் அல்லது உருட்டவும், மேலும் பழைய நிகழ்வுகள் வெளியேறிவிட்டன என்பதை உறுதிப்படுத்தவும்.
  3. உண்மையான Web கோரிக்கை பாதை மூலம் சரிபார்க்கவும்: Web SAPI, முழு தொகுப்பு பதிப்பு மற்றும் இயங்கும் நிகழ்வைச் சரிபார்க்கவும். php -v ஐ மட்டும் சரிபார்ப்பதால், நேரடி சேவை நிலையானது என்பதை உறுதிப்படுத்தாது.
  4. வணிக பின்னடைவு சோதனைகளை இயக்கவும் மற்றும் இயல்பான ஆதார வரவு செலவுத் திட்டங்களை மீட்டமைக்கவும்: சோதனை உள்நுழைவு, அமர்வு கையாளுதல், பதிவேற்றங்கள், இறக்குமதிகள் மற்றும் பிழை கையாளுதல். PHP நினைவக வரம்பு தற்காலிகமாக அகற்றப்பட்டால், பேட்ச் செய்த பிறகு பொருத்தமான வரையறுக்கப்பட்ட பட்ஜெட்டை மீட்டெடுக்கவும்.
  5. I உடனடி மேம்படுத்தல் சாத்தியமற்றதாக இருந்தால்: 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 அதிகாரப்பூர்வமாக கருதுகிறது அனைத்து 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 ஐ வரம்பற்றதாக மாற்றுவது இந்த பாதிப்புகளை மறைக்காது.

”தொடக்கத்திற்கு முன்” தனித்தனியாக கருதப்பட வேண்டும்

உறுதிப்படுத்தப்பட்ட இரண்டு வகையான நுகர்வோரின் நேரம் வேறுபட்டது:

  • Early 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 இன் அதிகாரப்பூர்வ அறிவிப்பின் அடிப்படையிலானது, மேலும் நேர அடிப்படை அக்டோபர் 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

கொள்கலன் அல்லது 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

வணிகத்திற்கு மல்டிபார்ட் தேவைப்படாதபோது மட்டுமே, தொடர்புடைய சேவை நுழைவாயிலில் நீங்கள் நிராகரிப்பு விதியைச் சேர்க்கலாம்:

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=OffPOST/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]);

இந்த பகுதிகள் இரண்டு கொள்கைகளை விளக்குகின்றன: சாத்தியமான நுகர்வோர் முன் துவக்கவும், மேலும் மாநிலத்தை மீண்டும் உருவாக்கக்கூடிய கடைசி செயல்பாட்டிற்குப் பிறகு இறுதி சுத்தம் செய்யவும். சாதாரண நேரத்தில் மட்டும் சுட்டியை மீட்டமைத்தல் 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