টেক লগ

php2shell (CVE-2026-109618 / 109619) php -v দিয়ে যাচাই করা যায় না: FPM, Docker ও ডিস্ট্রোতে ভার্সন নম্বর যেখানে আলাদা হয়ে যায়

প্রকাশের তারিখ: 2026-10-22 · লেখক: GRAMSHIFT

CLI বনাম FPM ভার্সন, Docker ট্যাগ, ডিস্ট্রোর ব্যাকপোর্ট, এবং শেয়ার্ড হোস্টিংয়ে যা যা দেখতে হবে

এই পাতাটি জাপানি মূল লেখা থেকে এআই দিয়ে অনুবাদ করা হয়েছে। কোনো অমিল থাকলে জাপানি সংস্করণই চূড়ান্ত বলে গণ্য হবে: 日本語

ওয়েব রিকোয়েস্ট সামলানো PHP (PHP-FPM, Apache-র mod_php, php-cgi, FrankenPHP, LiteSpeed) 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12-এর আগের ভার্সনের হলে সেটি php2shell নামে পরিচিত CVE-2026-109618 ও CVE-2026-109619-এর আওতায় পড়ে। সমাধান হলো এই ভার্সনগুলোর একটিতে (ডিস্ট্রো প্যাকেজের ক্ষেত্রে ফিক্স করা প্যাকেজে) আপগ্রেড করে প্রসেসগুলো রিস্টার্ট করা। যা যাচাই করতে হবে তা আপনার লোকাল php -v নয়, বরং “যে PHP আসলে ওয়েব চালাচ্ছে” এবং “ইনস্টল করা প্যাকেজের ভার্সন।”

এই লেখায় এমন চারটি জায়গা নিয়ে আলোচনা করা হয়েছে যেখানে শুধু ভার্সন নম্বর দেখে সিদ্ধান্ত নিলে ভুল সিদ্ধান্তে পৌঁছানো যায়। সব সংখ্যা ও অবস্থার তথ্য ২০২৬-১০-২২ পর্যন্ত, আর প্রতিটি বিষয়ের সূত্র শেষে দেওয়া আছে।

২০২৬-১০-২২ পর্যন্ত যা জানা গেছে

বিষয়	বিবরণ
CVE	CVE-2026-109618 (GHSA-w8hw-w9fx-j79w) / CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp)
তীব্রতা	PHP-র অ্যাডভাইজরিতে দুটোই CVSS v4.0 9.2 (Critical)
ফিক্স করা ভার্সন	8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 (প্রকাশ: ২০২৬-১০-২১)
প্রভাবিত ভার্সন	উপরের ফিক্স করা ভার্সনগুলোর আগের ভার্সন (GitHub অ্যাডভাইজরি অনুযায়ী)
পরিধি	ওয়েব রিকোয়েস্ট সামলানো যেকোনো PHP। অ্যাডভাইজরিতে PHP-FPM, mod_php, php-cgi, FrankenPHP ও LiteSpeed-এর নাম আছে, আর mod_php-কে সর্বোচ্চ ঝুঁকিপূর্ণ বলা হয়েছে। GitHub অ্যাডভাইজরিতে mod_php-তে শোষণ (exploitation) প্রদর্শিত হয়েছে, আর FPM ও FrankenPHP “প্রদর্শিত হয়নি” বা “শর্তসাপেক্ষ” হিসেবে তালিকাভুক্ত। প্রদর্শিত না হওয়ার মানে নিরাপদ নয়, তাই যেভাবেই PHP চালান না কেন ফিক্স করা ভার্সনে আপগ্রেড করুন
8.1 ও আগের ভার্সন	PHP প্রজেক্টের পক্ষ থেকে কোনো আপডেট নেই। 7.4 / 8.0 / 8.1-এর জন্য সোর্সের ন্যূনতম ব্যাকপোর্ট প্রকাশিত হয়েছে, এবং কিছু ডিস্ট্রো ও LTS ভেন্ডর ফিক্স দিতে পারে
8.2	২০২৬-১২-৩১-এ সাপোর্ট শেষ (8.2.35 রিলিজ নোট অনুযায়ী)

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

ফাঁদ ১: `php -v` আর ওয়েব-মুখী PHP আলাদা হতে পারে

SSH-এ php -v লিখলে CLI PHP-র ভার্সন দেখায়। ওয়েব রিকোয়েস্ট সামলায় PHP-FPM প্রসেস বা Apache-তে লোড করা mod_php, যেগুলো আলাদা বাইনারি ও আলাদা প্যাকেজ। শুধু CLI-র জন্য নতুন PHP ইনস্টল করলে, একসঙ্গে একাধিক ভার্সন চালালে, বা কোনো FPM পুল অন্য ভার্সনের দিকে নির্দেশ করলে php -v-তে ফিক্স করা ভার্সন দেখালেও ওয়েব দিক পুরোনো থেকে যেতে পারে।

