উত্সগুলি 22 অক্টোবর, 2026 তারিখে চেক করা হয়েছে৷ অডিয়েন্স: PHP অ্যাপ্লিকেশন অপারেটর, নিরাপত্তা উত্তরদাতা, এবং প্রকৌশলীরা কাস্টম PHP বিল্ডস বজায় রাখে।

এই নিবন্ধটি PHP2Shell দুর্বলতার কারণ, প্রভাবের সুযোগ, আনুষ্ঠানিক মেরামত প্রক্রিয়া, অস্থায়ী প্রশমনের ব্যবস্থা এবং অফিসিয়াল প্যাচ বাস্তবায়নের সংক্ষিপ্ত বিবরণ দেয়। S1 এর মতো সংখ্যা ব্যবহার করে মূল পাঠ্যটি উদ্ধৃত করা হয়েছে; সমস্ত উত্স লিঙ্কগুলি পাঠ্যের শেষে পরিশিষ্টে তালিকাভুক্ত করা হয়েছে। কনফিগারেশন খণ্ডটি একটি স্থাপনার টেমপ্লেট, যা প্রকৃত সংস্করণ, ব্যবসার ক্ষমতা এবং কনফিগারেশন উত্তরাধিকার সম্পর্কের উপর ভিত্তি করে সামঞ্জস্য করা প্রয়োজন।

TL;DR: মেরামতের পদক্ষেপ এবং পরামর্শ

  1. আপগ্রেড করুন PHP রানটাইম : অন্তত প্রাসঙ্গিক শাখা আপগ্রেড করুন 8.2.35 , 8.3.36 , 8.4.27 বা 8.5.12 . ডিস্ট্রিবিউশন প্যাকেজগুলির জন্য, সম্পূর্ণ প্যাকেজ সংস্করণটি ব্যবহার করুন যা বিক্রেতা উভয় CVE-এর সমাধান নিশ্চিত করে। S1 S10
  2. সমস্ত পুরানো প্রক্রিয়া প্রতিস্থাপন করুন: আপগ্রেড করার পরে প্রতিটি PHP worker, হোস্টিং পরিষেবা এবং কন্টেইনার পুনরায় চালু করুন বা রোল করুন এবং নিশ্চিত করুন যে পুরানো উদাহরণগুলি প্রস্থান হয়েছে৷
  3. প্রকৃত Web অনুরোধ path মাধ্যমে যাচাই করুন: Web SAPI, সম্পূর্ণ প্যাকেজ সংস্করণ এবং চলমান উদাহরণ পরীক্ষা করুন। শুধুমাত্র php -v চেক করলেই লাইভ পরিষেবা স্থির করা হয় না।
  4. Run ব্যবসা রিগ্রেশন চেক করে এবং স্বাভাবিক রিসোর্স বাজেট পুনরুদ্ধার করে: পরীক্ষা লগইন, সেশন হ্যান্ডলিং, আপলোড, আমদানি, এবং ত্রুটি পরিচালনা। যদি PHP মেমরি সীমা সাময়িকভাবে সরানো হয়, প্যাচ করার পরে একটি উপযুক্ত সীমাবদ্ধ বাজেট পুনরুদ্ধার করুন।
  5. যদি অবিলম্বে আপগ্রেড করা অসম্ভব: এটি PHP পৌঁছানোর আগে অবিশ্বস্ত ট্র্যাফিক সীমাবদ্ধ করুন৷ অনুচ্ছেদ 5 এ বর্ণিত আপলোড অগ্রগতি এবং PHP 8.5 মারাত্মক ব্যাকট্রেস নিষ্ক্রিয় করার মূল্যায়ন করুন। কনফিগারেশন প্রশমন এবং WAF নিয়মগুলির সীমিত কভারেজ রয়েছে এবং একটি আপগ্রেড প্রতিস্থাপন করতে পারে না। S1S2S3

1. দুর্বলতা ওভারভিউ এবং ঝুঁকি বিচার

এই নিবন্ধে PHP2Shell দুটি Critical স্তরের দুর্বলতাগুলিকে বোঝায় যা আনুষ্ঠানিকভাবে PHP দ্বারা 21 অক্টোবর, 2026-এ প্রকাশ করা হয়েছে। উভয়ই 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 diagnostics: কিছু কনফিগারেশন অনুরোধ ইস্যু সতর্কতা, নোটিশ বা অবনমনের স্বাভাবিক নির্বাহক আরম্ভ করার আগে প্রয়োগ করা হয় এবং ডায়াগনস্টিক প্রসেসিং পুরানো ত্রুটির অবস্থা অ্যাক্সেস করতে পারে।
  • অধিবেশন আপলোডের অগ্রগতি: অনুরোধের বডি পার্সিং প্রক্রিয়া চলাকালীন সেশন অগ্রিম প্রক্রিয়া করা হতে পারে, তবে নিয়মিত মডিউল RINIT এখনও সম্পূর্ণ হয়নি; এটি অনুমান করা যায় না যে পথটি বিদ্যমান নেই কারণ অ্যাপ্লিকেশনটি স্পষ্টভাবে session_start() কল করে না। S3

সব নয় INI কনফিগারেশন একই ঝুঁকি সময় আছে. এর ডিরেক্টরি-স্তরের কনফিগারেশন mod_php এবং PHP_VALUE / PHP_ADMIN_VALUE দ্বারা পাস FPM সামনের প্রান্তকে সাধারণ থেকে আলাদা করা দরকার php.ini , FPM pool স্টার্টআপ কনফিগারেশন এবং FPM .user.ini . পরেরটির কনফিগারেশনের সময় আলাদা এবং সমষ্টিগতভাবে একই প্রারম্ভিক ভোক্তা বলা যায় না। S3

