PHP2Shell ও সার্ভার ভার্সন বিভ্রান্তি: আপনার PHP কি আসলেই নিরাপদ? পূর্ণাঙ্গ ইনভেস্টিগেশন ও ফিক্স গাইড

সার্ভার সিকিউরিটির এক অদ্ভুত প্যারাডক্স: ধরুন, আপনার শেয়ার্ড হোস্টিং বা ভিপিএস কন্ট্রোল প্যানেলে ঢুকে দেখলেন পিএইচপি ইনফো দেখাচ্ছে ভার্সন 8.2.34। অথচ অফিশিয়াল পিএইচপি সিকিউরিটি এডভাইজারিতে স্পষ্টভাবে বলা আছে সাম্প্রতিক ক্রিটিক্যাল সিকিউরিটি ফিক্স এসেছে 8.2.35 এ। আবার আরেকটা উবুন্টু ভিপিএস টার্মিনালে php -v কমান্ড দিতেই স্ক্রিনে ফুটে উঠল 8.3.6, অথচ ফিক্স আসার কথা 8.3.36 এ। সাধারণ দৃষ্টিতে যে কারও মনে হওয়া স্বাভাবিক যে সার্ভার দুটো চরম ঝুঁকিতে রয়েছে এবং যে কোনো মুহূর্তে হ্যাক হতে পারে। কিন্তু কারিগরি সত্যটি হলো, এই দুটো সংখ্যাই বাইরে থেকে আপনাকে বিভ্রান্তিকর বার্তা দিচ্ছে—ভেতর থেকে দুটো সার্ভারই হয়তো শতভাগ প্যাচ করা ও নিরাপদ।

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

১. PHP2Shell আসলে কী এবং কেন এটি এত বিপজ্জনক?

২১শে অক্টোবর পিএইচপির অফিশিয়াল টিম জরুরি ভিত্তিতে দুটি ক্রিটিক্যাল ভালনারেবিলিটি প্রকাশ করে, যেগুলোর ট্র্যাকিং নম্বর যথাক্রমে CVE-2026-109618 এবং CVE-2026-109619। কমন ভালনারেবিলিটি স্কোরিং সিস্টেমে (CVSS) এগুলোর ঝুঁকি রেটিং নির্ধারণ করা হয়েছে ৯.২ (আউট অব ১০), যাকে সাইবার সিকিউরিটির ভাষায় সরাসরি সর্বোচ্চ স্তরের বিপদ সংকেত বলা হয়। মূলত তিনটি সুনির্দিষ্ট কারণে এই ত্রুটি বিশ্বজুড়ে কোটি কোটি সার্ভারকে ঝুঁকিতে ফেলেছিল:

• লগইন ছাড়া রিমোট আক্রমণ (Zero-Auth RCE): এই দুর্বলতাকে কাজে লাগাতে হ্যাকারকে আপনার ওয়েবসাইটে নিবন্ধিত ব্যবহারকারী হতে হয় না কিংবা কোনো পাসওয়ার্ড জানতে হয় না। বাইরে থেকে একটি সুনির্দিষ্টভাবে ক্রাফট করা এইচটিটিপি রিকোয়েস্ট পাঠিয়েই সার্ভারের ভেতরে নিজস্ব শেল কোড এক্সিকিউট করা সম্ভব।
• ত্রুটি অ্যাপ্লিকেশনে নয়, পিএইচপির নিজস্ব ইঞ্জিনে: আপনার তৈরি ওয়ার্ডপ্রেস সাইট, লারাভেল অ্যাপ্লিকেশন কিংবা নিজস্ব পিএইচপি কোড কতটা মানসম্মতভাবে লেখা হয়েছে—তার ওপর এই আক্রমণ নির্ভর করে না। ত্রুটিটি সরাসরি পিএইচপির মূল এক্সিকিউশন ইঞ্জিনের ভেতরের মেমোরি ম্যানেজমেন্টে।
• বিগত এক দশকের সবকটি ভার্সনে প্রভাব: পিএইচপি ৫.৪ থেকে শুরু করে সাম্প্রতিক সকল আধুনিক ভার্সনই এই কাঠামোগত দুর্বলতার অন্তর্ভুক্ত ছিল। ফলে ইন্টারনেটের প্রায় ৮০ শতাংশ ডায়নামিক ওয়েবসাইট এর আওতায় পড়েছিল।

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