ওয়েব দিকের আসল ভার্সন দেখার কয়েকটি উপায় আছে।

# Debian / Ubuntu-তে FPM (প্রতিটি ভার্সনের আলাদা নাম)
php-fpm8.3 -v

# RHEL-পরিবারে FPM
php-fpm -v

# Apache-তে mod_php লোড হয়েছে কি না দেখুন
apachectl -M | grep -i php

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

<?php echo PHP_VERSION, ' ', PHP_SAPI;

PHP_SAPI fpm-fcgi হলে PHP FPM-এর অধীনে চলছে; apache2handler মানে mod_php; cgi-fcgi মানে CGI। phpinfo() খোলা রেখে দেবেন না, কারণ তাতেই তথ্য ফাঁস হয়।

রিস্টার্ট করা আরেকটি সহজে ভুলে যাওয়া ধাপ। প্যাকেজ বদলে গেলেও ইতিমধ্যে চলমান php-fpm বা Apache প্রসেস পুরোনো কোডই চালাতে থাকতে পারে। কিছু সেটআপে প্যাকেজ আপডেটের সময় নিজে থেকে রিস্টার্ট হয়, কিছুতে হয় না। আপডেটের পর FPM / Apache রিস্টার্ট করুন এবং উপরের পদ্ধতিতে ওয়েব দিকের ভার্সন আবার যাচাই করুন।

ফাঁদ ২: Docker-এ ট্যাগের নাম দেখে বিচার করা যায় না

অফিশিয়াল php ইমেজে 8.3 ও 8.3-fpm-এর মতো “পরিবর্তনশীল ট্যাগ” আছে, যেগুলোর বিষয়বস্তু বদলে যায়, আর 8.3.30-এর মতো পিন করা ট্যাগ আছে, যেগুলো ভার্সন স্থির রাখে।

Docker Hub-এ পরিবর্তনশীল ট্যাগ ফিক্স করা ভার্সনে বদলে গেলেও আবার pull না করা পর্যন্ত আপনার লোকাল কপি পুরোনো ইমেজই থাকে। চলমান কন্টেইনারও নতুন করে তৈরি না হওয়া পর্যন্ত পুরোনো ইমেজ ব্যবহার করে। FROM php:8.3-fpm লেখা Dockerfile বিল্ড ক্যাশে পুরোনো বেস থেকে গেলে পুরোনো বেসের ওপরই বিল্ড করবে।
পিন করা ট্যাগ আপনি নিজে নম্বর না বাড়ানো পর্যন্ত চিরকাল পুরোনো থাকে।

ফিক্স করা ভার্সনের ট্যাগ প্রকাশিত হয়েছে কি না, Docker Hub API দিয়ে তা দেখা যায়।

curl -s "https://hub.docker.com/v2/repositories/library/php/tags?name=8.3.36&page_size=100"

২০২৬-১০-২২ তারিখে চারটি রিলিজ লাইনে অনুসন্ধানের ফলাফল নিচে দেওয়া হলো (সময় UTC-তে)।

ফিক্স করা ভার্সন	পাওয়া ট্যাগ	Debian-ভিত্তিক ট্যাগ (`-fpm`, `-apache` ইত্যাদি) যখন এসেছে	Alpine-ভিত্তিক ট্যাগ
8.5.12	54 (RC1 সহ)	2026-10-21 18:59–22:13	2026-10-21 22:12–10-22 01:05
8.4.27	54 (RC1 সহ)	2026-10-21 22:09–22:11	2026-10-21 22:09–10-22 03:58
8.3.36	27	2026-10-21 22:04–22:06	2026-10-21 22:04–10-22 03:56
8.2.35	27	2026-10-21 21:59–22:01	2026-10-21 22:00–10-22 00:58

এটি যাচাই করতে গিয়ে তিনটি জায়গা পাওয়া গেছে যেখানে নম্বর দেখে বিচার করলে বিভ্রান্ত হওয়ার আশঙ্কা থাকে।