display_errors, log_errors বন্ধ করা, error_reporting হ্রাস করা বা @ ব্যবহার করা শুধুমাত্র রোগ নির্ণয়ের দৃশ্যমানতাকে প্রভাবিত করে; লগ আউটপুট করার সিদ্ধান্ত নেওয়ার আগে প্রাসঙ্গিক অভ্যন্তরীণ অবস্থা অ্যাক্সেস করা যেতে পারে। S3

3. সংস্করণ এবং প্যাচ নির্বাচন মেরামত

3.1 অফিসিয়াল আপস্ট্রিম ফিক্স বেসলাইন

বর্তমান PHP শাখাএই অফিসিয়াল ফিক্স অন্তর্ভুক্ত করার প্রথম সংস্করণপরামর্শ
8.28.2.35এই সংস্করণে আপগ্রেড করুন বা একই সংশোধন সমন্বিত একটি পরবর্তী সংস্করণ
8.38.3.36উপরের হিসাবে একই
8.48.4.27উপরের হিসাবে একই
8.58.5.12উপরের হিসাবে একই
8.1 এবং পূর্ববর্তী সংস্করণআপস্ট্রিম সাধারণ সমর্থন শেষ হয়েছেসমর্থিত শাখায় স্থানান্তরকে অগ্রাধিকার দিন; স্বল্পমেয়াদী চেক রিলিজ বা LTS প্রস্তুতকারকের ব্যাকপোর্ট

সংস্করণ এবং সমর্থন অবস্থা PHP-এর অফিসিয়াল ঘোষণার উপর ভিত্তি করে এবং সময় বেসলাইন হল 22 অক্টোবর, 2026। S1

এগুলি হল শাখা-নির্দিষ্ট ফিক্স থ্রেশহোল্ড৷ 8.5.12-এর নীচের প্রতিটি সংস্করণ দুর্বল: অন্য শাখায় 8.2.35 এবং 8.4.27-এর মতো সংস্করণগুলিতে ইতিমধ্যেই সংশোধন রয়েছে৷

3.2 সম্পূর্ণ বিতরণ প্যাকেজ সংস্করণ পরীক্ষা করুন

ডিস্ট্রো প্রায়শই পুরানো আপস্ট্রিম সংস্করণের উপর ভিত্তি করে সুরক্ষা সংশোধন করে। গ্রহণযোগ্যতা রিলিজ সংস্করণ, সংগ্রহস্থল উৎস, সম্পূর্ণ প্যাকেজ সংস্করণ এবং নিরাপত্তা বুলেটিন পরীক্ষা করা উচিত।

উদাহরণস্বরূপ, Ubuntu USN-8948-1-এর জন্য তালিকাভুক্ত Ubuntu 24.04 LTS ফিক্স প্যাকেজ সংস্করণ হল:

8.3.6-0ubuntu0.24.04.13

এর আপস্ট্রিম অংশটি এখনও 8.3.6, তবে সেই বিতরণের সম্পূর্ণ প্যাকেজ সংস্করণটি এই ফিক্স ঘোষণায় অন্তর্ভুক্ত করা হয়েছে। এই উপসংহারটি শুধুমাত্র সংশ্লিষ্ট ডিস্ট্রিবিউশন এবং প্যাকেজ উৎসের ক্ষেত্রে প্রযোজ্য, এবং 8.3.6 প্রদর্শন করে এমন কোনো বিল্ডে সাধারণীকরণ করা যাবে না। S10

3.3 সঠিক প্যাচ নির্বাচন করা হচ্ছে

দৃশ্যঅগ্রাধিকার পরিকল্পনাগ্রহণের জন্য মূল পয়েন্ট
বিতরণ PHP প্যাকেজ ব্যবহার করেপ্রস্তুতকারকের দ্বারা প্রকাশিত নিরাপত্তা আপডেট ইনস্টল করুনঘোষণা CVE উভয়ই কভার করে; সম্পূর্ণ প্যাকেজ সংস্করণ সঠিক
অফিসিয়াল PHP ধারক বা স্ব-নির্মিত ছবি ব্যবহার করুনবেস রানটাইম আপডেট করুন, পুনর্নির্মাণ করুন এবং স্থাপন করুনচলমান উদাহরণ নতুন চিত্র ব্যবহার করে; সমস্ত পুরানো কপি প্রস্থান করা হয়
স্ব-সংকলিত সমর্থিত শাখাএই শাখার অফিসিয়াল নিরাপত্তা সংস্করণ বা সম্পূর্ণ অফিসিয়াল প্যাচ সেট ব্যবহার করুনশাখা মিল, নির্ভরতা সমাপ্তি, এক্সটেনশন সামঞ্জস্য এবং রিগ্রেশন পাসিং
7.4, 8.0, 8.1 সাপেক্ষেবিক্রেতা ব্যাকপোর্ট অগ্রাধিকার; প্রয়োজনে অফিসিয়াল ইমার্জেন্সি সোর্স কোড শাখার মূল্যায়ন করুনআচরণগত পরিবর্তনগুলি সনাক্ত করুন এবং সমর্থিত সংস্করণগুলিতে স্থানান্তরের সময়সূচী করুন৷

অফিসিয়াল প্যাচ প্রকাশ করা হয়েছে, এবং প্রকৃত সংশোধন এই প্যাচ থেকে শুরু করা উচিত। বিভাগ 6-এর কোড স্নিপেটগুলি ডিজাইন এবং পর্যালোচনা হাইলাইটগুলিকে চিত্রিত করার উদ্দেশ্যে এবং একটি সম্পূর্ণ প্যাচ গঠন করে না যা স্বাধীনভাবে প্রয়োগ করা যেতে পারে। S1S4S6

