Microsoft-এর ৯৬৬ patch—দুটি zero-day ইতিমধ্যেই আক্রমণে
Microsoft ৮ সেপ্টেম্বর ২০২৬-এর মাসিক security release-এ Windows ও অন্যান্য পণ্যের শত শত দুর্বলতার update প্রকাশ করেছে। BleepingComputer-এর গণনায় ওই দিনের Patch Tuesday-তে ৯৬৬টি flaw ঠিক হয়েছে; এর মধ্যে ১০৫টি Critical এবং দুটি actively exploited zero-day।
একই ৮ সেপ্টেম্বরের Microsoft security bulletin নিশ্চিত করেছে, CVE-2026-81963 ও CVE-2026-85880 update প্রকাশের আগেই আক্রমণে ব্যবহৃত হয়েছিল। দুটিই Windows-এর local privilege-escalation flaw; তাই প্রভাবিত Windows PC ও enterprise endpoint-এ এগুলোর fix প্রথম deployment wave-এ রাখা উচিত।
দুই zero-day কীভাবে ঝুঁকি বাড়ায়
CVE-2026-81963 Windows Update Stack-এর elevation-of-privilege vulnerability। File access-এর আগে link ঠিকভাবে resolve না হওয়ায় অনুমোদিত local attacker privilege বাড়িয়ে SYSTEM পর্যায়ে যেতে পারে। CVE-2026-85880 Windows Advanced Local Procedure Call বা ALPC-এর heap-based buffer overflow; এটিও local attacker-কে SYSTEM privilege অর্জনের সুযোগ দেয়।
এগুলো সরাসরি internet থেকে অননুমোদিত remote code execution-এর flaw নয়। আক্রমণকারীকে আগে আক্রান্ত system-এ code চালানোর বা অনুমোদিত local access পাওয়ার পথ তৈরি করতে হয়। কিন্তু সেই প্রাথমিক প্রবেশের পর SYSTEM privilege পাওয়া credential theft, malware execution এবং security control এড়িয়ে যাওয়ার ক্ষতি বাড়াতে পারে।
Microsoft আক্রমণকারী, malware, campaign বা আক্রান্ত প্রতিষ্ঠানের পরিচয় প্রকাশ করেনি। ফলে exploitation নিশ্চিত হলেও আক্রমণের বিস্তার সম্পর্কে নির্ভরযোগ্য সংখ্যা নেই; deployment priority নির্ধারণে confirmed exploitation-কে গুরুত্ব দেওয়া যায়, কিন্তু অজানা attack volume নিয়ে অনুমান করা ঠিক হবে না।
প্রথম ২৪ ঘণ্টায় Windows update আগে
ব্যক্তিগত PC ও managed enterprise endpoint-এর প্রথম অগ্রাধিকার হলো প্রভাবিত supported Windows build-এ September cumulative update পৌঁছানো। প্রথম wave-এ privileged-user workstation, administrator device, security-sensitive endpoint এবং অবিশ্বস্ত file বা application নিয়ে নিয়মিত কাজ করা system রাখা যুক্তিসঙ্গত।
শুধু update download হওয়া যথেষ্ট নয়। Deployment console-এ installation status-এর সঙ্গে সংশ্লিষ্ট KB বা নতুন OS build এবং প্রয়োজনীয় restart সম্পন্ন হয়েছে কি না মিলিয়ে দেখতে হবে। Install ব্যর্থ, rollback হওয়া বা pending restart অবস্থায় থাকা device-কে সফল deployment-এর হিসাবে রাখা যাবে না।
একটি সীমিত representative group-এ application compatibility ও boot health যাচাই করে দ্রুত বাকি fleet-এ rollout বাড়ানো যেতে পারে। তবে actively exploited flaw-এর ক্ষেত্রে দীর্ঘ, অনির্দিষ্ট testing period ঝুঁকি রেখে দেয়; test window-এর সময়সীমা এবং ব্যর্থ device সামলানোর আলাদা queue শুরুতেই নির্ধারিত থাকা দরকার।
Server ও Critical RCE-র জন্য সমান্তরাল lane
দুই zero-day প্রথম সারিতে থাকলেও server priority শুধু actively exploited label দিয়ে নির্ধারণ করা যাবে না। Microsoft-এর product-family তালিকায় Windows Server 2016, 2019, 2022 ও 2025, Microsoft Office এবং SQL Server-এর সর্বোচ্চ severity Critical ও maximum impact remote code execution। SharePoint ও Exchange-এর maximum impact-ও remote code execution, যদিও family-level severity Important দেখানো হয়েছে।
Ars Technica-র পর্যালোচনায় CVE-2026-55007 Exchange Server-এ unauthenticated RCE এবং CVE-2026-69525 Remote Desktop Services-এ ৯.৮ severity-এর RCE হিসেবে আলাদা গুরুত্ব পেয়েছে। প্রতিবেদনটি ৯৭২টি vulnerability ও ১১২টি Critical flaw গুনেছে—BleepingComputer-এর ৯৬৬ ও ১০৫-এর সঙ্গে পার্থক্যটি দেখায়, inclusion rule না জেনে headline total দিয়ে asset priority ঠিক করা নির্ভরযোগ্য নয়।
তাই internet-facing Exchange, বাইরে থেকে পৌঁছানো Remote Desktop service এবং অন্যান্য reachable server workload-এর জন্য Windows endpoint-এর পাশাপাশি আলাদা জরুরি lane প্রয়োজন। কোনো Critical RCE বাস্তবে network থেকে reachable হলে সেটি exploited local EoP update-এর সমান্তরালে যেতে পারে। Isolated server-এর maintenance dependency rollout ধীর করতে পারে, কিন্তু তার exposure ও compensating control নথিবদ্ধ থাকা দরকার।
Office ও SQL Server একই success metric নয়
Office package, Windows cumulative update এবং SQL Server update আলাদা product ও deployment path। এগুলোকে একটি সামগ্রিক success percentage-এ মেশালে কোন asset সত্যিই সুরক্ষিত হয়েছে তা বোঝা কঠিন হয়। Office-এর ক্ষেত্রে externally sourced document বেশি খোলা endpoint-কে আগে নেওয়া যায়; SQL Server-এর ক্ষেত্রে version, installed component, availability topology এবং সংশ্লিষ্ট application-এর health আলাদাভাবে যাচাই করতে হবে।
একটি কার্যকর phased order হতে পারে: প্রথমে দুই exploited CVE-তে প্রভাবিত Windows asset এবং সরাসরি reachable Critical RCE surface; এরপর উচ্চ-ঝুঁকির Office endpoint ও production-representative server canary; সফল installation ও service telemetry পাওয়ার পর বাকি managed fleet। এই ক্রম vulnerability-র মোট সংখ্যা নয়, exploitation evidence, attack precondition, reachability এবং asset criticality—এই চারটি বিষয়ের ওপর দাঁড়ায়।
Deployment-এর তিনটি যাচাই
- প্রযোজ্যতা: OS edition ও build, Windows Server role, Office channel এবং SQL Server version মিলিয়ে কোন update কোন asset-এ প্রয়োজন তা নির্ধারণ করতে হবে। Product-family তালিকায় নাম থাকা মানেই সেই family-এর প্রতিটি machine একইভাবে আক্রান্ত নয়।
- Known issue: production wave-এর আগে সংশ্লিষ্ট KB-এর known-issue অংশ, restart requirement ও প্রযোজ্য mitigation দেখতে হবে। Microsoft individual support article ও September release notes যাচাই করার নির্দেশ দিয়েছে।
- বাস্তব ফল: rollout-এর পরে installation status, KB বা build level, reboot completion এবং business-service health আলাদাভাবে যাচাই করতে হবে। ব্যর্থ update ও rollback শনাক্ত না হলে deployment dashboard সুরক্ষার অতিরঞ্জিত ছবি দেখাতে পারে।
এখন পর্যন্ত নিশ্চিত অবস্থাটি স্পষ্ট: CVE-2026-81963 ও CVE-2026-85880 বাস্তব আক্রমণে ব্যবহৃত হয়েছে এবং তাদের update প্রকাশিত হয়েছে। আক্রমণের পরিসর এখনও অপ্রকাশিত, আর Critical server RCE-র বাস্তব ঝুঁকি প্রতিটি প্রতিষ্ঠানের exposure-এর ওপর নির্ভর করবে। পরবর্তী rollout সিদ্ধান্তে Microsoft-এর CVE ও KB revision, known-issue পরিবর্তন এবং নিজস্ব installation ও service telemetry একসঙ্গে দেখতে হবে।
আরও পড়ুন:
আমাদের নিউজলেটার নিন
সর্বশেষ Web3, AI ও ক্রিপ্টো সংবাদ সরাসরি আপনার ইনবক্সে পান।