PHP-তে গুরুতর RCE ত্রুটি: CVE-2026-109618 ও 109619 প্যাচ

২১ অক্টোবর ২০২৬ তারিখে PHP ডেভেলপমেন্ট টিম PHP 8.5.12, 8.4.27, 8.3.36 এবং 8.2.35 নিরাপত্তা সংস্করণ প্রকাশ করেছে। এই আপডেটগুলো সাইবার নিরাপত্তা মহলে “php2shell” নামে পরিচিত দুটি গুরুতর ত্রুটি সমাধান করে: CVE-2026-109618 এবং CVE-2026-109619। উভয় ত্রুটিই কোনো প্রমাণীকরণ ছাড়াই দূর থেকে কোড কার্যকর (RCE) করার সুযোগ দিতে পারে। PHP টিমের মূল বার্তা অত্যন্ত স্পষ্ট: PHP রানটাইম আপডেট করাই একমাত্র পূর্ণাঙ্গ সমাধান।

পরিচিত সার্ভার-সাইড ভাষা ব্যবহারকারী ওয়েবসাইটগুলোর প্রায় ৭০ শতাংশ PHP-তে চলায়, এই ঘোষণার পরপরই আন্তর্জাতিক ও ইউরোপীয় কম্পিউটার ইমার্জেন্সি রেসপন্স টিমগুলো জরুরি সতর্কবার্তা জারি করে, যার মধ্যে রয়েছে CERT-EU (নিরাপত্তা বিজ্ঞপ্তি 2026-018) এবং নেদারল্যান্ডসের ন্যাশনাল সাইবার সিকিউরিটি সেন্টার (NCSC-NL)। ইউরোপসহ বিভিন্ন অঞ্চলে বহু সরকারি পোর্টাল ও প্রাতিষ্ঠানিক ওয়েব সেবা প্যাচ প্রয়োগের সময় সতর্কতামূলকভাবে তাদের সাইট সাময়িক রক্ষণাবেক্ষণ মোডে রাখে।

নির্ধারিত সময়ের আগে CVE ফাঁস, আবিষ্কারের সময়রেখা ও কারিগরি কারণ

The PHP Foundation-এর কারিগরি প্রতিবেদনে জানানো হয়েছে, CVE-2026-109618-এর মূলে থাকা আউট-অফ-মেমোরি (OOM) আচরণটি প্রথম নজরে আসে ২০২৪ সালে Sovereign Tech Agency-এর অর্থায়নে OSTIF এবং Quarkslab পরিচালিত এক বাহ্যিক নিরাপত্তা নিরীক্ষায়। তখন এর অপব্যবহার কেবল তাত্ত্বিক মনে হয়েছিল এবং প্রস্তাবিত পরিবর্তনে পুরোনো এক্সটেনশনের সামঞ্জস্য নষ্ট হওয়ার ঝুঁকি ছিল। ২০২৬ সালের জুলাইয়ের শেষে PHP ‘Patch the Planet’ কর্মসূচিতে যুক্ত হওয়ার পর পরিস্থিতি বদলে যায়: ১১ আগস্ট ২০২৬ তারিখে Calif-এর গবেষক রায়ান অস্টিন (সিইও থাই দুয়ং-এর নেতৃত্বে) নিঃশর্ত রিমোট কোড এক্সিকিউশনের পথ প্রমাণ করে The PHP Foundation-এর নিরাপত্তা প্রকৌশলী ভলকার ডুশকে জানান। একই দিনে OpenAI স্বতন্ত্রভাবে একই মূল কারণ রিপোর্ট করে এবং পরে ২৪ আগস্ট Wiz ও ১৮ সেপ্টেম্বর OpenAI অতিরিক্ত আক্রমণের পথগুলো জানায়।

তবে নির্ধারিত প্রকাশের প্রায় ২৪ ঘণ্টা আগে সমন্বিত প্রকাশের সময়সূচি বিঘ্নিত হয়। ২০ অক্টোবর আনুমানিক ১৫:০০ UTC-তে সংশোধিত প্যাকেজ প্রকাশের আগেই দুটি CVE নম্বর ও শিরোনাম পাবলিক ফিডে ফাঁস হয়ে যায়, যার ফলে CERT-EU এবং NCSC-NL জরুরি সতর্কতা জারি করে। এখানে একটি গুরুত্বপূর্ণ বিষয় হলো: ২০ ও ২১ অক্টোবর বিভিন্ন ওয়েবসাইট সাময়িকভাবে বন্ধ থাকার ঘটনাটি কোনো নিশ্চিত গণ-আক্রমণের কারণে ঘটেনি, বরং প্যাচ না আসা পর্যন্ত সিস্টেম প্রশাসকদের সতর্কতামূলকভাবে সেবা অফলাইনে রাখার কারণে ঘটেছিল।