4. আনুষ্ঠানিক মেরামতের প্রক্রিয়া

4.1 রানটাইমের ইনভেন্টরি যা আসলে অনুরোধগুলি পরিচালনা করে

কমপক্ষে রেকর্ড করার জন্য একটি সংক্ষিপ্ত লেজার গঠন করার সুপারিশ করা হয়:

  • এন্ট্রি ডোমেন নাম বা পরিষেবা, বিপরীত প্রক্সি ব্যাকএন্ড, PHP SAPI।
  • PHP শাখা, সম্পূর্ণ প্যাকেজ সংস্করণ বা ইমেজ ডাইজেস্ট, বিল্ড সোর্স।
  • FPM pool, প্রকৃত পরিষেবা ইউনিট, ধারক বা Pod, প্রতিলিপির সংখ্যা।
  • এক্সটেনশন, প্রধান কনফিগারেশন এবং অতিরিক্ত কনফিগারেশন ফাইল লোড করা হয়েছে।
  • অন্যান্য PHP সংস্করণ, পুরানো স্থাপনার অনুলিপি, বা মূল পোর্টালগুলি কি সরাসরি অ্যাক্সেস করা যেতে পারে?

এগুলি বাস্তবায়নের পরামর্শ যাতে “আপগ্রেড” প্রতিটি প্রকৃত ট্রাফিক এন্ট্রির সাথে সামঞ্জস্যপূর্ণ হতে পারে৷ বিশেষ করে পরীক্ষা করুন যে কমান্ড লাইন PHP এবং Web PHP বিভিন্ন সংস্করণ ব্যবহার করে, ছবিটি তৈরি করা হয়েছে কিন্তু পুরানো ধারকটি এখনও চলছে, পুলের অংশ বা অনুলিপি প্রতিস্থাপন করা হয়নি ইত্যাদি।

4.2 সঠিক আপডেট নির্বাচন করুন এবং স্থাপন করুন

অনুচ্ছেদ 3 অনুযায়ী ফিক্স সংস্করণ নিশ্চিত করুন, বিশেষত একটি বিদ্যমান বিশ্বস্ত প্যাকেজ উৎস বা নিয়ন্ত্রিত বিল্ড চেইন ব্যবহার করে। আপডেটের সুযোগে সেই উপাদানটি অন্তর্ভুক্ত করা উচিত যা আসলে অনুরোধটি হোস্ট করে, যেমন FPM প্যাকেজ, Apache PHP মডিউল, CGI বাইনারি, বা পরিষেবা বিল্ড যেখানে PHP এমবেড করা আছে৷

আপগ্রেড করার আগে, কনফিগারেশন এবং প্যাকেজ তালিকা রাখুন, এবং উত্পাদনের মতো পরিবেশে স্টার্টআপ এবং মূল পরিষেবাগুলি যাচাই করুন। স্ব-রক্ষণাবেক্ষণ করা এক্সটেনশনগুলির জন্য, PHP সংস্করণের সাথে সম্পর্কিত বিল্ড এবং রানের সামঞ্জস্যতা পরীক্ষা করুন। অন্য শাখা থেকে একটি আপাতদৃষ্টিতে প্রাসঙ্গিক প্রতিশ্রুতি বাছাই করা গ্যারান্টি দেয় না যে সম্পূর্ণ সেটগুলি কার্যকর করা হয়েছে৷

4.3 রিস্টার্ট করুন বা চলমান দৃষ্টান্তগুলি রোল ওভার করুন৷

একটি ফাইল ইনস্টল করা এবং একটি প্রক্রিয়াতে নতুন কোড লোড করা দুটি ভিন্ন জিনিস। সংশ্লিষ্ট পরিষেবাটি পুনরায় চালু করা উচিত, অথবা রোলিং প্রতিস্থাপন সম্পূর্ণ করা উচিত, এবং পুরানো কর্মী এবং পুরানো কন্টেইনারটি প্রস্থান হয়েছে তা নিশ্চিত করা উচিত।

mod_php এর জন্য, মডিউল হোস্ট করা Apache প্রক্রিয়াটি পুনরায় চালু করুন। যে পরিষেবাগুলি PHP এম্বেড করে তাদের হোস্টিং প্রক্রিয়া প্রতিস্থাপন করা প্রয়োজন৷ FPM এর জন্য, OPcache সাফ করা রানটাইম আপডেট করা এবং পুরানো কর্মীদের অবসর নেওয়ার প্রতিস্থাপন করে না।

গ্রেসফুল সুইচিং ব্যবহার করার সময়, আপনাকে পুরানো প্রজন্মের প্রক্রিয়াটি এখনও দীর্ঘ সংযোগ বা অসামান্য অনুরোধগুলি পরিচালনা করছে কিনা তা পরীক্ষা করতে হবে। গ্রহণযোগ্যতা রেকর্ডে প্রকৃত পরিষেবা, স্থাপনার সংস্করণ, সমাপ্তির সময় পরিবর্তন এবং পুরানো উদাহরণের প্রস্থান ফলাফল অন্তর্ভুক্ত করা উচিত।

4.4 বাস্তব Web অনুরোধের মাধ্যমে যাচাই করুন

শুধুমাত্র একটি একক সংস্করণ কমান্ডের উপর নির্ভর না করে নিম্নলিখিত প্রমাণের অংশগুলিকে একত্রিত করার সুপারিশ করা হয়:

প্রমাণকি প্রমাণ করা যায়একা কিছু প্রমাণ করা যায় না
প্যাকেজ ম্যানেজার বা ইমেজ মেটাডেটাইনস্টলেশন উত্স এবং সম্পূর্ণ বিল্ডএই দৃষ্টান্তে ট্রাফিক সুইচ করা হয়েছে
প্রক্রিয়া এবং স্থাপনার অবস্থাকর্মী বা ধারক প্রতিস্থাপন সম্পূর্ণ করেবাহ্যিক প্রবেশদ্বারটি অবশ্যই এটির দিকে যেতে হবে
বাস্তব পোর্টালের মাধ্যমে সীমাবদ্ধ ডায়গনিস্টিক ফলাফল অ্যাক্সেস করা হয়েছেপ্রকৃত Web SAPI এবং চলমান কনফিগারেশনরিলিজ ব্যাকপোর্ট দুটি CVE কভার করে কিনা
বিক্রেতার ঘোষণা বা সম্পূর্ণ প্যাচ রেকর্ডএই বাগ ফিক্স এই বিল্ড অন্তর্ভুক্ত করা হয়েছেসমস্ত প্রতিলিপি স্থাপন করা হয়

PHP_VERSION, PHP_SAPI, লোড করা কনফিগারেশন ফাইল এবং জরুরী কনফিগারেশনগুলি বিদ্যমান অভ্যন্তরীণ ডায়াগনস্টিক ক্ষমতা বা অস্থায়ী এবং অ্যাক্সেস-নিয়ন্ত্রিত ডায়াগনস্টিক পোর্টালগুলির মাধ্যমে চেক করা যেতে পারে। নিশ্চিত করুন যে অনুরোধটি সরাসরি CDN বা পৃষ্ঠার ক্যাশে দ্বারা ফেরত দেওয়া হয়নি; সম্পূর্ণ হলে অস্থায়ী ডায়গনিস্টিক এন্ট্রি সরান।

php -v সাধারণত শুধুমাত্র শেল দ্বারা নির্বাচিত CLI বাইনারি নির্দেশ করে; php-fpm -i-এর মতো কমান্ড ট্র্যাফিক গ্রহণকারী বিদ্যমান কর্মীকে যাচাই করার সমতুল্য নয়। দীর্ঘ সময়ের জন্য সম্পূর্ণ phpinfo() পৃষ্ঠাটি সর্বজনীন নেটওয়ার্কে প্রকাশ করবেন না।

4.5 বিজনেস রিগ্রেশন চেক এবং জরুরী সেটিংস অপসারণ

এই পরিবর্তন দ্বারা প্রভাবিত ফাংশনগুলির চারপাশে স্বাভাবিক লগইন, সেশন পড়া এবং লেখা, ফর্ম এবং আপলোড, আমদানি, ত্রুটি পরিচালনা এবং কর্মী স্থায়িত্ব যাচাই করুন। ত্রুটির হার, প্রতিক্রিয়া বিলম্ব, মেমরির শিখর, প্রক্রিয়া প্রস্থান এবং পুনর্নির্মাণের ফ্রিকোয়েন্সি অস্বাভাবিক কিনা তা পরীক্ষা করুন।

যদি memory_limit=-1 সাময়িকভাবে সেট করা হয়, অফিসিয়াল প্যাচ কার্যকর হওয়ার পরে ব্যবসার ক্ষমতার সাথে মেলে সীমিত বাজেট পুনরুদ্ধার করা হবে; pm.max_requests=1 সেট করা থাকলে, মেরামত নিশ্চিত হওয়ার পরে ক্ষমতা-মূল্যায়িত জীবন চক্র কনফিগারেশন পুনরুদ্ধার করা হবে। ইনপুট আকারের সীমা এবং উত্স অ্যাক্সেস নিয়ন্ত্রণগুলি ব্যবসার প্রয়োজন অনুসারে ধরে রাখা যেতে পারে।

আপগ্রেড করার সময় সামঞ্জস্যের সমস্যা দেখা দিলে, প্রভাবিত পোর্টালটিকে স্থগিত করা, এর বাহ্যিক অ্যাক্সেস সীমিত করা, বা রোল ব্যাক করার আগে অ্যাপ্লিকেশনটি সামঞ্জস্য করাকে অগ্রাধিকার দেওয়া উচিত। অপরিবর্তিত রানটাইমকে সরাসরি পাবলিক নেটওয়ার্কে পরিবেশন করার অনুমতি দিলে মূল ঝুঁকি আবার খুলে যাবে।

5. অবিলম্বে আপগ্রেড করা সম্ভব না হলে প্রশমন ব্যবস্থা

এই বিভাগটি স্বল্প-মেয়াদী এক্সপোজার হ্রাস বা প্রাপ্যতার উন্নতির উদ্দেশ্যে। প্রতিটি পরিমাপ শুধুমাত্র একটি নির্দিষ্ট পথকে কভার করে এবং একাধিক ব্যবস্থার সংমিশ্রণ সম্পূর্ণ মেরামতের সমতুল্য নয়। S1S2S3

5.1 PHP এর আগে ট্রাফিক নিয়ন্ত্রণকে অগ্রাধিকার দিন

যদি পরিষেবাটি এটির অনুমতি দেয়, অস্থায়ীভাবে সংবেদনশীল শেষ পয়েন্টগুলিকে বিশ্বস্ত উত্সগুলিতে সীমাবদ্ধ করুন বা PHP এর আগে অ্যাক্সেস নিয়ন্ত্রণ প্রয়োগ করুন৷ আপলোড ওয়ার্কলোডের জন্য, অনুরোধ-বডির আকার, ক্ষেত্র গণনা, অংশ গণনা, অংশ প্রতি শিরোনাম এবং নেস্টিং গভীরতা সীমিত করুন। যে পরিষেবাগুলির মাল্টিপার্টের প্রয়োজন নেই তারা ফ্রন্টএন্ডে এটি প্রত্যাখ্যান করতে পারে৷ S2

