WordPress CVE-2026-119977: আপডেটের সময়ই RCE ঝুঁকি ও নিরাপদ করণীয়

সারসংক্ষেপ: WordPress-এর নিরাপত্তা আপডেট বসানোর সময়ই কিছু সাইট সাময়িকভাবে আক্রমণের ঝুঁকিতে পড়তে পারে। কারণ আপডেটটি সাইটের পুরোনো (অসংশোধিত) কোড দিয়েই ফাইল খুলে বসায়। ত্রুটিটির নম্বর CVE-2026-119977, এটি WordPress 4.7 থেকে 7.1.3 পর্যন্ত সব সংস্করণে ছিল এবং 7.1.4-এ ঠিক করা হয়েছে। যুক্তরাষ্ট্রের সাইবার নিরাপত্তা সংস্থা CISA ৩ নভেম্বর ২০২৬-এ এটিকে “বাস্তবে শোষিত” ত্রুটির তালিকায় যুক্ত করেছে। এই লেখায় ব্যাখ্যা করেছি ত্রুটিটি কী, কারা ঝুঁকিতে, আপডেটের আগে কী করবেন এবং আপডেটের পরে কী যাচাই করবেন।

তথ্যগুলো WordPress-এর অফিসিয়াল নিরাপত্তা বিজ্ঞপ্তি (GHSA-4w3m-c66w-69mg), ত্রুটি আবিষ্কারক Umut Bayram-এর Picus Security-তে প্রকাশিত কারিগরি বিশ্লেষণ, Wordfence-এর আক্রমণ পর্যবেক্ষণ প্রতিবেদন, CISA-র KEV তালিকা এবং The Hacker News-এর প্রতিবেদন—এই পাঁচটি সূত্র মিলিয়ে যাচাই করা। কোথাও কোনো পক্ষ বিস্তারিত জানায়নি, সেখানে সেটি স্পষ্ট করে লেখা হয়েছে।

এক নজরে

• ত্রুটি: CVE-2026-119977 — WordPress core আপডেটারের ভেতরে “রেস কন্ডিশন” (race condition), যা দূর থেকে কোড চালানোর (Remote Code Execution) সুযোগ দেয়।
• ক্ষতিগ্রস্ত: WordPress 4.7 থেকে 7.1.3 পর্যন্ত।
• সমাধান: 7.1.4, সাথে পুরোনো শাখাগুলোর জন্য আলাদা আপডেট (7.0.8, 6.9.11, 6.8.12 … 4.7.39)।
• অ্যাকাউন্ট দরকার? না—লগইন ছাড়াই আক্রমণ সম্ভব, তবে সফল হতে হলে আপডেট চলার খুব ছোট একটি মুহূর্তে আক্রমণকারীকে “জিতে” যেতে হবে।
• তীব্রতা: Wordfence-এর স্কোরে CVSS 8.1 (High); WordPress-এর নিজস্ব সতর্কবার্তায় তীব্রতা Low বলা হয়েছে। পার্থক্যের কারণ নিচে ব্যাখ্যা করা হয়েছে।
• প্রকাশ: WordPress 7.1.4 প্রকাশিত হয় ২৮ অক্টোবর ২০২৬-এ; এই আপডেটে মোট ২২টি নিরাপত্তা ত্রুটি ঠিক করা হয়েছে।
• বাস্তবে শোষণ: CISA ৩ নভেম্বর ২০২৬-এ KEV তালিকায় যোগ করে; Wordfence জানায় ফায়ারওয়াল নিয়ম চালু করার ৯ মিনিটের মধ্যে আক্রমণের চেষ্টা শনাক্ত হয়েছে।

আপডেটই যখন ঝুঁকি—ব্যাপারটা আসলে কী

WordPress যখন নতুন সংস্করণ বসায়, তখন পুরো প্যাকেজটি সরাসরি জায়গায় বসিয়ে দেয় না। প্রথমে সেটি wp-content/upgrade ফোল্ডারের ভেতরে একটি অস্থায়ী ফোল্ডারে ফাইলগুলো খোলে, তারপর সেখান থেকে মূল সাইটে কপি করে, শেষে অস্থায়ী ফোল্ডার মুছে ফেলে।