কারিগরি দিক থেকে, CVE-2026-109618 (GHSA-w8hw-w9fx-j79w, NVD) ঘটে যখন ইনকামিং রিকোয়েস্ট ডেটা পার্স করার সময় মেমোরি শেষ (OOM) হয়ে যায় এবং আংশিকভাবে তৈরি ডেটা স্ট্রাকচার অপরিষ্কার থেকে যায়, যা মেমোরি করাপশন ও RCE ঘটাতে পারে (CWE-119, CWE-787)। অন্যদিকে CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp, NVD) হলো একটি ইউজ-আফটার-ফ্রি (CWE-416) ত্রুটি, যেখানে রিকোয়েস্টের মেমোরি মুক্ত হওয়ার পরও সেশন আপলোড প্রোগ্রেস বা ফ্যাটাল এরর ব্যাকট্রেসের অভ্যন্তরীণ অবস্থা প্রসেসে থেকে যায়। PHP উভয় ত্রুটিকে CVSS v4.0 অনুযায়ী 9.2 (গুরুতর) এবং NVD CVSS v3.1 অনুযায়ী 9.8 (গুরুতর) হিসেবে চিহ্নিত করেছে।

ঝুঁকিতে থাকা সার্ভার কনফিগারেশন ও প্যাচকৃত সংস্করণ

PHP-এর আনুষ্ঠানিক বিজ্ঞপ্তিতে বলা হয়েছে, ওয়েব রিকোয়েস্ট প্রক্রিয়াকরণকারী প্রতিটি PHP ইনস্টলেশনই ঝুঁকির আওতায় রয়েছে—যার মধ্যে PHP-FPM, Apache mod_php, php.exe, CGI/FastCGI এবং FrankenPHP, RoadRunner ও Swoole-এর মতো দীর্ঘস্থায়ী ওয়ার্কার রানটাইম অন্তর্ভুক্ত। সবচেয়ে বেশি ঝুঁকি রয়েছে Apache mod_php পরিবেশে, যেখানে সব থ্রেড একই মেমোরি স্পেস ব্যবহার করে।

PHP-FPM ব্যবহারকারীদেরও নিশ্চিন্ত থাকার সুযোগ নেই। যদিও FPM প্রসেস আইসোলেশনের কারণে CVE-2026-109618-এর ঝুঁকি কিছুটা কমায়, তবুও CVE-2026-109619-এর সেশন আপলোড প্রোগ্রেস সুবিধাটি ডিফল্টভাবে চালু থাকে এবং কোনো বিশেষ অ্যাপ্লিকেশন স্ক্রিপ্ট ছাড়াই সাধারণ FPM ইনস্টলেশনে অপব্যবহার করা যায়। গবেষকরা mod_php এবং FPM উভয় ক্ষেত্রেই পূর্ণ রিমোট কোড এক্সিকিউশন নিশ্চিত করেছেন। Tenable-এর কারিগরি বিশ্লেষণে উল্লেখ করা হয়েছে যে FPM-এর মাস্টার প্রসেস ক্র্যাশ হওয়া ওয়ার্কারগুলোকে তাৎক্ষণিকভাবে পুনরায় চালু করে, তাই সার্ভিস সচল দেখানো মানেই আক্রমণের চেষ্টা হয়নি এমন নয়; পাশাপাশি GitHub-এ “php2shell PoC” নামে ছড়ানো ভুয়া রিপোজিটরিগুলো থেকে সতর্ক থাকতে বলা হয়েছে, যেগুলোতে ইনফোস্টিলার ম্যালওয়্যার পাওয়া গেছে।

সমর্থিত শাখাগুলোর জন্য প্রকাশিত আনুষ্ঠানিক প্যাচ সংস্করণগুলো হলো PHP 8.5.12, PHP 8.4.27, PHP 8.3.36 এবং PHP 8.2.35। ত্রুটির গুরুত্ব বিবেচনায় PHP নিরাপত্তা টিম জীবনচক্র শেষ হওয়া (EOL) PHP 7.4, 8.0 এবং 8.1-এর জন্যেও ন্যূনতম সোর্স-স্তরের প্যাচ শাখা প্রকাশ করেছে। Debian এবং Ubuntu-এর মতো Linux ডিস্ট্রিবিউশনে নিরাপত্তা প্যাচগুলো বিদ্যমান প্যাকেজ সংস্করণে ব্যাকপোর্ট করা হয়; তাই কেবল php -v-এর আউটপুটের ওপর নির্ভর না করে ডিস্ট্রিবিউশনের নিরাপত্তা বিজ্ঞপ্তির সাথে ইনস্টল করা প্যাকেজ সংস্করণ মিলিয়ে দেখা জরুরি (Debian Security Tracker, Ubuntu Security)।