এই বিধিনিষেধগুলি PHP এর সমস্ত প্রবেশদ্বারগুলিকে কভার করার জন্য৷ শুধুমাত্র “আপলোড” নামের URL-কে বাধা দিলে অন্য এন্ট্রিগুলি মিস হবে যেগুলি এখনও অনুরোধের অংশে PHP দ্বারা স্বয়ংক্রিয়ভাবে পার্স করা হয়েছে৷ খণ্ডিত স্থানান্তর, উপলব্ধ ঘোষিত দৈর্ঘ্যের অভাব ইত্যাদি ক্ষেত্রে, সীমাটি প্রকৃত পঠিত আকারের উপর ভিত্তি করে হওয়া উচিত; আবার বিষয়বস্তু ডিকম্প্রেস বা প্রসারিত করার সময় অ্যাপ্লিকেশনটির নিজস্ব আউটপুট আকারের বাজেট থাকা উচিত।

5.2 FPM pool কনফিগারেশন টেমপ্লেট

FPM pool কনফিগারেশন বিভাগে নিম্নলিখিত সেটিংস রাখুন যা প্রকৃতপক্ষে অনুরোধগুলি পরিবেশন করে, php.ini-এ মৌখিকভাবে নয়। 8M এবং 4M মানগুলি কাজের চাপের জন্য সামঞ্জস্য করার উদাহরণ। সম্পূর্ণ POST অনুরোধ সীমিত করার সময় ফর্ম ফিল্ড এবং মাল্টিপার্ট বাউন্ডারির ​​জন্য জায়গা ছেড়ে দিন। S11S12

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

PHP 8.5 শুধুমাত্র, প্লাস:

php_admin_flag[fatal_error_backtraces] = off

প্রতিটির কাজ এবং সীমানা নিম্নরূপ:

কনফিগারেশনপ্রত্যাশিত প্রভাববিধিনিষেধের বর্ণনা যা অবশ্যই ধরে রাখতে হবে
memory_limit=-1অনুমানযোগ্য PHP অনুরোধ মেমরি উচ্চ সীমা ট্রিগার শর্ত সরানএটি অন্তর্নিহিত বরাদ্দ ব্যর্থতা প্রতিরোধ করে না; মূল বাজেট বাতিল করা মেমরি ক্লান্তি এবং পরিষেবা বাধার ঝুঁকি বাড়াতে পারে।
ছোট post_max_sizeপার্সিং প্রক্রিয়ায় প্রবেশ করা ডেটার আকার হ্রাস করুনঅনির্দিষ্ট পার্সার পরিচিত ফাঁক আছে; মেমরি পরিবর্ধন স্বাধীনভাবে প্রতিরোধ করা যাবে না
upload_max_filesize < post_max_sizeএকক ফাইলের আকার সীমিত করুন এবং রিজার্ভ অনুরোধ ওভারহেড স্থানসমস্ত ক্ষেত্র, মেটাডেটা বা অ্যাপ-মধ্যস্থ বরাদ্দগুলিকে সীমাবদ্ধ করে না
আপলোড অগ্রগতি বন্ধ করুননিশ্চিত সেশন সম্পর্কিত পথ ব্লক করুনঅন্যান্য গ্লোবাল স্টেট ভেরিয়েন্ট কভার করে না
PHP 8.5 মারাত্মক ব্যাকট্রেস বন্ধ করুনব্লক নিশ্চিত সম্পর্কিত স্থিতি প্রযোজকসেশনের মতো অন্যান্য পথ কভার করে না

পরিমাপের সীমানা সরকারী ঘোষণা থেকে আসে; পুল সিনট্যাক্স এবং ব্যবস্থাপনা-স্তরের কনফিগারেশন শব্দার্থবিদ্যার জন্য, PHP ম্যানুয়াল দেখুন। S1S2S3S11

ব্যবস্থাপনা-স্তরের php_admin_* সেটিংস ini_set() এর মাধ্যমে অ্যাপ্লিকেশন দ্বারা ওভাররাইড করা যাবে না। সমস্ত পুল, ডিরেক্টরি-স্তর এবং ফ্রন্ট-এন্ড ইনকামিং কনফিগারেশনগুলি এখনও নিশ্চিত করার জন্য পর্যালোচনা করা উচিত যে প্রকৃত অনুরোধের মানগুলি প্রত্যাশিত। পরিবর্তনের পরে, বিদ্যমান প্রক্রিয়াগুলিকে পুরানো অবস্থায় ধরে রাখা থেকে বিরত রাখতে সমস্ত কর্মীকে পুনর্নির্মাণ করুন।

আপনি যদি সরাসরি php.ini পরিবর্তন করতে চান, তাহলে সিনট্যাক্স পরিবর্তন করা উচিত:

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

পুলে php_admin_value এর বিপরীতে, শুধুমাত্র php.ini-এ memory_limit=-1 সেট করা অ্যাপটিকে আবার পরিবর্তন করা থেকে বাধা দেয় না। ফ্রেমওয়ার্ক, অ্যাপ্লিকেশন কোড, এবং অন্যান্য কনফিগারেশনগুলি সীমিত মান পুনরায় সেট করেছে কিনা তা দেখতে পরীক্ষা করা উচিত; যখন প্রয়োগের প্রয়োজন হয়, তখন বর্তমান SAPI-এর জন্য উপযুক্ত ব্যবস্থাপনা-স্তরের সেটিংস ব্যবহার করুন এবং প্রকৃত কার্যকর মান পরীক্ষা করুন। S11S12

শুধুমাত্র 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 কভারেজ সীমা