সমস্যা হলো, পূর্ণ (complete) প্যাকেজে WordPress-এর ইনস্টলার ফাইলও থাকে—যেমন wp-admin/setup-config.php। ফলে অস্থায়ী সেই ফোল্ডারটি কিছুক্ষণের জন্য ওয়েবসাইটের ভেতরেই একটি “দ্বিতীয়, অসম্পূর্ণ WordPress” হিসেবে ব্রাউজার থেকে খোলা যায়। আর আগের সংস্করণগুলোতে অস্থায়ী ফোল্ডারের নাম অনুমানযোগ্য ছিল।

আক্রমণকারী কীভাবে সুবিধা নেয়

1. আক্রমণকারী অনুমানযোগ্য নাম ব্যবহার করে অস্থায়ী ইনস্টলারটি খুঁজে বের করে।
2. সেখানে নিজের একটি wp-config.php বসিয়ে দেয়, যেটি একটি ভুয়া (আক্রমণকারীর নিয়ন্ত্রিত) ডেটাবেসের দিকে ইশারা করে।
3. আপডেট প্রক্রিয়া সেই ফাইলটি সাইটের আসল কনফিগারেশনের জায়গায় কপি করে দেয়।
4. ফলে সাইটটি নিজের ডেটাবেস খুঁজে পায় না এবং WordPress-এর ইনস্টলেশন উইজার্ড চালু হয়ে পড়ে।
5. আক্রমণকারী নতুন একটি অ্যাডমিনিস্ট্রেটর অ্যাকাউন্ট তৈরি করে, তারপর একটি প্লাগিন আপলোডের মাধ্যমে সার্ভারে নিজের PHP কোড চালায়।

এই পুরো কাজটির জন্য তাকে আপডেট চলাকালীন মাত্র কয়েক সেকেন্ডের একটি “জানালা” ধরতে হয়। গবেষকের পরীক্ষাগারে এই জানালাটি ছিল মাত্র কয়েক সেকেন্ড—তাই একবার চেষ্টা করে সফল হওয়া কঠিন, কিন্তু স্বয়ংক্রিয় স্ক্রিপ্ট দিয়ে বারবার চেষ্টা করলে সম্ভাবনা বাড়ে।

সবচেয়ে জরুরি কথা: আপডেট বসানোর সময়ও ঝুঁকি থাকে

এখানেই ঘটনার আসল মোচড়। যে আপডেটটি এই ত্রুটি ঠিক করে, সেটি বসানোর কাজটি কিন্তু সাইটে আগে থেকে থাকা পুরোনো কোডই করে। অর্থাৎ, ৭.১.৪ বসানোর ঠিক সেই মুহূর্তেও অস্থায়ী ফোল্ডারের নাম একবারের জন্য অনুমানযোগ্য থাকতে পারে।

গবেষক Umut Bayram স্পষ্ট করেছেন—আসলে নির্ভর করে আপনার সাইটে আগে থেকে থাকা আপডেটার ঠিক করা হয়েছে কি না, তার ওপর। তাই ৭.১.৪-এ ওঠার আগে wp-content/upgrade ফোল্ডারটি ওয়েব থেকে পুরোপুরি বন্ধ করে দেওয়া সবচেয়ে বাস্তবসম্মত সুরক্ষা।

একটি সান্ত্বনার কথা: ত্রুটির যে অংশটি আক্রমণকারীকে আপনার আসল wp-config.php প্রতিস্থাপন করতে দেয়, সেই অংশটি আপডেট বসানোর সময়ই কাজ করে না—কারণ ফাইল কপির কাজ নতুন (ঠিক করা) কোডই করে।

কোন সাইট, কতটা ঝুঁকিতে

