ژرف‌بان دو رخنهٔ مورد سوءاستفاده در ویندوز؛ اولویت امروزِ واحد مالی
مایکروسافت برای دو آسیب‌پذیری ویندوز، سوءاستفادهٔ واقعی را ثبت کرده و CISA نیز هر دو را به فهرست خود افزوده است. تصمیم امروزِ شرکت‌های دارای نسخهٔ آسیب‌پذیر: تعیین اولویت اصلاح بر اساس دسترسی مالی و تأیید بازگشت عملیات، نه اتکا به امتیاز شدت یا درصد کلی نصب.
چه چیزی در ۱۷ شهریور تغییر کرد؟ تأیید سوءاستفاده، نه فقط انتشار وصله
در انتشار امنیتی ۸ سپتامبر، برابر با ۱۷ شهریور ۱۴۰۵، مایکروسافت وضعیت دو آسیب‌پذیری ویندوز را «سوءاستفاده‌شده» ثبت کرد: CVE-2026-81963 در Windows Update Stack و CVE-2026-85880 در Windows ALPC. برای هر دو اقدام مشتری لازم اعلام شده است. CISA نیز همان روز هر دو شناسه را به فهرست آسیب‌پذیری‌های شناخته‌شدهٔ مورد سوءاستفاده افزود. بنابراین خبر تازه، وجود سند بهره‌برداری واقعی همراه با مسیر اصلاح رسمی است؛ نه صرفاً هشدار دربارهٔ یک احتمال نظری. [۱] [۴]
مایکروسافت شدت هر دو را «مهم» و امتیاز پایهٔ CVSS نسخهٔ ۳٫۱ را ۷٫۸ از ۱۰ درج کرده است. این امتیاز، درصد احتمال حمله یا برآورد خسارت ریالی نیست. برداشت ژرف‌بان برای جلسهٔ امروز مدیر مالی و مسئول فناوری اطلاعات این است: صف اصلاح را نمی‌توان فقط با مرتب‌کردن امتیازها بست. یک رایانهٔ مشمول با دسترسی حساس مالی و ضعفِ واقعاً مورد سوءاستفاده، نیازمند تصمیم روشن دربارهٔ زمان اصلاح است؛ حتی اگر بالاترین عدد جدول را نداشته باشد. [۲] [۳]
پنجرهٔ این نسخه از ساعت ۰۷:۰۲ روز ۱۷ شهریور تا ۰۷:۰۲ روز ۱۸ شهریور به وقت تهران است. تاریخ انتشار اسناد مایکروسافت و زمان انتشار نسخهٔ ۱۷ شهریور فهرست CISA در این بازه قرار می‌گیرند؛ اما تاریخ شروع حملات از این اسناد معلوم نمی‌شود. در رکوردهای CISA، استفاده در کارزار باج‌افزاری «نامعلوم» ثبت شده است. این عنوان نه اثبات باج‌افزار است و نه اثبات نبود آن؛ همچنین داده‌ای دربارهٔ شمار قربانیان ایرانی به دست نمی‌دهد. [۱] [۴]
دو رخنه چه امکانی می‌دهند و چه چیزی را ثابت نمی‌کنند؟
توضیح مایکروسافت برای رخنهٔ Update Stack، اشکال در رسیدگی به پیوند پیش از دسترسی به فایل است که به مهاجم دارای دسترسی اجازهٔ ارتقای محلی سطح اختیار می‌دهد. پیامد موفقیت، رسیدن به سطح SYSTEM عنوان شده است. برای مخاطب مالی، نکتهٔ تعیین‌کننده افزایش اختیار روی همان دستگاه است؛ متن منبع نمی‌گوید هر فرد ناشناس می‌تواند صرفاً از اینترنت، بدون دسترسی قبلی، وارد رایانه شود. این مرز باید در گزارش ریسک داخلی حفظ شود. [۲]
رخنهٔ ALPC نیز ارتقای دسترسی محلی است. در پرسش‌وپاسخ رسمی، شرطی مشخص آمده: مهاجمی که بتواند در محیط کم‌اختیار AppContainer کد اجرا کند، می‌تواند از محدودیت آن محیط خارج شود و سطح اختیار را افزایش دهد؛ تعامل اضافی کاربر لازم نیست. سطح SYSTEM برای این مورد هم ذکر شده است. «بدون تعامل اضافی» را نباید به «بدون هیچ پیش‌شرط» ترجمه کرد. در مقابل، محلی‌بودن ضعف هم به‌خودی‌خود دلیل کم‌اهمیت‌دانستن آن نیست، چون وضعیت سوءاستفاده تأیید شده است. [۳] [۴]
تفسیر عملی ژرف‌بان، سنجش پیامد بر اساس کار واقعی دستگاه است: رایانه‌ای که فایل حقوق آماده می‌کند، به اسناد حسابداری دسترسی دارد یا برای تأیید پرداخت استفاده می‌شود، صرفاً یک شماره در فهرست تجهیزات نیست. بااین‌حال، از رسیدن بالقوه به SYSTEM نمی‌توان وقوع سرقت وجه، تغییر سند یا دسترسی قطعی به تمام سامانه‌های شرکت را نتیجه گرفت. آن پیامدها به اتصال‌ها و مجوزهای همان محیط وابسته‌اند و برای ادعای وقوع، شواهد جداگانه لازم است.
«ویندوز داریم» کافی نیست؛ نسخه و حق دریافت اصلاح را تطبیق دهید
در فهرست مایکروسافت، رخنهٔ Update Stack شامل نسخه‌های مشخص ویندوز ۱۱ و Windows Server 2025 است؛ فهرست ALPC نسخه‌های مشخص ویندوز ۱۰ و چند نسل Windows Server را در بر می‌گیرد. این دو دامنه یکسان نیستند. دادهٔ رسمی برای محصول و معماری مربوط، بستهٔ اصلاح و نسخهٔ ساخت هدف را مشخص می‌کند؛ در ردیف‌های به‌روزرسانی این دو مورد، راه‌اندازی مجدد نیز لازم درج شده است. پس نام کلی سیستم‌عامل یا اعلام دانلود بسته، گواه بسته‌شدن کار نیست. [۱]
برای نمونه، صفحهٔ رسمی بستهٔ KB5122878 مورخ ۸ سپتامبر، ویندوز ۱۰ تحت ESU، نسخهٔ Enterprise LTSC 2021 و نسخهٔ IoT Enterprise LTSC 2021 را نام می‌برد. وجود این صفحه به معنای تحویل رایگان اصلاح به هر رایانهٔ ویندوز ۱۰ نیست. جزئیات پیش‌نیاز نصب و کانال دریافت نیز در همان سند آمده است. نتیجه برای بودجهٔ شرکت: وضعیت پشتیبانی و مسیر مجاز دریافت اصلاح باید روی دارایی واقعی تأیید شود؛ صرف درج نام ویندوز ۱۰ در موجودی، پاسخ کافی نیست. [۵]
پیشنهاد ژرف‌بان این است که خروجی بررسی فناوری اطلاعات، به‌جای عبارت کلی «به‌روز شد»، برای هر دستگاه حساس چهار مدرک داشته باشد: نسخه و معماری شناسایی‌شده، بسته یا نسخهٔ ساخت اصلاح‌شده، تأیید نصب و وضعیت راه‌اندازی مجدد. دستگاهی که فعلاً اصلاح دریافت نمی‌کند باید با علت مشخص، مسئول تصمیم و تاریخ بازبینی ثبت شود. این خبر دسترس‌پذیری یک برنامهٔ پشتیبانی برای هر شرکت ایرانی را تضمین نمی‌کند و نسخهٔ واحدی برای خرید مجوز یا مهاجرت همهٔ سامانه‌ها نمی‌پیچد.
تصمیم مالی امروز: توقفِ برنامه‌ریزی‌شده و مدرکِ بازگشت کار
راهنمای NIST SP 800-40r4، منتشرشده در آوریل ۲۰۲۲، مدیریت وصله را فرایندی از شناسایی و اولویت‌بندی تا دریافت، نصب و تأیید نصب تعریف می‌کند و آن را بخشی از نگهداری پیشگیرانهٔ فناوری می‌داند. این منبع قدیمی، زمینهٔ مدیریتی است و خبر تازه یا بخشنامهٔ ایرانی محسوب نمی‌شود. برداشت ژرف‌بان از این چارچوب برای رویداد امروز: مدیر مالی مالک انتخاب بستهٔ فنی نیست، اما باید دربارهٔ توقف خدمت، کار جایگزین و پذیرش بازگشت عملیات پاسخ روشن داشته باشد. [۶]
اقدام پیشنهادی، یک فهرست کوتاه مشترک با مسئول فناوری اطلاعات است: ابتدا دستگاه‌های مشمول را با دسترسی به پرداخت، حقوق، اسناد و مدیریت سامانه‌ها مشخص کنید؛ سپس نزدیک‌ترین بازهٔ قابل اجرا برای اصلاح و آزمون را تعیین کنید. پیش از توقف، مسئول پشتیبان‌گیری و امکان بازیابی، مسئول نصب و فرد تأییدکنندهٔ کار مالی معلوم باشند. تأیید بازگشت کار می‌تواند شامل ورود مجاز، بازکردن گزارش و اجرای سناریوی آزمایشیِ بدون انتقال واقعی وجه باشد؛ آزمون نباید خود یک پرداخت تکراری ایجاد کند.
شاخص گزارش نیز باید به تصمیم کمک کند. در یک مثال کاملاً فرضی، اگر ۹۵ رایانه از ۱۰۰ رایانه اصلاح شوند اما پنج دستگاه باقی‌مانده ابزار اصلی پرداخت باشند، عدد ۹۵ درصد به‌تنهایی اطمینان معناداری دربارهٔ عملیات پرداخت نمی‌دهد. ژرف‌بان پیشنهاد می‌کند کنار درصد کل، تعداد دستگاه‌های حساسِ مشمول که نصب و بازآزمایی آنها تأیید نشده گزارش شود. این تفکیک، هزینهٔ توقف برنامه‌ریزی‌شده و علت تعویق را قابل گفت‌وگو می‌کند؛ بدون اینکه خسارت احتمالیِ نامعلوم به عدد ساختگی تبدیل شود.
چه چیزی را بعد از نصب رصد کنیم؟
یک ملاحظهٔ واقعی، سازگاری به‌روزرسانی با محیط شرکت است. صفحهٔ KB5122878 در زمان بررسی می‌گوید مایکروسافت فعلاً از مشکل شناخته‌شده‌ای برای این بسته آگاه نیست. این عبارت محدود به همان بسته و زمان گزارش است؛ تضمین سازگاری نرم‌افزار حسابداری، ابزار بانکی یا تنظیمات اختصاصی شرکت شما نیست. پیشنهاد ژرف‌بان، آزمون متناسب و کوتاه با مسئول مشخص است، نه حذف آزمون و نه تبدیل نگرانی مبهم به تعویق بدون موعد. [۵]
در رصد بعدی، سه تغییر ارزش پیگیری دارند: اصلاح فهرست محصولات و راهنمای نصب مایکروسافت، اعلام مشکل تازه در بستهٔ مرتبط، و تعیین تکلیف دستگاه‌های حساسِ باقی‌مانده در فهرست استثناها. نصب وصله به‌تنهایی سندی دربارهٔ نبود نفوذ پیشین نیست؛ اگر نشانهٔ مستقلی از رخداد وجود دارد، نباید آن را فقط با عنوان «به‌روزرسانی انجام شد» مختومه کرد. این نتیجه‌گیری احتیاطی ژرف‌بان است، نه ادعای کشف رخداد در سازمانی مشخص.
شش سند این نسخه از سه مرجع می‌آیند: مایکروسافت برای شرح فنی و اصلاح، CISA برای ثبت سوءاستفادهٔ شناخته‌شده، و NIST برای زمینهٔ نگهداری. چهار سند مایکروسافت چهار تأیید مستقل نیستند و هیچ‌یک ممیزی امنیت شرکت ایرانی محسوب نمی‌شوند. تصمیم قابل دفاع امروز، تعیین تکلیف رایانه‌های واقعاً مشمول و حساس با مدرک اجرای اصلاح است. این گزارش راهنمای اولویت‌گذاری مدیریتی است؛ ارزیابی فنی همان محیط و رسیدگی مستقل به نشانه‌های رخداد را جایگزین نمی‌کند.
منابع مستقیم
- دادهٔ رسمی انتشار امنیتی سپتامبر؛ وضعیت سوءاستفاده، محصولات و بسته‌های اصلاح Microsoft Security Response Center · 2026-09-08
- CVE-2026-81963؛ ارتقای دسترسی در Windows Update Stack Microsoft Security Response Center · 2026-09-08
- CVE-2026-85880؛ ارتقای دسترسی در Windows ALPC Microsoft Security Response Center · 2026-09-08
- فهرست رسمی KEV؛ دو رکورد افزوده‌شده در ۸ سپتامبر ۲۰۲۶ CISA · 2026-09-08
- KB5122878؛ دامنهٔ پشتیبانی ویندوز ۱۰، دریافت و مشکلات شناخته‌شده Microsoft Support · 2026-09-08
- NIST SP 800-40r4؛ زمینهٔ قدیمیِ مدیریت وصله به‌عنوان نگهداری پیشگیرانه NIST · 2022-04-06
تحلیل‌های مرتبط
مطالب هم‌موضوع که همین تصمیم را از زاویهٔ دیگری کامل می‌کنند.
نرم‌افزار حسابداری لایسنس‌دار یا کرک‌شده؟ راهنمای امنیت و تداوم
نسخه کرک‌شده فقط یک اختلاف قیمت نیست؛ زنجیره اعتماد کد، مسیر اصلاح آسیب‌پذیری و امکان بازیابی دفتر مالی را نامعلوم می‌کند. نسخه مجاز هم بدون کنترل خودکار امن نیست.
خواندن گزارش
حسابداری ابری برای چه کسب‌وکاری مناسب است؟ راهنمای انتخاب و پشتیبان
ابر می‌تواند راه‌اندازی، دسترسی و نگهداری را ساده‌تر کند، اما اینترنت، قرارداد، مسئولیت امنیت و خروج داده را حذف نمی‌کند. تصمیم درست از فرایند حیاتی، تحمل توقف و آزمون بازیابی شروع می‌شود.
خواندن گزارش
ثبت‌نام و ورود سامانه مؤدیان؛ راهنمای کنترل دسترسی شرکت
ورود موفق به یک صفحه پایان ثبت‌نام نیست. شرکت باید پرونده فعال، کارپوشه درست، روش ارسال، امضاکننده مجاز، نگهداری امن کلید و جانشین عملیاتی را به یک زنجیره قابل آزمون تبدیل کند.
خواندن گزارش
سامانه گزارش سایبری اروپا راه افتاد؛ پاسخ فروشنده، رفع مشکل نیست
آژانس امنیت سایبری اروپا دیروز نسخه اولیه سامانه گزارش‌دهی قانون تاب‌آوری سایبری را راه‌اندازی کرد. خبر برای مدیر مالی، وعده امنیت بی‌نقص نیست: زمان اعلام رخداد، زمان اصلاح و زمان بازگشت عملیات باید در قرارداد فروشنده از هم جدا باشند؛ شمول مقررات اروپا نیز نیازمند بررسی مستقل است.
خواندن گزارش
اعلام اصلاح بیش از ۴۰۰ آسیب‌پذیری جاوا؛ مدرک نصب در شرکت کجاست؟
دو شرکت از اصلاح بیش از ۴۰۰ آسیب‌پذیری خبر داده‌اند، اما این عدد وضعیت نرم‌افزار شرکت شما را مشخص نمی‌کند. مسئله امروز مدیر مالی، اتصال اطلاعیه فروشنده به نسخه نصب‌شده، آزمون عملیات و مسئول پذیرش تغییر است.
خواندن گزارش
پروندهٔ EvilTokens؛ ایمیل آشنا مجوز تغییر حساب پرداخت نیست
مایکروسافت و شرکایش از اختلال در سرویسی خبر داده‌اند که ایمیل‌های سرقت‌شده را برای یافتن فرصت تقلب مالی تحلیل می‌کرد. برای واحد مالی، نقطه کنترل فوری تغییر حساب ذی‌نفع است: تأیید را بیرون از همان رشته ایمیل بگیرید.
خواندن گزارشخلاصه را سریع ببینید؛ گزارش کامل را با یک لمس باز کنید
هر پست با تصویر اختصاصی، دو دلیل اهمیت، یک اقدام مدیریتی، یک مورد قابل رصد و مسیر مستقیم به متن کامل و منابع منتشر می‌شود.