২. ঘরের উপমা দিয়ে মেমোরি করাপশনের সহজ মেকানিজম

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

বিপদটি ঘটে এক বিশেষ মুহূর্তে। যদি কোনো ইনকামিং রিকোয়েস্ট এমন একটি সময়ে পিএইচপির মেমোরি লিমিট (Memory Limit Exceeded) পার করে ফেলে যখন অভ্যন্তরীণ ডেটা স্ট্রাকচারগুলো এখনো পুরোপুরি সাজানো সম্পন্ন হয়নি, তখন পিএইচপি তাৎক্ষণিকভাবে স্বাভাবিক কাজ থামিয়ে দিয়ে একরকম তাড়াহুড়ো করে ঘর পরিষ্কারে নেমে পড়ে। দ্বিতীয় বাগটিও প্রায় অভিন্ন—সেখানে একটি অপ্রত্যাশিত ফ্যাটাল এরর মাঝপথে প্রসেস আটকে দেয়।

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

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

৩. ব্যাকপোর্টিং রহস্য: ভার্সন নম্বর কেন বিভ্রান্তিকর?

অনেকেই শুধু টার্মিনাল বা ড্যাশবোর্ডে পিএইচপির ভার্সন নাম্বার দেখে সিদ্ধান্ত নেন। এখানেই সবচেয়ে বড় ভুলটি ঘটে। উবুন্টু, ডেবিয়ান কিংবা বড় বড় ক্লাউড হোস্টিং প্রোভাইডাররা অনেক সময় পুরো পিএইচপি ভার্সন জাম্প করায় না। অর্থাৎ উবুন্টু ২৪.০৪-এর মূল প্যাকেজ যদি পিএইচপি 8.3.6 হয়ে থাকে, তবে তারা অফিশিয়াল 8.3.36-এ না গিয়ে সরাসরি 8.3.6 প্যাকেজের ভেতরেই সিকিউরিটি কোড ব্যাকপোর্ট (Backporting) করে ইনজেক্ট করে দেয়।

ফলে বাইরে থেকে ভার্সন নম্বর পুরোনো মনে হলেও ভেতরের বাইনারিটি শতভাগ নিরাপদ থাকে। তাহলে সত্য জানার উপায় কী? দুটি জায়গায় আসল প্রমাণ পাওয়া যায়:

• বিল্ড ডেট (Build Date): পিএইচপির কম্পাইলেশন বা বিল্ড ডেট যদি ২১শে অক্টোবর, ২০২৬ বা তার পরবর্তী তারিখের হয়, তবে বুঝতে হবে ভেতরে সিকিউরিটি কোড প্রতিস্থাপিত হয়েছে।
• প্যাকেজ চেঞ্জলগ (Package Changelog): লিনাক্স প্যাকেজের অভ্যন্তরীণ চেঞ্জলগ ফাইলে নির্দিষ্ট CVE নম্বরের স্পষ্ট উল্লেখ থাকে।

৪. সার্ভারে পিএইচপির ৩টি রূপ এবং বিপজ্জনক 'রানিং ওয়ার্কার' ফাঁদ

একটি সার্ভারে পিএইচপি মূলত তিনটি স্বতন্ত্র স্তরে কার্যকর থাকে:

1. কমান্ড লাইন পিএইচপি (CLI PHP): আপনি যখন এসএসএইচ টার্মিনালে php -v কমান্ড দেন, তখন অপারেটিং সিস্টেমের লোকাল বাইনারি ভার্সন প্রদর্শিত হয়।
2. ওয়েব প্রসেসর (PHP-FPM / FastCGI): আপনার এনজিনিক্স বা অ্যাপাচি ওয়েব সার্ভার যে সকেট বা পোর্টের মাধ্যমে পিএইচপি প্রসেস করে।
3. মেমোরিতে সচল ওয়ার্কার প্রসেস (In-memory Worker Processes): মেমোরির ভেতরে আগে থেকেই সক্রিয় থাকা চাইল্ড প্রসেসগুলো।