Cloudflare PHP2Shell এর বিরুদ্ধে সুরক্ষার জন্য মোতায়েন ব্যবস্থা ঘোষণা করেছে, যার মধ্যে Free পরিকল্পনা রয়েছে৷ এটির পরিষেবাগুলি ব্যবহার করার সময়, আপনার প্রকৃত ট্র্যাফিক প্রক্সির মধ্য দিয়ে যায় কিনা, সুরক্ষা নিয়ম কার্যকর কিনা এবং মূল স্থানটিকে সরাসরি বাইপাস করা যায় কিনা তা পরীক্ষা করা উচিত; অর্থপ্রদানের পরিকল্পনার জন্য, আপনাকে সংশ্লিষ্ট পরিচালিত নিয়মগুলির কনফিগারেশন এবং ব্যতিক্রমগুলিও পরীক্ষা করতে হবে। S16

বিক্রেতার দ্বারা বর্ণিত কিছু সনাক্তকরণ প্রতিক্রিয়া সংকেত ব্যবহার করে, তাই সমস্ত সুরক্ষাকে “PHP পৌঁছানোর আগে প্রতিটি আক্রমণ অবরুদ্ধ” হিসাবে ব্যাখ্যা করা যায় না। WAF এক্সপোজার কমাতে এবং পর্যবেক্ষণমূলক তথ্য প্রদান করতে সাহায্য করতে পারে, তবে PHP-এ অব্যাহত আপগ্রেড এখনও প্রয়োজনীয়। S16

5.7 কেন সাধারণ ব্যবস্থা অপর্যাপ্ত

ব্যবস্থা বা রায়ত্রুটিগুলি
শুধুমাত্র file_uploads বন্ধ করুনসমস্ত মাল্টিপার্ট প্রসেসিং কভার করতে পারে না এবং এর নিজস্ব OOM পাথ প্রয়োগ করতে পারে না৷
enable_post_data_reading=Off সেট করা হচ্ছেস্বয়ংক্রিয়ভাবে POST/FILES পূরণ করার আচরণ পরিবর্তন করুন; অনুরোধের অংশটি এখনও অ্যাপ্লিকেশন দ্বারা পড়া যেতে পারে এবং স্বাভাবিক ব্যবসা ব্যাহত করতে পারে
ত্রুটি প্রদর্শন বন্ধ করুন, লগ করুন বা @ ব্যবহার করুন৷অভ্যন্তরীণ ডায়াগনস্টিক প্রক্রিয়াকরণ এখনও ঝুলন্ত অবস্থায় অ্যাক্সেস করতে পারে
কর্মীর সংখ্যা বাড়ানএকটি নিরাপদ রাষ্ট্র পরিচ্ছন্নতার ব্যবস্থা স্থাপন করবেন না, বা একক শ্রমিকের পুনর্ব্যবহার দূর করবেন না
শুধুমাত্র disable_functions বা open_basedir কনফিগার করুনএই সীমাবদ্ধতা C ইঞ্জিন স্তর মেমরি দুর্নীতি ঠিক করে না
শুধুমাত্র একবার একটি সংস্করণ বা একক অনুলিপি পরীক্ষা করুনএটা প্রমাণ করা যাবে না যে সমস্ত প্রবেশদ্বার এবং চলমান উদাহরণ প্রতিস্থাপিত হয়েছে
কোন ব্যতিক্রম লগ দেখা যায় নাএটি প্রমাণ করতে পারে না যে দুর্বলতার অস্তিত্ব নেই বা এটি আগে শোষণ করা হয়নি।

তাদের মধ্যে, PHP এর কনফিগারেশন এবং দুর্বলতা প্রক্রিয়ার ভিত্তি S2S3S12 এ পাওয়া যাবে; কভারেজ, গ্রহণযোগ্যতা এবং অনুমতির সীমানা সম্পর্কে রায়গুলি এই প্রক্রিয়াগুলির দ্বারা সামনে রাখা বাস্তবায়নের পরামর্শগুলির উপর ভিত্তি করে।

6. অফিসিয়াল প্যাচের বাস্তবায়ন ধারণা এবং পর্যালোচনা পয়েন্ট

6.1 সঠিক শাখার জন্য সম্পূর্ণ সংশোধন ব্যবহার করুন

PHP 8.5 এর জন্য প্রতিনিধি অফিসিয়াল দাখিল হল:

31c0ea7d7ff1d1fccb6492e52dab544011628065
Avoid state corruption via bailout

প্রতিশ্রুতিটি স্পষ্টভাবে দুটি CVE-কে সংযুক্ত করে, উভয়ই OOM প্রস্থান প্রক্রিয়া সামঞ্জস্য করতে এবং বৈশ্বিক অবস্থা ঠিক করতে যা শুরুর পর্যায়ে অ্যাক্সেস করা যেতে পারে। সম্পূর্ণ পার্থক্য সহ পৃষ্ঠা জমা দিন S4S5 দেখুন। অন্যান্য শাখাগুলিকে তাদের নিজস্ব অফিসিয়াল নিরাপত্তা রিলিজ বা ম্যাচিং প্যাচ ব্যবহার করা উচিত, এবং এটি ধরে নেওয়া যায় না যে 8.5-এ পরিবর্তনগুলি সরাসরি কোনও পুরানো সংস্করণে প্রয়োগ করা যেতে পারে।

6.2 OOM মেরামত: প্রথমে প্রক্রিয়াযোগ্য অবস্থা পুনরুদ্ধার করুন এবং তারপর অনুরোধটি বন্ধ করুন

