🥇পিএইচপি-এর গুরুতর দুর্বলতার বিবরণ প্রকাশিত হয়েছে এবং প্রতিকারমূলক আপডেট প্রকাশ করা হয়েছে

PHP 8.5.12, 8.4.27, 8.3.36, এবং 8.2.35-এর সংশোধনমূলক রিলিজ প্রকাশিত হয়েছে। এর সাথে, বর্তমানে অসমর্থিত PHP 7.4, PHP 8.0, এবং PHP 8.1 ব্রাঞ্চগুলোর জন্য প্যাচও প্রকাশ করা হয়েছে (ঝুঁকিপূর্ণ সংস্করণ 5.4 থেকে 7.3 এখনও প্যাচবিহীন রয়েছে), যা দুটি গুরুতর দুর্বলতা সমাধান করে।

CVE-2026-109618 — রিমোট কোড এক্সিকিউশন হলো একটি দুর্বলতা, যা প্রসেসের মেমোরি শেষ হয়ে গেলে আউট-অফ-মেমোরি হ্যান্ডলারের longjmp() ফাংশনটি এক্সিকিউট করার কারণে ঘটে। এই দুর্বলতার ফলে, রিকোয়েস্ট প্রসেসিং-এর সাথে যুক্ত অভ্যন্তরীণ স্ট্রাকচারগুলোর মধ্যে শুধুমাত্র কয়েকটি ইনিশিয়ালাইজড থাকা অবস্থাতেই PHP ইন্টারপ্রেটার বন্ধ হয়ে যেতে পারে। এরপর রিকোয়েস্ট কমপ্লিশন ফাংশনটি এই স্ট্রাকচারগুলোকে এমনভাবে অ্যাক্সেস করে যেন সেগুলো আগে থেকেই ইনিশিয়ালাইজড ছিল, যদিও সেগুলোর জন্য কোনো মেমোরি বরাদ্দ করা হয়নি।
আক্রমণের প্রধান উপায় হলো প্রসেসের উপলব্ধ মেমরি নিঃশেষ করার জন্য মাল্টিপার্ট রিকোয়েস্টগুলোকে কাজে লাগানো। post_max_size সীমাটি এড়ানোর জন্য Content-Length হেডারটি বাদ দেওয়া যেতে পারে এবং বিপুল সংখ্যক HTTP হেডার প্রেরণ করা যেতে পারে। পিএইচপি অ্যাপ্লিকেশনের নির্দিষ্ট অপারেশন, যা অতিরিক্ত মেমরি ব্যবহার করে, সেগুলোর উপর লক্ষ্যভিত্তিক আক্রমণও সম্ভব। mod_php-এর জন্য এই এক্সপ্লয়েটটি নিশ্চিত করা হয়েছে, কারণ এটি ব্যর্থ হলেও shutdown() ফাংশনটি কল করে। PHP-FPM ব্যর্থ হলে চাইল্ড প্রসেসটি বন্ধ করে দেয়, যা আক্রমণটিকে আরও কঠিন করে তোলে, কিন্তু তাত্ত্বিকভাবে অসম্ভব নয়।
CVE-2026-109619 – একটি নির্দিষ্ট অনুরোধের সাথে যুক্ত গ্লোবাল স্টেট সঠিকভাবে ক্লিয়ার না করার কারণে সৃষ্ট ইউজ-আফটার-ফ্রি দুর্বলতার ফলে রিমোট কোড এক্সিকিউশন। যদি কোনো অনুরোধ মারাত্মক ত্রুটি, টাইমআউট, বা মেমরি শেষ হয়ে যাওয়ার কারণে বাধাগ্রস্ত হয়, তবে গ্লোবাল স্টেট রিসেট নাও হতে পারে, এবং যে মেমরিকে পয়েন্টারগুলো নির্দেশ করে তা মুক্ত হয়ে যাওয়া সত্ত্বেও পয়েন্টারগুলো সক্রিয় থাকতে পারে। একই প্রসেসে পরবর্তী কোনো অনুরোধ প্রক্রিয়া করার সময়, অবশিষ্ট পয়েন্টারটি পুরোনো গ্লোবাল স্টেট অ্যাক্সেস করতে পারে।
আপলোড প্রোগ্রেস ইন্ডিকেটর কোডে (session.upload_progress) মাল্টিপার্ট রিকোয়েস্ট প্রসেসিংয়ের সময় মেমোরি শেষ হয়ে যাওয়ার পরিস্থিতি তৈরি করে এই এক্সপ্লয়টেশনটি করা যেতে পারে। এর প্রধান এবং নিশ্চিত অ্যাটাক ভেক্টর হলো PHP 8.5-এর fatal_error_backtraces হ্যান্ডলার, যা কাজ শেষ হওয়ার পর ট্রেসিং স্টেট রিসেট করে না। প্রথম ক্ষেত্রে, এই অ্যাটাকটি mod_php এবং PHP-FPM উভয়ের ক্ষেত্রেই সম্ভব, কিন্তু দ্বিতীয় ক্ষেত্রে এটি শুধুমাত্র mod_php-তেই সম্ভব। এমন কনফিগারেশনেও একটি অনিশ্চিত অ্যাটাকের কথা উল্লেখ করা হয়েছে, যেগুলোতে এমন ডিরেক্টিভ থাকে যা রিকোয়েস্ট প্রসেসিংয়ের একেবারে শুরুতে ওয়ার্নিং ট্রিগার করে (উদাহরণস্বরূপ, পুরোনো প্যারামিটার ব্যবহারের বিষয়ে ওয়ার্নিং)।