বিপজ্জনক ফাঁদটি কোথায়? আপনি যখন টার্মিনালে apt update && apt upgrade চালাবেন, অপারেটিং সিস্টেম নতুন প্যাচ করা ফাইলগুলো ডিস্কে ডাউনলোড করে প্রতিস্থাপন করবে। ফলে টার্মিনালে php -v দিলে আপনি নতুন সিকিউরিটি বিল্ড দেখতে পাবেন। কিন্তু আপনার ওয়েবসাইট যেসব পিএইচপি-এফপিএম ওয়ার্কার প্রসেস দিয়ে চালু ছিল, সেগুলো মেমোরিতে রিস্টার্ট না করা পর্যন্ত পুরোনো অনিরাপদ বাইনারি কোড নিয়েই চলতে থাকবে!

এই অমিলটি শনাক্ত করার জন্য দুটি কমান্ড মিলিয়ে দেখা জরুরি:

• প্যাকেজ ইনস্টলেশনের সময় বের করার কমান্ড:grep php8.3-fpm /var/log/dpkg.log | tail -1
• সার্ভিসটি কখন থেকে চলছে তা দেখার কমান্ড:systemctl status php8.3-fpm

যদি দেখা যায় পিএইচপি-এফপিএম সার্ভিস চালু হওয়ার সময়টি প্যাকেজ ইনস্টলেশনের সময়ের চেয়ে পুরোনো, তবে নিশ্চিতভাবে বুঝতে হবে আপনার সার্ভার মেমোরি স্তরে এখনো অনিরাপদ। সমাধান হলো অবিলম্বে সার্ভিস রিস্টার্ট দেওয়া:

sudo systemctl restart php8.3-fpm

৫. পিএইচপি ৮.৪ আপগ্রেড ও প্যারামিটার ডেপ্রিকেশন সমাধান

পিএইচপি ৮.২ ভার্সনের অফিশিয়াল সাপোর্ট ২০২৬ সালের ৩১শে ডিসেম্বর সমাপ্ত হচ্ছে। তাই সাময়িক প্যাচ নিয়ে বসে না থেকে দীর্ঘমেয়াদী সুরক্ষার জন্য সক্রিয়ভাবে সমর্থিত পিএইচপি ৮.৪ এ আপগ্রেড করাই সর্বোত্তম কৌশল, যার অফিশিয়াল সিকিউরিটি সাপোর্ট বজায় থাকবে ২০২৮ সালের শেষ পর্যন্ত।

তবে যেকোনো সার্ভারে পিএইচপি ভার্সন পরিবর্তনের আগে কিছু আবশ্যিক প্রস্তুতি নেওয়া প্রয়োজন:

• ডাটাবেস এবং সম্পূর্ণ সোর্স কোডের একটি নির্ভরযোগ্য অফলাইন ব্যাকআপ গ্রহণ করা।
• ওয়ার্ডপ্রেস থিম, প্লাগইন অথবা ফ্রেমওয়ার্ক ডিপেন্ডেন্সিগুলো আধুনিক ভার্সনে আপডেট করা।
• ভার্সন পরিবর্তনের পর সরাসরি লাইভ সাইটে এরর লগ (Error Log) মনিটর করা।

পিএইচপি ৮.৪ এ কমন ডেপ্রিকেশন ত্রুটি ও কোড ফিক্স: পিএইচপি ৮.৪ এ ইম্প্লিসিট নালেবল প্যারামিটার (Implicitly Nullable Parameter) ডেপ্রিকেট করা হয়েছে। যেমন পূর্বে লেখা হতো:

function find_orders(string  = null) { ... }

যেখানে টাইপ দেওয়া আছে string কিন্তু ডিফল্ট মান দেওয়া আছে null। পিএইচপি ৮.৪ এতে ওয়ার্নিং দেয় এবং ভবিষ্যতে পিএইচপি ৯ এ এটি ফ্যাটাল এররে রূপ নেবে। এর সঠিক আধুনিক রূপ হলো টাইপের আগে প্রশ্নবোধক চিহ্ন দিয়ে স্পষ্টভাবে নালেবল ঘোষণা করা:

function find_orders(?string  = null) { ... }

৬. উবুন্টু ভিপিএস কনফিগারেশন ও অতিরিক্ত নিরাপত্তা মেজার (CVE-2026-5560)

২৩শে অক্টোবর পিএইচপি টিম আরেকটি সম্ভাব্য দুর্বলতা চিহ্নিত করে পরবর্তী আপডেট না আসা পর্যন্ত session.upload_progress অপশনটি বন্ধ রাখার সুপারিশ করেছে। ভিপিএস বা ডেডিকেটেড সার্ভারে এটি কার্যকর করার নিয়ম নিচে দেওয়া হলো:

echo "session.upload_progress.enabled = Off" | sudo tee /etc/php/8.3/fpm/conf.d/99-php2shell.ini sudo systemctl restart php8.3-fpm

এরপর অপশনটি সত্যি বন্ধ হয়েছে কিনা তা যাচাই করতে টার্মিনালে রান করুন:

php-fpm8.3 -i | grep "session.upload_progress.enabled"

আউটপুটে Off দেখালে বুঝতে হবে বাড়তি ভেক্টরটিও সফলভাবে সুরক্ষিত হয়েছে।

৭. পোস্ট-প্যাচ ফরেনসিক অডিট চেকলিস্ট: সার্ভারে কেউ আগেই ঢুকে পড়েনি তো?

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