আনুষ্ঠানিক বাস্তবায়ন দুটি স্তরের নরম এবং শক্ত OOM প্রক্রিয়াকরণের প্রবর্তন করে: যখন নরম সীমায় পৌঁছে যায়, মুলতুবি অবস্থা রেকর্ড করা হয়, এবং একটি নিয়ন্ত্রিত প্রস্থান একটি নিরাপদ স্থানে যেমন VM সঞ্চালিত হয়; ব্যর্থ বরাদ্দ ইন্টারফেস কলারকে স্পষ্টভাবে ব্যর্থতা পরিচালনা করতে দেয়। যে বরাদ্দগুলি সরাসরি ব্যর্থতা ফেরত দিতে পারে না, যদি একটি উচ্চ হার্ড থ্রেশহোল্ড অতিক্রম করার প্রত্যাশিত হয়, একটি অনিরাপদ মধ্যবর্তী অবস্থায় অনুরোধগুলি প্রক্রিয়া চালিয়ে যাওয়া এড়াতে প্রক্রিয়াটি সরাসরি বন্ধ করা হবে। S2S5

নিচে 8.5 পার্থক্যের মূল কোডের একটি উদ্ধৃতি দেওয়া হল OOM মুলতুবি চিহ্নিত করার জন্য:

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

VM ব্যাঘাত হ্যান্ডলিং এবং অন্যান্য নিরাপদ অবস্থানগুলি পরবর্তীতে zend_handle_delayed_oom() কল করে। এর ইউজার কোড এক্সিকিউশন কনটেক্সট একটি নিয়ন্ত্রিত আনওয়াইন্ড পাথ ব্যবহার করে; কঠিন OOM পথটিকে _exit(137) বলে। S5

একটি নকশার দৃষ্টিকোণ থেকে, গুরুত্বপূর্ণ পরিবর্তনগুলি হল: avoids নির্বিচারে C কল স্ট্যাক অতিক্রম করে যখন কাঠামোটি একটি মধ্যবর্তী অবস্থায় থাকে, এবং প্রস্থানকে এমন একটি স্থানে রাখে যা রাষ্ট্রের সীমাবদ্ধতা বজায় রাখতে পারে। নরম সীমা ট্রিগার হওয়ার পরে, প্রক্রিয়াটি সম্পূর্ণ করার জন্য অতিরিক্ত মেমরির প্রয়োজন হতে পারে, তাই নতুন সফ্ট থ্রেশহোল্ড প্রক্রিয়াটির মোট মেমরির জন্য একটি পরম উপরের সীমা হিসাবে বোঝা যাবে না।

বা এটিকে “PHP সমস্ত zend_bailout() মুছে ফেলেছে” হিসাবে সংক্ষিপ্ত করা যাবে না। প্যাচ এখনও নির্দিষ্ট প্রসঙ্গে প্রাসঙ্গিক প্রক্রিয়া ব্যবহার করে; যা স্থির করা হয়েছে তা হল বিপজ্জনক প্রস্থান সময় এবং সহগামী রাষ্ট্রীয় ব্যবস্থাপনা। S5

6.3 বরাদ্দ কলার এবং মাল্টিপার্ট পার্সিং একসাথে আপডেট করুন

আপনি যদি শুধুমাত্র একটি বরাদ্দকরণ ফাংশন পরিবর্তন করে “ব্যর্থতার উপর NULL রিটার্ন” করেন এবং মূল কলার এখনও ধরে নেয় যে একটি বৈধ পয়েন্টার সর্বদা ফেরত দেওয়া হয়, তাহলে আপনি নতুন নাল পয়েন্টার অ্যাক্সেস বা অসম্পূর্ণ ক্লিনআপ প্রবর্তন করবেন। প্যাচের ব্যর্থ বরাদ্দ ইন্টারফেসটি কলার চেকিং এবং ব্যতিক্রম প্রচারের সাথে একসাথে পর্যালোচনা করা দরকার। S5

মাল্টিপার্ট রিলেটেড ফিক্সের মধ্যে রয়েছে প্রকৃত রিড ভলিউমের উপর ভিত্তি করে ক্রমবর্ধমান চেক করা, অকেজো বা ডুপ্লিকেট হেডারের প্রসেসিং কমানো এবং OOM মুলতুবি থাকা অবস্থায় সামঞ্জস্যপূর্ণ প্রস্থান এবং ক্লিনআপ লজিক গ্রহণ করা। এই পরিবর্তনগুলি উভয়ই সংস্থান পরিবর্ধন হ্রাস করে এবং পার্সারকে নতুন OOM প্রোটোকল মেনে চলতে বাধ্য করে৷ S5

যে দলগুলি তাদের নিজস্ব শাখাগুলি বজায় রাখে, তাদের জন্য সুপারিশ করা হয় যে নিম্নলিখিত সমস্যাগুলি কোড পর্যালোচনার কেন্দ্রবিন্দু হতে হবে:

  • রাষ্ট্র কি সম্পূর্ণরূপে চালু হওয়ার আগে বহির্বিশ্বের কাছে দৃশ্যমান?
  • বরাদ্দ ব্যর্থতা বা কলব্যাক ব্যতিক্রমের পরে, মালিকানা কি এখনও অনন্য এবং দ্ব্যর্থহীন?
  • আপনি মাঝপথে ব্যর্থ হলে ইউনিফাইড ক্লিনআপ প্রস্থানে পৌঁছাতে পারবেন?
  • ক্লিনআপ ফাংশন কি শুরু না করা বা মুক্ত ক্ষেত্র চিনতে পারে?
  • পার্সিং বাজেট কি প্রকৃত প্রসেসিং ভলিউমের উপর ভিত্তি করে, শুধু বিশ্বাসের অনুরোধ দাবি নয়?
  • নতুন ব্যর্থতার রিটার্ন মান কি সমস্ত কলার দ্বারা পরিচালিত হয়েছে?