“সম্প্রতি আপডেট হয়েছে” মানে “ফিক্স হয়েছে” নয়। পিন করা ট্যাগ 8.3.35 ২০২৬-১০-২১-এর মধ্যে আবার বিল্ড হয়েছিল, কিন্তু ভেতরের PHP_VERSION তখনও 8.3.35-ই ছিল। আপডেটের সময় নয়, ভেতরের ভার্সন দেখুন।
ডাইজেস্ট আলাদা হলেও বিষয়বস্তু এক হতে পারে। 8.3 ও 8.3.36-এর ট্যাগ ডাইজেস্ট (মাল্টি-আর্কিটেকচার ইনডেক্সের মান) আলাদা ছিল, কিন্তু amd64 ইমেজ একই ছিল এবং দুটোতেই PHP_VERSION=8.3.36 ছিল। একইভাবে 8.3-fpm / 8.3.36-fpm, 8.4-apache / 8.4.27-apache, latest / 8.5.12, 8.5-fpm ও 8.2-fpm-এর amd64 ইমেজের PHP_VERSION ফিক্স করা ভার্সন ছিল।
8.1 ও আগের ভার্সনের জন্য ফিক্স করা অফিশিয়াল ইমেজ নেই। 8.1-fpm সর্বশেষ আপডেট হয়েছে ২০২৫-১২-৩১-এ।

লোকাল ইমেজ ও চলমান কন্টেইনার যাচাই করতে:

# লোকালি pull করা ইমেজের PHP ভার্সন
docker image inspect php:8.3-fpm --format '{{range .Config.Env}}{{println .}}{{end}}' | grep PHP_VERSION

# আবার pull করে কন্টেইনার নতুন করে তৈরি করুন
docker compose pull
docker compose up -d

# নিজে ইমেজ বিল্ড করলে বেস আবার pull করে তারপর বিল্ড করুন
docker compose build --pull

# চলমান কন্টেইনারের ভেতরের ভার্সন
docker compose exec app php -r 'echo PHP_VERSION, PHP_EOL;'

শেষ কমান্ডের app-এর জায়গায় নিজের সার্ভিসের নাম বসান। প্রতিটি অফিশিয়াল ইমেজ একটিমাত্র PHP_VERSION দিয়ে বিল্ড করা, তাই কন্টেইনারের ভেতরের CLI ভার্সন ওই কন্টেইনারের FPM / Apache ভার্সনের সমান (হোস্টে সরাসরি PHP ইনস্টল করা থাকলে ফাঁদ ১ প্রযোজ্য)।

FrankenPHP-র ভেতরে PHP এমবেড করা থাকে, তাই FrankenPHP-র ভার্সন আর এমবেড করা PHP-র ভার্সন আলাদা নম্বর। ২০২৬-১০-২১-এ প্রকাশিত FrankenPHP 1.13.2-এর রিলিজ নোটে বলা আছে, Docker ইমেজ PHP 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 দিয়ে এবং স্ট্যাটিক বাইনারি PHP 8.5.12 দিয়ে বিল্ড করা হয়েছে।

ফাঁদ ৩: ডিস্ট্রো প্যাকেজ “পুরোনো নম্বরেই ফিক্স হয়”

Ubuntu ও RHEL শুধু ফিক্সগুলো পুরোনো ভার্সনে নিয়ে যায় (ব্যাকপোর্ট)। php -v-এ দেখানো নম্বর পুরোনোই থাকে, তাই “8.3.36-এর চেয়ে কম, অতএব ঝুঁকিপূর্ণ”-জাতীয় সংখ্যাভিত্তিক যাচাই ফিক্স করা সিস্টেমকেও ঝুঁকিপূর্ণ বলে চিহ্নিত করবে। উল্টো দিকে, নম্বর দেখে নিশ্চিন্ত হওয়াও যায় না। প্যাকেজের ভার্সন এবং প্রতিটি ডিস্ট্রোর সিকিউরিটি ট্র্যাকারের ভিত্তিতে সিদ্ধান্ত নিন।

২০২৬-১০-২২ পর্যন্ত প্রতিটি ট্র্যাকারে তালিকাভুক্ত ফিক্স করা প্যাকেজ (দুটো CVE-র ক্ষেত্রেই একই):

ডিস্ট্রো	প্যাকেজ	ফিক্স করা ভার্সন	সূত্র
Ubuntu 22.04 (jammy)	php8.1	8.1.2-1ubuntu2.28	USN-8948-1
Ubuntu 24.04 (noble)	php8.3	8.3.6-0ubuntu0.24.04.13	USN-8948-1
Ubuntu 26.04 (resolute)	php8.5	8.5.4-0ubuntu1.5	USN-8948-1
Ubuntu (stonking)	php8.5	8.5.9-0ubuntu2.1	USN-8948-1
Ubuntu 14.04 / 16.04 / 18.04 / 20.04	php5 / php7.0 / php7.2 / php7.4	Ubuntu Pro-র মাধ্যমে পাওয়া যায় (Legacy Support সহ)	USN-8948-2
Debian 12 (bookworm)	php8.2	8.2.35-1~deb12u1	DLA-4848-1
Debian 13 (trixie)	php8.4	8.4.27-1~deb13u1	DSA-6574-1
RHEL 10	php / php8.4	8.3.36-1.el10_2 / 8.4.27-1.el10_2	Red Hat
RHEL 9	php (ডিফল্ট)	8.0.30-8.el9_8.1	Red Hat
RHEL 9	php মডিউল 8.2 / 8.3	8.2.35-1.module+el9.8.0… / 8.3.36-1.module+el9.8.0…	Red Hat
RHEL 8	php মডিউল 7.4 / 8.2	7.4.33-8.module+el8.10.0… / 8.2.35-1.module+el8.10.0…	Red Hat

