PHP-র গুরুতর CVE-2026-109618: খবর আসার দিনই আমরা যা করেছি, আর আপনার যা চেক করা দরকার
TrustByte Team
২৭ অক্টোবর, ২০২৬

২১ অক্টোবর ২০২৬ PHP প্রজেক্ট জরুরি একটা সিকিউরিটি রিলিজ ছেড়েছে। এতে দুটো গুরুতর নিরাপত্তা দুর্বলতা ঠিক করা হয়েছে, CVE-2026-109618 আর CVE-2026-109619। এগুলো কাজে লাগিয়ে হ্যাকার কোনো লগইন ছাড়াই ওয়েব সার্ভারে নিজের কোড চালিয়ে দিতে পারে। দুটোরই রেটিং ৯.২ (ক্রিটিক্যাল)। PHP 5.4 থেকে 8.5.11 পর্যন্ত সব ভার্সনই এর আওতায় ছিল।
ওয়েবের বিশাল একটা অংশ চলে PHP-তে: WordPress, Laravel অ্যাপ, বেশির ভাগ শেয়ার্ড হোস্টিং, আর বাংলাদেশের অনেক ব্যবসায়িক ওয়েবসাইট। এমন একটা ফাঁক খুললে কয়েক ঘণ্টার মধ্যেই হ্যাকাররা স্ক্যান করা শুরু করে দেয়। তাই ক্লায়েন্টরা জিজ্ঞেস করবেন, সেই অপেক্ষায় আমরা বসে থাকিনি। নিচে ধাপে ধাপে লিখছি আমরা কী করেছি, আর আপনার ওয়েবসাইট থাকলে এর মানে কী।
PHP-র এই দুর্বলতাটা আসলে কী?
দুটো ত্রুটিই PHP-র মূল রানটাইমে, WordPress বা কোনো প্লাগইনে নয়। Google Cloud-এর বিশ্লেষণ অনুযায়ী, একটার গোড়ায় আছে রিকোয়েস্টের মাঝপথে মেমোরি ফুরিয়ে গেলে PHP যেভাবে সেটা সামলায়; অন্যটার গোড়ায় রিকোয়েস্টের এমন ডেটা, যা মেমোরি ছেড়ে দেওয়ার পরেও রয়ে যায়। বিশেষভাবে সাজানো HTTP রিকোয়েস্ট পাঠিয়ে, যেমন মাত্রাছাড়া বড় আপলোড দিয়ে, হ্যাকার এই ত্রুটিগুলোর সুযোগ নিতে পারে, আর শেষমেশ সার্ভারে নিজের কোড চালাতে পারে।
PHP-র নিজেদের রিলিজ নোটে কোনো রাখঢাক ছিল না: "পুরোপুরি ঠেকানোর কোনো উপায় নেই, আপডেট করাই একমাত্র নিরাপদ পথ।"
- যেসব ভার্সনে ঠিক করা হয়েছে: PHP 8.5.12, 8.4.27, 8.3.36 আর 8.2.35
- কোনো প্যাচই আসবে না: PHP 8.1 আর তার আগের ভার্সনগুলোর মেয়াদ (end-of-life) শেষ, তাই ওই সাইটগুলোকে 8.2 বা তার পরের ভার্সনে যেতেই হবে
সতর্কবার্তা আসার পর আমরা কী করলাম?
আমাদের কাছে এটা নিউজলেটারে পড়ে রেখে দেওয়ার মতো খবর ছিল না; জরুরি অবস্থা ধরেই কাজে নেমেছি।
- সেদিনই সবাইকে জানিয়েছি। চলমান সব ক্লায়েন্ট, আগের যেসব ক্লায়েন্টের সাইট আমরা বানিয়েছি বা এখনো হোস্ট করি, আর যেসব ব্যবসার সঙ্গে তখনো কথাবার্তা চলছিল, সবাইকে। এটা "আমাদের দায়িত্বে পড়ে কি না", সেই হিসাব আগে কষতে বসিনি। যে সম্ভাব্য ক্লায়েন্ট এখনো কিছুতে সই করেননি, তাঁরও জানা দরকার যে তাঁর সাইট ঝুঁকিতে আছে।
- আমাদের দায়িত্বে থাকা প্রতিটা PHP ভার্সন মিলিয়ে দেখেছি। প্রতিটা সার্ভার আর সাইটের তালিকা করেছি: কোনটায় কোন PHP ভার্সন, আর সেটা দেখাশোনা করে কে, আমরা, হোস্টিং কোম্পানি, নাকি ক্লায়েন্ট নিজে।
- প্যাচ বসিয়ে রিস্টার্ট দিয়েছি। PHP-কে ঠিক করা বিল্ডে আপগ্রেড করেছি, তারপর PHP-FPM আর ওয়েব সার্ভার রিস্টার্ট দিয়েছি। এই ধাপটা জরুরি, কারণ Google যেমন বলেছে, ডিস্কে প্যাকেজ আপগ্রেড হয়ে গেলেও ওয়ার্কারগুলো রিস্টার্ট না হওয়া পর্যন্ত পুরোনো ঝুঁকিপূর্ণ কোডই মেমোরিতে চলতে থাকে।
- পুরোনো সাইটগুলোকে মেয়াদ ফুরানো PHP থেকে সরিয়েছি। PHP 8.1 বা তার আগের ভার্সনে চলা কোনো সাইট আর ফিক্স পাবে না। তাই সেগুলোকে সাপোর্টেড ভার্সনে আপগ্রেড করেছি, তারপর টেস্ট করে দেখেছি কিছু ভেঙে গেল কি না।
- সার্ভারে যখন ঢুকেছিই, WordPress কোর, থিম আর প্লাগইনও আপডেট করেছি। পরিষ্কার করে বলি, WordPress আপডেট করলে PHP-র ত্রুটি ঠিক হয় না। কিন্তু যে সাইটে PHP-র পুরোনো ভার্সন চলছে, সেখানে প্রায়ই পুরোনো প্লাগইনও পড়ে থাকে। এক ফাঁক বন্ধ করে পাশের ফোকরটা খোলা রেখে আসার কোনো মানে হয় না।
- যেখানে যতটুকু সম্ভব, নিরাপত্তা আঁটসাঁট করেছি। যেসব সার্ভারে হোস্টিং প্রোভাইডারের অপেক্ষায় থাকতে হয়েছে, সেখানে প্যাচ করা বিল্ড না আসা পর্যন্ত অ্যাডভাইজরিতে দেওয়া অস্থায়ী সেটিংস বসিয়ে রেখেছি, যেমন session upload progress বন্ধ করা আর আপলোড ও ইনপুটের সীমা কড়া করা।
- যাচাই করে ক্লায়েন্টকে জানিয়েছি। প্রত্যেক ক্লায়েন্ট একটা ছোট নোট পেয়েছেন: আগে আর পরে তাঁদের PHP ভার্সন কত, আমরা কী কী আপডেট করেছি, আর হোস্টের দিক থেকে কিছু বাকি থাকলে সেটা কী।
পুরোনো ক্লায়েন্ট আর সম্ভাব্য ক্লায়েন্টদেরও কেন জানালাম?
কারণ বিল মিটিয়ে দিলেই একটা ওয়েবসাইটের ঝুঁকি মিটে যায় না। বছর কয়েক আগে আমাদের বানানো অনেক সাইট এখনো ঠিক সেভাবেই চলছে, যেভাবে আমরা বুঝিয়ে দিয়েছিলাম, আর সেগুলোর মালিকদের PHP-র রিলিজ নোটের খোঁজ রাখার কোনো কারণ নেই। আমাদের বানানো কিছুতে গুরুতর ফাঁক আছে জেনেও চুপ করে থাকা আমাদের পক্ষে সম্ভব না।
সম্ভাব্য ক্লায়েন্টদের বেলাতেও একই কথা। যে ব্যবসা গত মাসে নতুন ওয়েবসাইট নিয়ে আমাদের সঙ্গে কথা বলেছে, আজও তাদের পুরোনো সাইটটাই চলছে। তাদের জানাতে আমাদের খরচ একটা ফোনকল। না জানালে তাদের কাস্টমারের ডেটা বেহাত হয়ে যেতে পারে।
এ মাসের শুরুতেই আমরা লিখেছিলাম ব্যবসায়িক ওয়েবসাইটে বারবার যেসব নিরাপত্তা ফাঁকফোকর পাই, সেগুলো নিয়ে। পুরোনো সার্ভার সফটওয়্যার ছিল সেই তালিকার একেবারে ওপরের দিকে, আর এবারের ঘটনা সেই সমস্যারই জলজ্যান্ত উদাহরণ।
আমার ওয়েবসাইট কি CVE-2026-109618-এর ঝুঁকিতে আছে?
আপনার সাইট যদি PHP-তে চলে, আর সব WordPress সাইটই PHP-তে চলে, তাহলে চেক না করা পর্যন্ত ধরে নিন উত্তরটা হ্যাঁ। যেভাবে চেক করবেন:
- WordPress: Tools → Site Health → Info → Server-এ গিয়ে PHP ভার্সন দেখুন
- cPanel বা অন্য হোস্টিং: "Select PHP Version" বা "MultiPHP Manager" অপশনটা খুঁজুন
- নিজের সার্ভার:
php -vচালান, আর আপগ্রেডের পর PHP-FPM বা Apache রিস্টার্ট দিতে ভুলবেন না
আপনার ভার্সন যে সিরিজের, সেই সিরিজে সেটা যদি 8.2.35, 8.3.36, 8.4.27 বা 8.5.12-এর চেয়ে পুরোনো হয়, তাহলে এখনই ব্যবস্থা নিতে হবে। আর ভার্সন যদি 7 দিয়ে শুরু হয়, কিংবা 8.0 বা 8.1 হয়, তাহলে কোনো প্যাচ আসবে না; আপগ্রেডই একমাত্র উপায়।
আগেভাগে মেইনটেন্যান্স বলতে আসলে কী বোঝায়?
বেশির ভাগ সময় এটা চোখেই পড়ে না। সাইট আগের মতোই খোলে, অর্ডার আসতে থাকে, আর "CVE" শব্দটা আপনাকে কখনো শুনতেই হয় না। সমস্যাটা আপনার নজরে আসার আগেই কাজটা সেরে ফেলা হয়।
ক্লায়েন্টের খেয়াল রাখা বলতে আমরা এটাই বুঝি। আমরা সৈয়দপুরের একটি সফটওয়্যার কোম্পানি; কাজ করি রংপুর বিভাগ, দেশের অন্যান্য জায়গা আর দেশের বাইরের ব্যবসার সঙ্গে। আপনার সাইটে প্যাচ বসেছে কি না, তা নিয়ে খটকা লাগলে আমাদের জিজ্ঞেস করুন। আমরা বিনা খরচে চেক করে দেব, আর যা পাব, সোজাসাপ্টা জানিয়ে দেব।