• WordPress 4.7 – 7.1.3: ক্ষতিগ্রস্ত। যত দ্রুত সম্ভব ঠিক করা সংস্করণে যান।
• ৪.৪ – ৫.৮: পুরোনো কোড অস্থায়ী ফোল্ডারের নামের সাথে দৈব অক্ষর যোগ করে, ফলে নাম অনুমান করা কঠিন—তবে ত্রুটিটি থেকেই যায়।
• ৫.৯ ও তার পরের সংস্করণ: পুরোনো কোড ফোল্ডারের নাম ডাউনলোড করা ফাইলের নাম অনুযায়ী রাখে, অর্থাৎ নাম অনুমানযোগ্য।
• ৪.৬ বা তার আগে: আর নিরাপত্তা আপডেট পাওয়া যায় না, তাই কোনো সমাধান নেই—এগুলো অবশ্যই সমর্থিত সংস্করণে নিতে হবে। গবেষকের মতে ত্রুটিটি ২০০৮ সালের WordPress ২.৭ থেকেই ছিল।

ছোট (partial) প্যাকেজে সব ফাইল থাকে না। গবেষকের ভাষায়, সিদ্ধান্তের বিষয় প্যাকেজটি ছোট না বড়—তা নয়; আসল প্রশ্ন হলো আপনার সাইটের আপডেটারটি ইতিমধ্যে ঠিক করা হয়েছে কি না। মনে রাখবেন, সাইটের core ফাইল অফিসিয়াল চেকসামের সাথে না মিললে বা “পুনরায় ইনস্টল” করলে WordPress নিজে থেকেই পূর্ণ প্যাকেজ ব্যবহার করে।

প্রমাণ: আক্রমণকারীরা ইতিমধ্যে চেষ্টা করছে

• CISA: ৩ নভেম্বর ২০২৬-এ CVE-2026-119977 কে Known Exploited Vulnerabilities তালিকায় যুক্ত করেছে। তবে তারা আক্রমণের ধরন বা লক্ষ্যবস্তু বিস্তারিত জানায়নি।
• Wordfence: তাদের ফায়ারওয়াল নিয়ম চালু হওয়ার ৯ মিনিট পরেই প্রথম আক্রমণের চেষ্টা মিলেছে। প্রথম ২১ ঘণ্টায় অস্থায়ী setup-config.php পথে ১৮,৫০০-এর বেশি অনুরোধ রেকর্ড হয়েছে। দুটি বড় উৎস প্রায় ১৪.৫ ঘণ্টা ধরে ছোট ছোট সাইট-গ্রুপ বারবার পরীক্ষা করেছে—যা আপডেটের মুহূর্ত ধরার চেষ্টার সাথে মিলে যায়।
• CVSS: Wordfence-এর স্কোর ৮.১ (High), কারণ সফল হলে ফলাফল সার্ভারে কোড চালানো। WordPress-এর নিজস্ব বিজ্ঞপ্তি এটিকে Low বলেছে, কারণ আক্রমণ জটিল—সঠিক সময়ে সঠিক প্যাকেজ, ওয়েব থেকে প্রবেশযোগ্য অস্থায়ী ফোল্ডার, নাম জানা এবং মুছে ফেলার আগেই কাজ শেষ করা—সব একসাথে লাগে।
• পাবলিক এক্সপ্লয়েট কোড: GitHub-এ কিছু কোড প্রকাশিত হয়েছে যাদের লেখকদের দাবি সেটি এই ত্রুটিতে কাজ করে; তবে কাজ করে কি না তা এখনো নিশ্চিতভাবে প্রমাণিত নয়।

আপডেট করার আগে: ধাপে ধাপে নিরাপদ পদ্ধতি

ধাপ ১ — wp-content/upgrade ফোল্ডারে ওয়েব থেকে প্রবেশ বন্ধ করুন। WordPress এই ফোল্ডার সরাসরি ডিস্কে ব্যবহার করে, তাই ওয়েব অ্যাক্সেস বন্ধ করলে আপডেট ভাঙে না।

Nginx ব্যবহার করলে সার্ভার কনফিগারেশনে যোগ করুন:

location ^~ /wp-content/upgrade/ { deny all; }

Apache ব্যবহার করলে ভার্চুয়াল হোস্টের ভেতরে ওই ফোল্ডারের জন্য <Directory> ব্লকে দিন:

Require all denied