এই তালিকা থেকেই বোঝা যায় কেন শুধু নম্বর যথেষ্ট নয়। Ubuntu 24.04-এর ফিক্স করা PHP এমন একটি ভার্সন যা 8.3.6 দিয়ে শুরু, যা আপস্ট্রিমের 8.3.36-এর চেয়ে অনেক কম। RHEL 9-এর ডিফল্ট PHP 8.0.30-এ থেকেই ফিক্স করা, যদিও আপস্ট্রিম আর 8.0-এর জন্য ফিক্স দেয় না। Debian আপস্ট্রিমের একই নম্বরে (8.2.35 / 8.4.27) চলে গেছে।

কিছু প্যাকেজ এখনও ফিক্স হয়নি (২০২৬-১০-২২ পর্যন্ত)।

RHEL 9-এর php মডিউল 8.4 “প্রভাবিত, ফিক্স নেই” হিসেবে তালিকাভুক্ত।
Debian forky (testing)-তে php8.4 8.4.26-1, যা “vulnerable” চিহ্নিত। sid (unstable)-এর php8.4 হলো 8.4.27-1 এবং ফিক্স করা।

নিজের সার্ভার যাচাইয়ের উদাহরণ কমান্ড:

# Debian / Ubuntu: ইনস্টল করা ভার্সন ও পাওয়া যাওয়া ভার্সন
apt-cache policy php8.3-fpm libapache2-mod-php8.3

# Ubuntu: এই সার্ভারে এই CVE ফিক্স হয়েছে কি না
pro fix CVE-2026-109618
pro fix CVE-2026-109619

# RHEL-পরিবার: এই CVE ফিক্স করার কোনো আপডেট আছে কি না, এবং ইনস্টল করা ভার্সন
dnf updateinfo list --cve CVE-2026-109618
rpm -q php-fpm php-cli

প্যাকেজের নাম (php8.3-fpm ইত্যাদি) নিজের পরিবেশ অনুযায়ী বদলে নিন। দেখানো ভার্সন উপরের তালিকা বা ট্র্যাকারের “ফিক্স করা ভার্সন”-এর সমান বা বেশি হলে ফিক্স ঢুকে গেছে। এরপর ফাঁদ ১-এ বর্ণিত রিস্টার্ট ও ওয়েব দিকের যাচাই শেষ করুন।

ডিস্ট্রোর নিজস্ব প্যাকেজের বদলে থার্ড-পার্টি রিপোজিটরি থেকে PHP ইনস্টল করলে সেই রিপোজিটরির আপডেট অনুসরণ করতে হবে। PHP-র অ্যাডভাইজরিতে বলা হয়েছে, স্বেচ্ছাসেবীদের চালানো rpms.remirepo.net-এ প্রকাশের দিনে আপডেট থাকবে না, এবং ডিস্ট্রো প্যাকেজ বা নিজের বিল্ডে যাওয়ার পরামর্শ দেওয়া হয়েছে।

ফাঁদ ৪: শেয়ার্ড হোস্টিং ও ম্যানেজড পরিবেশে নিজে PHP আপগ্রেড করা যায় না

শেয়ার্ড হোস্টিং ও ম্যানেজড PHP পরিবেশে PHP রানটাইম বদলান প্রোভাইডার। এখানেও শুধু নম্বর যথেষ্ট নয়: প্রোভাইডার নিজে PHP বিল্ড করলে বা ফিক্স ব্যাকপোর্ট করলে ভার্সন নম্বর পুরোনো থেকে যেতে পারে।

নিজে করার মতো তিনটি কাজ আছে।