জরুরি করণীয় তালিকা ও সাময়িক প্রশমন ব্যবস্থা

১. সব PHP রানটাইম চিহ্নিত করুন: বাহ্যিক বা অভ্যন্তরীণ HTTP ট্রাফিক পরিচালনাকারী সব PHP ইনস্টলেশন—FPM পুল, Apache mod_php, কন্টেইনার ইমেজ এবং FrankenPHP, RoadRunner বা Swoole ওয়ার্কার—তালিকাভুক্ত করুন এবং প্রকাশ্যে থাকা phpinfo() ডায়াগনস্টিক পেজগুলো সরিয়ে ফেলুন।

২. আপডেট প্রয়োগ ও ওয়ার্কার প্রসেস রিস্টার্ট: PHP 8.5.12, 8.4.27, 8.3.36 বা 8.2.35 সংস্করণে (অথবা আপনার Linux ডিস্ট্রিবিউশনের প্যাচকৃত প্যাকেজে) আপগ্রেড করুন এবং ওয়েব সার্ভারের পাশাপাশি সব PHP-FPM ওয়ার্কার প্রসেস রিস্টার্ট করুন যাতে পুরোনো বাইনারি মেমোরিতে না থাকে।

৩. সাময়িক কনফিগারেশন পরিবর্তন (কেবল প্যাচ প্রয়োগের আগ পর্যন্ত): PHP টিম স্পষ্টভাবে জানিয়েছে যে কনফিগারেশন পরিবর্তন কেবল নির্দিষ্ট কিছু আক্রমণের পথ সংকুচিত করে, কিন্তু প্যাচবিহীন সার্ভারকে নিরাপদ করে না। আপডেটের আগ পর্যন্ত CVE-2026-109618-এর ঝুঁকি কমাতে php_admin_value দিয়ে memory_limit=-1 নির্ধারণ করা যেতে পারে (যাতে ini_set() বা .user.ini দিয়ে তা পরিবর্তন করা না যায়) এবং post_max_size ও upload_max_filesize কমানো যেতে পারে; তবে অপারেটিং সিস্টেম স্তরে RLIMIT_AS বা RLIMIT_DATA সীমা নির্ধারণ করা যাবে না, অন্যথায় মেমোরি ত্রুটি আরও আগে ঘটবে। CVE-2026-109619-এর জন্য session.upload_progress.enabled=0 এবং PHP 8.5-এ fatal_error_backtraces=0 সেট করুন, এবং মনে রাখবেন যে error_reporting ও display_errors বন্ধ থাকলেও @ অপারেটর অভ্যন্তরীণ এরর অবজেক্ট তৈরি করতে পারে।

৪. ক্র্যাশ ও এরর লগ পরীক্ষা: বারবার ওয়ার্কার প্রসেস ক্র্যাশ, অস্বাভাবিক বড় multipart রিকোয়েস্ট এবং সন্দেহজনক সেশন আপলোড কার্যক্রমের জন্য FPM ও ওয়েব সার্ভারের লগ পরীক্ষা করুন। সাধারণ HTTP অ্যাক্সেস লগ পরিষ্কার দেখানোই সার্ভার অক্ষত থাকার চূড়ান্ত প্রমাণ নয়, কারণ মাঝপথে ক্র্যাশ হওয়া রিকোয়েস্টগুলো সবসময় সাধারণ অ্যাক্সেস লগে লেখা হয় না।

LeakData-এর দৃষ্টিভঙ্গি: সার্ভার ত্রুটির পর কীভাবে ক্রেডেনশিয়াল ও ডেটা সুরক্ষিত রাখবেন

প্রথমেই আমাদের ব্যবহারকারী ও অংশীদারদের আশ্বস্ত করতে চাই: LeakData প্ল্যাটফর্ম এবং আমাদের সেবাগুলো CVE-2026-109618 বা CVE-2026-109619 ত্রুটি দ্বারা প্রভাবিত নয়। আন্তর্জাতিক নিরাপত্তা বিজ্ঞপ্তি প্রকাশের পরপরই আমাদের নিরাপত্তা দল সব বাহ্যিক সুরক্ষা স্তর যাচাই করে পূর্ণ নিরাপত্তা নিশ্চিত করেছে। তবে যেসব প্রতিষ্ঠান ওয়েব অ্যাপ্লিকেশন পরিচালনা করে, তাদের ক্ষেত্রে php2shell-এর মতো গুরুতর RCE ত্রুটির সবচেয়ে বড় ঝুঁকি প্রায়ই পরবর্তী ধাপে—অর্থাৎ ক্রেডেনশিয়াল ও ডেটাবেস চুরির মাধ্যমে—প্রকাশ পায়।

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

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