শুধু .htaccess সম্পাদনা করার সুযোগ থাকলে WordPress রুটের .htaccess-এ, WordPress-এর নিজস্ব rewrite নিয়মগুলোর উপরে যোগ করুন:

RedirectMatch 403 ^/wp-content/upgrade/

সতর্কতা: wp-content/upgrade ফোল্ডারের ভেতরে .htaccess রাখবেন না। পুরোনো আপডেটার আপডেট খোলার আগে ওই ফোল্ডারের সব কিছু মুছে ফেলে—তখন ফাইলটি আর থাকবে না।

ধাপ ২ — যাচাই করুন। ব্রাউজারে https://আপনার-ডোমেইন/wp-content/upgrade/ খুলে দেখুন 403 আসছে কি না।

ধাপ ৩ — আপডেট করুন। 7.1.4 অথবা আপনার শাখার ঠিক করা সংস্করণে যান (যেমন 7.0.8, 6.9.11, 5.9.20, 4.7.39 ইত্যাদি)। আপডেটের পর আবার 403 যাচাইটি করে নিন।

বিকল্প পথ: ওয়েব রুটের বাইরে ম্যানুয়াল আপডেট

চাইলে হাতে আপডেট করতে পারেন—সাইটের ফাইল ও ডেটাবেস ব্যাকআপ নিন, নতুন সংস্করণ ওয়েব থেকে অপ্রবেশযোগ্য একটি ফোল্ডারে খুলুন, wp-config.php ও wp-content-এ হাত না দিয়ে শুধু core ফাইলগুলো জায়গামতো কপি করুন, তারপর ডেটাবেস আপডেট চালান। এতে ওয়েব থেকে খোলা কোনো অস্থায়ী ইনস্টলারই তৈরি হয় না।

মনে রাখুন: WP-CLI-র wp core update এই ঝুঁকি এড়ানোর উপায় নয়—সেটিও একই আপডেটার ব্যবহার করে একই ফোল্ডারে ফাইল খোলে।

আপডেটের পরে: সংক্রমণের লক্ষণ যাচাই

যেসব সাইট প্রকাশের পরও পুরোনো সংস্করণে ছিল, তাদের জন্য Wordfence এই বিষয়গুলো দেখার পরামর্শ দিয়েছে:

• wp-content/upgrade-এর ভেতরের PHP ফাইলে অস্বাভাবিক বা অপ্রত্যাশিত অনুরোধ (সার্ভার লগে)।
• এমন অ্যাডমিনিস্ট্রেটর অ্যাকাউন্ট, যাকে কেউ চেনে না।
• এমন প্লাগিন, যা কেউ ইনস্টল করেনি।
• wp-content/upgrade-এ এমন PHP ফাইল, যা কেউ রাখেনি।

Wordfence ব্যবহার করলে ফায়ারওয়ালটি “Extended Protection” মোডে অপটিমাইজ করা থাকা জরুরি—কারণ এই আক্রমণে WordPress লোড না করেই সরাসরি PHP ফাইল চাওয়া হয়। আর মনে রাখুন, ফায়ারওয়াল নিয়ম পাওয়া মানে আপডেট বসানো বন্ধ করা নয়। (Wordfence-এর ফ্রি ব্যবহারকারীরা এই ত্রুটির নিয়ম পাবেন ২৭ নভেম্বর ২০২৬ থেকে।)

শুধু এই ত্রুটি নয়—৭.১.৪-এর অন্য সমাধানগুলো

WordPress 7.1.4-এ মোট ২২টি ত্রুটি ঠিক হয়েছে। এর মধ্যে আছে একাধিক stored cross-site scripting (ব্লক ডেলিমিটার, Categories ব্লক, কমেন্ট পেজিনেশন, Customizer ইত্যাদি), Interactivity API-র কয়েকটি সমস্যা (প্রোটোটাইপ পলিউশন ও persistent denial-of-service সহ), অপ্রকাশিত Customizer পরিবর্তন ফাঁস হওয়ার একটি information disclosure, এবং Notes REST API-র একটি অনুমতি-দুর্বলতা। এসবের অনেকগুলোর জন্য Contributor/Author/Editor অ্যাকাউন্ট দরকার—তাই ঝুঁকি তুলনামূলক কম, কিন্তু আপডেট করলে সেগুলোও বন্ধ হবে।