ওয়েব দিকের ভার্সন যাচাই করুন। ফাঁদ ১-এর অস্থায়ী ফাইল দিয়ে PHP_VERSION ও PHP_SAPI প্রিন্ট করুন, তারপর সঙ্গে সঙ্গে মুছে ফেলুন। কন্ট্রোল প্যানেলে PHP ভার্সন নির্বাচনের অপশন থাকলে কোন ভার্সন বেছে রেখেছেন তাও টুকে রাখুন।
প্রোভাইডারের নোটিশ পড়ুন, না থাকলে জিজ্ঞেস করুন। জিজ্ঞেস করুন: “আমার প্ল্যানের কোন কোন PHP ভার্সনে CVE-2026-109618 ও CVE-2026-109619-এর ফিক্স কবে প্রয়োগ করা হবে (বা হয়ে গেছে)?” ভার্সন নম্বরের বদলে CVE নম্বর ধরে জিজ্ঞেস করলে ব্যাকপোর্টসহ উত্তর পাওয়া যায়।
সাপোর্ট-বহির্ভূত ভার্সন বেছে রাখলে আপগ্রেড করুন। PHP প্রজেক্ট 8.1 ও আগের ভার্সনের জন্য কোনো ফিক্স দেয় না, আর 8.2-এর সাপোর্ট ২০২৬-১২-৩১-এ শেষ হচ্ছে। প্রোভাইডার ফিক্স ব্যাকপোর্ট না করে থাকলে ভার্সন বদলানোই নির্ভরযোগ্য পথ।

হোস্টিং প্রোভাইডারভেদে অবস্থা (২০২৬-১০-২২ পর্যন্ত)

শেয়ার্ড হোস্টিংয়ে সাধারণত প্রোভাইডারই PHP রানটাইম আপডেট করে, এবং অনেক প্রোভাইডারের নোটিশে বলা হয়েছে “ব্যবহারকারীর কোনো পদক্ষেপ প্রয়োজন নেই।” ব্যবহারকারীর করণীয় দুটি: নিজের প্রোভাইডারের অফিশিয়াল নোটিশ দেখা, আর কন্ট্রোল প্যানেলে পুরোনো PHP ভার্সন বেছে রাখলে নোটিশে সুপারিশ করা ভার্সনে (যার ফিক্স করা রিলিজ আছে) যাবেন কি না তা ঠিক করা।

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