1. সাম্প্রতিক পরিবর্তিত বা নতুন পিএইচপি ফাইল স্ক্যান: দুর্বলতা প্রকাশ পাওয়ার সময়কাল থেকে আপনার ওয়েব রুটে কোনো অচেনা পিএইচপি ফাইল তৈরি হয়েছে কিনা তা দেখতে কমান্ড চালান:find /var/www/html -name "*.php" -newermt "2026-10-01"অপরিচিত বা অদ্ভুত নামের কোনো ফাইল পরিলক্ষিত হলে তা অবিলম্বে কোড অডিট করে অপসারণ করুন।
2. অননুমোদিত ক্রনজব (Crontab) পরীক্ষা: আক্রমণকারীরা ব্যাকডোর হিসেবে স্থায়ী ক্রনজব সেট করে রাখে। সার্ভারের শিডিউলার পরীক্ষা করুন:ls -la /var/spool/cron/crontabs/ ls -la /etc/cron.d/বিশেষ করে www-data বা ওয়েব সার্ভার ইউজারের অধীনে কোনো ক্রনজব যুক্ত হয়েছে কিনা তা যাচাই করুন।
3. ডাটাবেসে নতুন অ্যাডমিন অ্যাকাউন্ট যাচাই: কোনো অননুমোদিত ইউজার গোপনে সিস্টেমে সর্বোচ্চ প্রিভিলেজ নিয়েছে কিনা তা ডাটাবেস টেবিল থেকে কুয়েরি করে দেখে নিন:SELECT email, role, created_at FROM users WHERE role = 'admin';
4. অ্যাক্সেস লগে ডট-গিট বা এনভায়রনমেন্ট ফাইল প্রবিং মনিটরিং:zgrep -E "(\.git|\.env)" /var/log/nginx/*access.log*যদি দেখেন বাইরের কোনো আইপি থেকে এই ফাইলগুলোতে অ্যাক্সেস নেওয়ার চেষ্টা করা হয়েছিল এবং সার্ভার 403 Forbidden দিয়ে তা প্রতিহত করেছে, তবে আপনার সার্ভার কনফিগারেশন সঠিক পথে রয়েছে।

৮. পুরোনো আনসাপোর্টেড পিএইচপি ভার্সনগুলোর (PHP 7.4, 8.0, 8.1) ভবিষ্যৎ

যেসব অ্যাপ্লিকেশন এখনো পিএইচপির অ্যান্ড-অব-লাইফ (EOL) ভার্সনে আটকে আছে, পিএইচপি অফিশিয়াল প্রজেক্ট তাদের জন্য কোনো প্রি-বিল্ট বাইনারি রিলিজ দেয় না। এই পরিস্থিতিতে তিনটি বাস্তবসম্মত পথ খোলা থাকে:

• দ্রুততম সময়ে আধুনিক ভার্সনে মাইগ্রেশন: ফ্রেমওয়ার্ক বা সিএমএস কোড আধুনিক পিএইচপি ৮.২ বা ৮.৩-এর সাথে কম্প্যাটিবল করে অ্যাপ আপগ্রেড করা।
• এক্সটেন্ডেড সাপোর্ট প্রোভাইডার ব্যবহার: ক্লাউডলিনাক্স (CloudLinux Hardened PHP), উবুন্টু প্রো (Ubuntu Pro ESM) অথবা বিশ্বস্ত এন্টারপ্রাইজ লিনাক্স রিপোজিটরি ব্যবহার করা, যারা পুরোনো ভার্সনেও সিকিউরিটি ফিক্স প্রদান করে থাকে।
• পাবলিক ইন্টারনেট থেকে বিচ্ছিন্নকরণ: যদি অ্যাপ্লিকেশনটি তাৎক্ষণিকভাবে আপগ্রেড করা কোনোভাবেই সম্ভব না হয়, তবে পাবলিক আইপি থেকে সাইটটি সরিয়ে ভিপিএন বা সুরক্ষিত ইন্টারনাল নেটওয়ার্কের আওতায় নিয়ে আসা।

সাধারণ জিজ্ঞাসা (FAQ)

প্রশ্ন: আমার সাইট ক্লাউডফ্লেয়ার (Cloudflare WAF) দিয়ে প্রটেক্টেড, তাহলেও কি পিএইচপি প্যাচ করা জরুরি?
উত্তর: হ্যাঁ, অবশ্যই জরুরি। ক্লাউডফ্লেয়ার বা যেকোনো ওয়েব অ্যাপ্লিকেশন ফায়ারওয়াল পরিচিত এক্সপ্লয়েট রিকোয়েস্ট আটকে দিয়ে আপনাকে সাময়িক সময় দেয়। কিন্তু ফায়ারওয়াল কখনোই সার্ভার সাইড প্যাচের বিকল্প নয়। স্থায়ী সুরক্ষার একমাত্র সমাধান হলো পিএইচপি ইঞ্জিন আপডেট করা।

প্রশ্ন: পিএইচপি ইনফো (phpinfo) ফাইল বানিয়ে কি সার্ভারের পাবলিক ডিরেক্টরিতে রেখে দেওয়া নিরাপদ?
উত্তর: এটি চরম অনিরাপদ একটি অভ্যাস। phpinfo() পেজে সার্ভারের অপারেটিং সিস্টেম, ইন্টারনাল পাথ, এনভায়রনমেন্ট ভ্যারিয়েবল এবং কনফিগারেশনের সব সংবেদনশীল তথ্য উন্মুক্ত হয়ে পড়ে। যাচাইয়ের কাজ শেষ হওয়ার সাথে সাথেই ফাইলটি সার্ভার থেকে ডিলিট করে দিতে হবে।

প্রশ্ন: ডকার (Docker) বা কন্টেইনারাইজড অ্যাপ্লিকেশনে এই আপডেট কীভাবে দেব?
উত্তর: ডকার ব্যবহারকারীদের ক্ষেত্রে ডকারফাইলে থাকা পিএইচপি বেস ইমেজ (Base Image) লেটেস্ট প্যাচ করা ট্যাগ দিয়ে আপডেট করে সম্পূর্ণ কন্টেইনার নতুন করে বিল্ড (Build) ও রি-ডেপ্লয় (Redeploy) করতে হবে।

অফিশিয়াল তথ্যসূত্র ও সহায়ক লিংক

• পিএইচপি অফিশিয়াল সিকিউরিটি এডভাইজরি ও রিলিজ নোট: php.net/releases
• উবুন্টু অফিশিয়াল নোবেল সিকিউরিটি নোটিশ (USN): ubuntu.com/security
• ক্লাউডফ্লেয়ার ডব্লিউএএফ রুলস ডকুমেন্টেশন: blog.cloudflare.com
• ডেবিয়ান সিকিউরিটি ট্র্যাকার পোর্টাল: security-tracker.debian.org