আমাদের সাইটে কী অবস্থা—এবং আপনার জন্য পরামর্শ

নিরাপত্তার ক্ষেত্রে সবচেয়ে বড় ভুল হলো “অটো আপডেট হয়ে নিশ্চয়ই হয়ে গেছে” ধরে নেওয়া। তাই WordPress অ্যাডমিনে Dashboard → Updates-এ গিয়ে নিজে চোখে দেখুন আপনার সংস্করণ 7.1.4 বা শাখার ঠিক করা সংস্করণ কি না। অটো আপডেট চালু থাকলেও একবার যাচাই করা ভালো অভ্যাস।

আরও তিনটি অভ্যাস এই ধরনের ত্রুটির ক্ষতি কমায়: প্রথমত, নিয়মিত পূর্ণ ব্যাকআপ রাখুন (ফাইল ও ডেটাবেস—দুটোই); দ্বিতীয়ত, অ্যাডমিন অ্যাকাউন্টের সংখ্যা যতটা দরকার ততটাই রাখুন এবং দুই ধাপের যাচাই (2FA) চালু করুন; তৃতীয়ত, কোনো সন্দেহজনক নতুন অ্যাডমিন বা প্লাগিন চোখে পড়লে দ্রুত তদন্ত করুন।

সাধারণ কিছু প্রশ্ন

আমার সাইট অটো আপডেট হয়—তাহলে কি কিছু করার নেই?

অটো আপডেট ভালো, কিন্তু তার মানে এই নয় যে সব ঠিক হয়ে গেছে। একবার Dashboard → Updates-এ গিয়ে সংস্করণ নিশ্চিত করুন। আর যদি এখনো ৭.১.৩ বা পুরোনোতে থাকেন, তবে আপডেটের আগে wp-content/upgrade ব্লক করার পরামর্শটি গুরুত্বের সাথে নিন।

আমার সাইট কি হ্যাক হয়েছে কিনা বুঝব কীভাবে?

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

৭.১.৪-এ গেলে কি ভবিষ্যতে আর এই সমস্যা হবে?

না। ঠিক করা সংস্করণে ওঠার পর অস্থায়ী ফোল্ডারের নাম দৈব (random) হয়, অতিরিক্ত index গার্ড যোগ হয় এবং অস্থায়ী কনফিগারেশন ফাইল আর আসল ফাইলের জায়গায় কপি হয় না। এরপরের আপডেটগুলো এই ঝুঁকি ছাড়াই চলবে।

এটি কি কোনো নির্দিষ্ট প্লাগিনের দোষ?

না। এটি WordPress-এর core আপডেট প্রক্রিয়ার ত্রুটি, কোনো থিম বা প্লাগিনের নয়। তাই শুধু প্লাগিন আপডেট করলে সমাধান হবে না—core আপডেট করতেই হবে।

সূত্র

• WordPress নিরাপত্তা বিজ্ঞপ্তি — GHSA-4w3m-c66w-69mg
• Picus Security — Umut Bayram, CVE-2026-119977 কারিগরি বিশ্লেষণ
• Wordfence — WordPress 7.1.4 এবং আক্রমণের চেষ্টার বিশ্লেষণ
• CVE-2026-119977 রেকর্ড
• The Hacker News — Installing the Fix for an Exploited WordPress Flaw Can Expose Some Sites One Last Time

নোট: এই প্রতিবেদনের কারিগরি তথ্য WordPress-এর অফিসিয়াল বিজ্ঞপ্তি ও গবেষকের বিশ্লেষণ থেকে নেওয়া। কোনো পক্ষ যেখানে বিস্তারিত জানায়নি (যেমন CISA আক্রমণের বিবরণ), সেখানে আমরা অনুমান করিনি।

আপনার WordPress সাইট আপডেট, ব্যাকআপ বা নিরাপত্তা নিয়ে সহায়তা দরকার হলে আমাদের সাথে যোগাযোগ করুন। দেখুন WordPress Hosting, Server Configuration & Management এবং Backup Policy।