প্রোভাইডার / সার্ভিস	অফিশিয়াল নোটিশের মূল কথা	নোটিশের তারিখ/সময়	সূত্র
エックスサーバー	“PHP 8.2–8.5-এর জন্য সব প্রভাবিত সার্ভারে ফিক্স প্যাচ প্রয়োগ সম্পন্ন হয়েছে।” পুরোনো ভার্সনের ক্ষেত্রে নোটিশে বলা হয়েছে “কিছু ভার্সনের জন্য ফিক্স প্যাচ প্রস্তুত এবং যাচাই শেষ হলে ধাপে ধাপে প্রয়োগ করা হবে,” এবং অন্য পুরোনো ভার্সনের কাজও চলছে	10/22 6:45-এর অবস্থা অনুযায়ী (পাতাটি 13:15 পর্যন্ত আপডেট হয়েছে)	メンテナンスの進捗状況
シン・レンタルサーバー	ঘোষণার পাতায় Xserver-এর মতোই “রক্ষণাবেক্ষণের অগ্রগতি” আছে, কিন্তু Shin Rental Server-এর PHP অবস্থা নিয়ে আলাদা করে কোনো বিবৃতি খুঁজে পাইনি (সাপোর্টে জিজ্ঞেস করুন)	-	お知らせ
ConoHa WING	“আপনি এখন যে PHP ভার্সন ব্যবহার করছেন তা বজায় রেখেই আমরা নিরাপত্তা প্যাচ প্রয়োগ করছি।” নোটিশে বলা হয়েছে সাধারণত ব্যবহারকারীর ভার্সন বদলানোর দরকার নেই, তবে PHP 5.x ও 7.x-এর ক্ষেত্রে বদলানো লাগতে পারে। ফাইল ম্যানেজার ও ওয়েবমেইল সতর্কতামূলকভাবে সাময়িকভাবে বন্ধ; ওয়েবসাইট প্রদর্শন এবং ইমেইল পাঠানো/গ্রহণ স্বাভাবিকভাবে চলছে	10/22	【重要】PHPの脆弱性への弊社対応について
さくらのレンタルサーバ	“আমাদের কন্ট্রোল প্যানেল থেকে নির্বাচনযোগ্য সব PHP ভার্সনের জন্য দুর্বলতা মোকাবিলার কাজ সম্পন্ন করেছি।” বলা হয়েছে “গ্রাহকদের জরুরি কোনো পদক্ষেপ প্রয়োজন নেই,” এবং ভবিষ্যতে সর্বশেষ সাপোর্টেড ভার্সনে যাওয়ার সুপারিশ করা হয়েছে। নোটিশে বলা আছে ওয়েবমেইল 10/22 13:45-এ ঠিক করা হয়েছে এবং phpMyAdmin-এর কাজ চলছে	10/22 (13:45-এ আপডেট)	PHPの脆弱性（CVE-2026-109618、CVE-2026-109619）への対応状況について
ロリポップ！	ফিক্স করা ভার্সন প্রকাশের আগে সতর্কতামূলক রক্ষণাবেক্ষণের নোটিশ (সার্ভিস সাইট, ইউজার পেজ ইত্যাদি পর্যায়ক্রমে বন্ধ হবে; পূর্বসূচনা ছাড়াই সাইট বন্ধ বা সীমিত হতে পারে)। 10/22 পর্যন্ত PHP ফিক্স সম্পন্ন হওয়ার ঘোষণা খুঁজে পাইনি (সাপোর্টে জিজ্ঞেস করুন)	10/21	【重要】PHPの脆弱性への予防措置に伴うメンテナンス実施のお知らせ
ヘテムル	“PHP 8.x ও PHP 7.4-এর জন্য অফিশিয়াল ফিক্স করা ভার্সন প্রয়োগ করা হয়েছে”; অন্য ভার্সনের জন্য “অফিশিয়াল ফিক্সের ভিত্তিতে আমরা নিজেরা ফিক্স করেছি।” যেহেতু “সব ভার্সনে কিছু ফাংশনালিটি (session.upload_progress) নিষ্ক্রিয় করা হয়েছে,” ব্যবহারকারীদের নিজের সাইট ঠিকমতো চলছে কি না যাচাই করতে বলা হয়েছে। পুরোনো ভার্সন আর ফিক্স না-ও পেতে পারে, তাই নোটিশে নতুন ভার্সনে যাওয়ার সুপারিশ করা হয়েছে	10/21 19:44-এ প্রকাশিত; 10/22 12:18 ও 13:20-এ আপডেট	【一部完了】【重要】PHPの脆弱性への予防措置に伴うメンテナンス実施のお知らせ
mixhost	“PHP ফিক্স প্যাকেজ প্রয়োগ ২০২৬ সালের ২২ অক্টোবর প্রায় 10:18-এ সম্পন্ন হয়েছে।” “PHP ভার্সন নম্বর না বদলে প্রয়োগ করা হয়েছে”; “গ্রাহকদের কোনো পদক্ষেপ প্রয়োজন নেই।” নোটিশে PHP 8.2-এর নিচের ভার্সনের ব্যবহারকারীদের সাপোর্টেড ভার্সন (8.2 বা তার পরের) ব্যবহারের সুপারিশ করা হয়েছে	10/22	【完了】PHPの重大な脆弱性への対応について
KAGOYA	রেন্টাল সার্ভার সার্ভিসে PHP 8.2–8.5 ফিক্স করা ভার্সন যাচাইয়ের পর ধাপে ধাপে আপডেট হবে (লক্ষ্য ভার্সন এখনও চূড়ান্ত হচ্ছে)। ম্যানেজড ডেডিকেটেড, শেয়ার্ড ও WordPress-নির্দিষ্ট সার্ভারে স্থায়ী ফিক্সের পরিকল্পনা চলছে; অন্তর্বর্তী ব্যবস্থা হিসেবে নোটিশে সাইট অফলাইন করা বা অ্যাক্সেস সীমিত করার কথা ভাবতে বলা হয়েছে	10/21 18:20-এ প্রকাশিত; 10/22 10:35-এ আপডেট	PHPの脆弱性に関する当社サービスへの影響について
Zenlogic（IDCフロンティア）	জরুরি রক্ষণাবেক্ষণে (10/21 22:00–10/22 18:00; শেষ সময় বদলাতে পারে) ফিক্স প্রয়োগ করা হয়েছে। PHP 5.3 সর্বশেষ ভার্সনে আপডেট হবে এবং ফেরানো যাবে না; 7.4 ও 8.1 আপডেট হতে পারে। নোটিশে বলা হয়েছে আপডেটের পর প্রদর্শন বা আচরণে সমস্যা হলে অ্যাপ্লিকেশনের দিকে ঠিক করতে হবে	10/21	【ホスティング】緊急メンテナンス作業のお知らせ
ColorfulBox	“আপনি এখন যে PHP ভার্সন ব্যবহার করছেন তা বজায় রেখেই সার্ভার-পক্ষে প্যাচ করা ভার্সনে আপডেট সম্পন্ন করেছি।” নোটিশে বলা হয়েছে “গ্রাহকদের নিজে PHP ভার্সন বদলানো বা পরিবর্তন করার প্রয়োজন নেই”	10/22	【重要】PHPの脆弱性に対するセキュリティアップデート完了のお知らせ
お名前.com レンタルサーバー	“আপনি এখন যে PHP ভার্সন ব্যবহার করছেন তা বজায় রেখেই আমরা নিরাপত্তা প্যাচ প্রয়োগ করছি।” নোটিশে বলা হয়েছে সাধারণত ভার্সন বদলানোর দরকার নেই, তবে PHP 5.x ও 7.x-এর ক্ষেত্রে লাগতে পারে। ফাইল ম্যানেজার ও ওয়েবমেইল সতর্কতামূলকভাবে সাময়িকভাবে বন্ধ	10/22	【重要】PHPの脆弱性への弊社対応について
CORESERVER（V2）	“আমরা যে সব PHP ভার্সন দিই তার সবকটির জন্য দুর্বলতা মোকাবিলার কাজ সম্পন্ন করেছি”; “গ্রাহকের দিক থেকে PHP ভার্সন বদলানোর মতো কোনো পদক্ষেপ প্রয়োজন নেই।” রক্ষণাবেক্ষণ চলেছে 10/22 0:00–11:13 এবং সম্পন্ন বলা হয়েছে	10/21-এ প্রকাশিত (10/22-এ সম্পন্ন)	PHP脆弱性の対応（CORESERVER V2）【完了】
XREA	“PHP 7.4 ও তার পরের ভার্সনের (7.4 / 8.0 / 8.1 / 8.2 / 8.3 / 8.4 / 8.5) জন্য দুর্বলতা মোকাবিলার কাজ সম্পন্ন করেছি।” এই ভার্সনের ব্যবহারকারীদের ভার্সন বদলানোর দরকার নেই। 7.4-এর নিচের ভার্সন নিয়ে নোটিশে কিছু বলা নেই	10/21-এ প্রকাশিত (10/22 0:50-এ সম্পন্ন)	PHP脆弱性の対応（XREA）【完了】
バリューサーバー	“PHP 7.4 ও তার পরের ভার্সনের জন্য দুর্বলতা মোকাবিলার কাজ সম্পন্ন করেছি।” নোটিশে বলা হয়েছে এই ভার্সনের ব্যবহারকারীদের ভার্সন বদলানোর দরকার নেই	10/21-এ প্রকাশিত (10/22 0:50-এ সম্পন্ন)	PHP脆弱性の対応（VALUESERVER）【完了】
ABLENET	“PHP-তে শনাক্ত হওয়া দুটি দুর্বলতা নিয়ে আমাদের রেন্টাল সার্ভার পরিবেশে নিরাপত্তা আপডেটের প্রাথমিক পদক্ষেপ নিয়েছি।” কোন কোন ভার্সন এর আওতায় এবং ব্যবহারকারীকে কিছু করতে হবে কি না, তা নোটিশে বলা হয়নি	10/22 13:04	PHPの脆弱性に関するセキュリティアップデートの対応について
WebARENA（レンタルサーバー）	10/22 পর্যন্ত কোনো অফিশিয়াল নোটিশ খুঁজে পাইনি (সাপোর্টে জিজ্ঞেস করুন)	-	WebARENA お知らせ（2026年）