বলা হয়েছে যে, শুধুমাত্র একটি আপডেট ইনস্টল করার মাধ্যমেই দুর্বলতাগুলো সম্পূর্ণরূপে রোধ করা সম্ভব। নিম্নলিখিত পদক্ষেপগুলো সফল আক্রমণের সম্ভাবনা হ্রাস করে, কিন্তু সিস্টেমকে সম্পূর্ণ সুরক্ষিত করে না:

php.ini ফাইলে 'memory_limit=-1' প্যারামিটারটি সেট করলে আক্রমণকারীর পক্ষে মেমরি লিমিট শেষ হয়ে যাওয়া নিয়ন্ত্রণ করা কঠিন হয়ে পড়ে।
যদি বড় ফাইল আপলোড করার প্রয়োজন না হয়, তাহলে 'post_max_size = 8M' প্যারামিটারটি সেট করুন। 'upload_max_filesize' প্যারামিটারটি 'post_max_size' প্যারামিটারের চেয়ে কম হওয়া উচিত।
সিস্টেম লেভেলে cgroup memory.max অথবা কন্টেইনার মেমরি কনসাম্পশন প্যারামিটারের মাধ্যমে গ্রহণযোগ্য মেমরি ব্যবহারের সীমা নির্ধারণ করা যায়, কিন্তু সিস্টেম লিমিট RLIMIT_AS এবং RLIMIT_DATA-এর মাধ্যমে নয়, কারণ এগুলো কেবল একটি সমস্যাযুক্ত longjmp() কলের কারণ হয়।
পারফরম্যান্স গুরুত্বপূর্ণ না হলে, আপনি PHP-FPM-এ pm.max_requests=1 এবং Apache httpd-এ MaxRequestsPerChild ব্যবহার করে একটি ওয়ার্কার প্রসেস দ্বারা প্রক্রিয়াকৃত অনুরোধের সংখ্যা সীমিত করতে পারেন।
php.ini অথবা কনফিগারেশন স্তরে সেটিং সার্ভার (ini_set() বা FPM .user.ini এর মাধ্যমে নয়, কারণ অনুরোধ প্রক্রিয়া করার আগেই প্যারামিটারটি কার্যকর থাকতে হবে) "session.upload_progress.enabled=0" প্যারামিটারটি।
PHP 8.5 রিলিজ ব্যবহার করার সময় 'fatal_error_backtraces=0' প্যারামিটারটি সেট করতে হবে।
প্রতি-অনুরোধ ভিত্তিক অপ্রচলিত বা ত্রুটিপূর্ণ সেটিংস (যেমন assert.* এবং open_basedir-এ ভুল পাথ) অপসারণ করা হয়েছে, যেগুলোর কারণে ইনিশিয়ালাইজেশনের আগে ডায়াগনস্টিক বার্তা আউটপুট হচ্ছিল।
পিএইচপি কোডের সেইসব সমস্যা সমাধান করা, যা টাইমআউট এবং মারাত্মক ত্রুটির কারণ হতে পারে, যেমন কলব্যাক হ্যান্ডলার এবং ডাউনলোড প্রক্রিয়াকরণে ব্যর্থতা সম্পর্কিত সমস্যা।
PHP-এর পুরোনো সংস্করণগুলোর কোডে প্রথম দুর্বলতাটি রোধ করতে, আপনি আউট-অফ-মেমরি হ্যান্ডলারে longjmp() কলটিকে _exit() দিয়ে প্রতিস্থাপন করতে পারেন।
এছাড়াও, প্রাথমিক ঘোষণায় দেখানো অনুযায়ী, আপনি php.ini-তে max_input_nesting_level প্যারামিটারের মান কমিয়ে মাল্টিপার্ট রিকোয়েস্ট ব্লক করতে পারেন।

ডিস্ট্রিবিউশনগুলিতে দুর্বলতা সমাধানের অবস্থা এই পৃষ্ঠাগুলিতে জানা যাবে: Debian, Ubuntu, SUSE, RHEL, Gentoo, Arch,
ফেডোরা, ফ্রিবিএসডি।

পরিশিষ্ট ১: GPT-5.6 এবং Gemini 4 Argon AI মডেল ব্যবহার করে দুর্বলতাগুলো শনাক্ত করা হয়েছিল। OpenAI ওয়েবসাইট এবং স্থানীয় এক্সিকিউটেবল ফাইলগুলোর দুর্বলতা পরীক্ষা করার জন্য php2shell-checker ইউটিলিটি প্রকাশ করেছে, কিন্তু এই ইউটিলিটি বিস্তারিত বিশ্লেষণ প্রদান না করে শুধুমাত্র HTTP সার্ভার থেকে প্রাপ্ত PHP ভার্সন নম্বর অথবা "php -v" কমান্ড পরীক্ষা করে।

আপডেট ২: একটি ডাবল-ফ্রি দুর্বলতা কাজে লাগিয়ে তৈরি করা প্রোটোটাইপ এক্সপ্লয়েটের লেখক জানিয়েছেন যে, PHP 8.5.12-এ সমস্যাটি এখনও সমাধান করা হয়নি এবং এক্সপ্লয়েটটি কাজ করে চলেছে। PHP-এর প্রতিনিধিরা পূর্বে জানিয়েছিলেন যে, এই দুর্বলতাটি আসন্ন প্যাচগুলোর সাথে সম্পর্কিত নয় এবং এটি কোনো বাস্তব সমস্যা নয়। তবে, এক্সপ্লয়েটের লেখক দাবি করেছেন যে এটি সম্পূর্ণ ভিন্ন একটি দুর্বলতা ছিল।

উত্স: opennet.ru

পিএইচপি-এর গুরুতর দুর্বলতাগুলোর বিবরণ প্রকাশ করা হয়েছে এবং প্যাচও প্রকাশ করা হয়েছে।