এইগুলি হল ফিক্স মেকানিজমের উপর ভিত্তি করে সংক্ষিপ্ত করা পর্যালোচনা প্রশ্ন, এবং এটি একটি অডিটের উপসংহার নয় যা একটি অপ্রোভাইড কোড বেসের জন্য সম্পন্ন হয়েছে।

6.4 ক্রস-রিকোয়েস্ট ফিক্স: আগে শুরু করা, পরে চূড়ান্ত পরিষ্কার করা

CVE-2026-109619 এর সাথে সঙ্গতিপূর্ণ, প্যাচটি একই সময়ে একাধিক জীবন চক্রের সীমানা সামঞ্জস্য করে। নীচে তালিকাভুক্ত ফাইল এবং ক্রিয়াকলাপগুলি একটি উদাহরণ হিসাবে PHP 8.5 অফিসিয়াল পার্থক্য গ্রহণ করে। S5

অবস্থানদিক পরিবর্তনসমস্যা সমাধান
Zend/zend_execute_API.c ইত্যাদিএক্সিকিউটর স্ট্যাটাস রিসেট করুন যেমন ত্রুটি, ব্যতিক্রম, হ্যান্ডলার, অবজেক্ট ইত্যাদি।অনুরোধ শেষ হওয়ার পরে, এখনও পুরানো রেফারেন্স রয়েছে যা পরবর্তী অনুরোধ দ্বারা অ্যাক্সেস করা যেতে পারে।
main/main.c এর স্টার্টআপ পথSAPI সক্রিয় হওয়ার আগে php_basic_early_rinit() কল করুনযখন একটি প্রারম্ভিক ভোক্তা হয়, প্রাসঙ্গিক অন্তর্নিহিত অবস্থা এখনও আরম্ভ করা হয়নি।
main/main.c এর বন্ধ পথHTTP globals ধ্বংস করুন এবং এটিকে অনির্ধারিত হিসাবে চিহ্নিত করুনপ্রকাশিত মান এখনও একটি বৈধ বস্তু হিসাবে বিবেচিত হয়৷
অনুরোধের স্তূপ অবশেষে মুক্ত হওয়ার আগেশেষ ত্রুটি বার্তা আবার পরিষ্কার করুনদেরী ক্লিনআপ ডায়গনিস্টিক ত্রুটির স্থিতি পুনরুদ্ধার করে
ext/session/session.cআপলোড অগ্রগতি প্রারম্ভিক পথ প্রথম সেশন গ্লোবাল শুরু হয়নিয়মিত মডিউল RINIT পূর্বে পুরানো অবস্থায় অ্যাক্সেস করা হয়েছে
সিরিয়ালাইজেশন সম্পর্কিত কোডপ্রাথমিক প্রক্রিয়াকরণে ক্লাস পার্সিং এবং ব্যবহারকারীর কলব্যাক সীমিত করুনসূচনা সম্পূর্ণ না হলে অতিরিক্ত ব্যবহারকারী কোড চালান

উদাহরণস্বরূপ, স্টার্টআপ ক্রম অন্তর্ভুক্ত:

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

HTTP globals ধ্বংস হয়ে যাওয়ার পরে, স্থিতি ব্যর্থতার চিহ্ন যোগ করুন:

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

এই উদ্ধৃতিগুলি দুটি নীতির চিত্র তুলে ধরে: initialize যত তাড়াতাড়ি সম্ভব ভোক্তার আগে, এবং শেষ অপারেশনের পরে চূড়ান্ত পরিচ্ছন্নতা সঞ্চালন করুন যা রাষ্ট্রকে পুনরায় তৈরি করতে পারে। শুধুমাত্র স্বাভাবিক RINIT সময় একটি পয়েন্টার রিসেট করা বা পূর্ববর্তী শাটডাউন পর্যায়ের আগে বা পরে অ্যাক্সেস মিস হতে পারে। S5

6.5 কেন আপনার নিজের “এক-লাইন মেরামত” করার সুপারিশ করা হয় না?

সমস্ত zend_bailout() কে _exit() দিয়ে প্রতিস্থাপন করা, অথবা একটি নির্দিষ্ট এন্ট্রিতে শুধুমাত্র একটি নাল পয়েন্টার চেক যোগ করা, বিভিন্ন এক্সিকিউশন প্রেক্ষাপটের একটি বড় সংখ্যা বিস্তৃত করবে। তারা অন্যান্য স্থিতি ক্ষেত্রগুলি বাদ দিতে পারে, অথবা তারা ধ্বংস, বর্ধিত কলব্যাক, প্রক্রিয়া হোস্টিং এবং শেষ শব্দার্থের জন্য অনুরোধ করতে পারে।

সমর্থিত সংস্করণগুলির জন্য, ইতিমধ্যে প্রকাশিত সম্পূর্ণ সংশোধনগুলি অগ্রাধিকার পায়৷ নিজস্ব শাখার স্থানান্তরের ক্ষেত্রে প্যাচের উত্স, প্রযোজ্য বেসলাইন, দ্বন্দ্ব পরিচালনা এবং আচরণের পরিবর্তনগুলি রেকর্ড করা উচিত এবং সংশ্লিষ্ট আপস্ট্রিম রিগ্রেশন ব্যবহারের ক্ষেত্রে এবং এই ব্যবসায়িক প্রক্রিয়ার যাচাইকরণ ব্যবহার করা উচিত। এখানে পরামর্শগুলি বরাদ্দকারী, VM, অধিবেশন এবং জীবনচক্র পরিবর্তনের অনুরোধ জুড়ে প্যাচের সুযোগের বিশ্লেষণ থেকে এসেছে। S4S5

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