যেখানে অফিশিয়াল নোটিশ খুঁজে পাইনি বা খুলতে পারিনি, সেখানে তালিকায় “নিশ্চিত করতে পারিনি” বা “খুঁজে পাইনি” লেখা আছে। সেখানে তথ্য না থাকার মানে প্রোভাইডার সাড়া দেয়নি, তা নয়। আপনার প্রোভাইডারের ঘোষণা ও সাপোর্টে সরাসরি যাচাই করুন।

এখনই আপডেট করতে না পারলে প্রশমন ব্যবস্থা

আপডেট করতে পারার আগ পর্যন্ত আক্রমণের সুযোগ কমানোর কিছু সেটিং PHP-র অ্যাডভাইজরিতে তালিকাভুক্ত আছে। তবে অ্যাডভাইজরিতে নিজেই স্পষ্ট বলা আছে যে এগুলো “আপনাকে নিরাপদ করে না।” মূল সেটিংগুলো:

CVE-2026-109619-এর জন্য: php.ini, FPM পুল বা সার্ভার কনফিগারেশনে session.upload_progress.enabled=0 সেট করুন এবং সব ওয়ার্কার রিস্টার্ট করুন (এর জন্য ini_set() ও FPM-এর .user.ini কাজ করে না)। PHP 8.5-এ fatal_error_backtraces=0-ও সেট করুন।
CVE-2026-109618-এর জন্য: অ্যাপ্লিকেশন ওভাররাইড করতে পারে না এমনভাবে memory_limit=-1 সেট করুন এবং post_max_size কমান (আপলোড না থাকলে 8M, থাকলে 32M)। RLIMIT_AS / RLIMIT_DATA-কে বিকল্প হিসেবে ব্যবহার করবেন না।

যুক্তরাজ্যের NCSC সুপারিশ করে, যে সিস্টেম এখনই আপডেট বা প্রশমন করা যাচ্ছে না তা অফলাইন করার কথা বিবেচনা করতে, এবং আপডেট বা প্রশমনের আগে আপসের (compromise) কোনো চিহ্ন আছে কি না দেখে নিতে।

সূত্র (২০২৬-১০-২২-এ যাচাই করা)

php.net: Security advisory: Critical remote code execution vulnerabilities, update now (2026-10-21)
php.net: Upcoming Critical PHP Security Release (2026-10-20)
php.net: PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35-এর রিলিজ ঘোষণা
GitHub: GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
GitHub: GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
Docker Hub: অফিশিয়াল php ইমেজ
FrankenPHP 1.13.2 রিলিজ নোট
Debian Security Tracker: CVE-2026-109618 / CVE-2026-109619
Ubuntu: CVE-2026-109618 / CVE-2026-109619 / USN-8948-1 / USN-8948-2
Red Hat: CVE-2026-109618 / CVE-2026-109619 (সংশোধিত প্যাকেজের সংস্করণ Red Hat-এর VEX ডেটা থেকে নেওয়া)
NCSC: Critical security issue affecting PHP

সচরাচর জিজ্ঞাসিত প্রশ্ন

php -v-তে ফিক্স করা ভার্সন দেখালে কি আমি php2shell (CVE-2026-109618 / 109619) থেকে সুরক্ষিত?

নিশ্চিত নয়। php -v শুধু CLI PHP-র ভার্সন জানায়। ওয়েব রিকোয়েস্ট সামলানো PHP-FPM বা Apache-র mod_php আলাদা বাইনারি ও আলাদা প্যাকেজ হতে পারে। FPM-এর ভার্সন দেখতে php-fpm8.3 -v চালান (RHEL-পরিবারে php-fpm -v)। বিকল্প হিসেবে PHP_VERSION ও PHP_SAPI প্রিন্ট করে এমন একটি অস্থায়ী ফাইল ওয়েব থেকে খুলুন, আর দেখা হয়ে গেলেই ফাইলটি মুছে ফেলুন। আপডেটের পর FPM বা Apache রিস্টার্ট না করলে সেগুলো পুরোনো কোডই চালাতে থাকতে পারে।

Docker-এর php:8.3-fpm ব্যবহার করলে কি php2shell ঠিক হয়ে গেছে?

২০২৬-১০-২২ পর্যন্ত Docker Hub-এর php:8.3-fpm PHP 8.3.36-এ বদলে গেছে। তবে আপনার লোকাল ইমেজ আবার pull না করা পর্যন্ত পুরোনোই থাকে, আর চলমান কন্টেইনার নতুন করে তৈরি না হওয়া পর্যন্ত পুরোনো ইমেজই ব্যবহার করে। docker compose pull ও docker compose up -d চালান (নিজে ইমেজ বিল্ড করলে docker compose build --pull)। তারপর কন্টেইনারের ভেতরে php -r 'echo PHP_VERSION;' চালিয়ে নিশ্চিত হোন যে ভার্সন 8.3.36 বা তার পরের। 8.3.30-এর মতো পিন করা ট্যাগ আপনি নিজে নম্বর না বাড়ানো পর্যন্ত পুরোনো থাকে।

Ubuntu ও RHEL-এ এখনও PHP 8.3.6 বা 8.0.30 দেখাচ্ছে। এগুলো কি php2shell-এ প্রভাবিত?

শুধু ভার্সন নম্বর দেখে বোঝা যায় না। Ubuntu ও RHEL পুরোনো ভার্সনে ফিক্স ব্যাকপোর্ট করে, তাই প্যাকেজ ঠিক হয়ে গেলেও নম্বর পুরোনো থাকে। ২০২৬-১০-২২ পর্যন্ত Ubuntu 24.04-এ php8.3 8.3.6-0ubuntu0.24.04.13 এবং RHEL 9-এ php 8.0.30-8.el9_8.1-এ ফিক্স আছে। আপনার ইনস্টল করা প্যাকেজের ভার্সন (apt-cache policy বা rpm -q) আপনার ডিস্ট্রোর সিকিউরিটি ট্র্যাকারের ফিক্স করা ভার্সনের সঙ্গে মিলিয়ে দেখুন। Ubuntu-তে pro fix CVE-2026-109618 এবং RHEL-পরিবারে dnf updateinfo list --cve CVE-2026-109618 দিয়েও যাচাই করা যায়।