آسیب‌پذیری کرنل لینوکس CVE-2026-98432؛ ضرورت محدودسازی دسترسی به سرورها و میزبان‌های PVM

آسیب‌پذیری کرنل لینوکس با شناسه CVE-2026-98432 در پردازش اتصال‌های شبکه رخ می‌دهد و می‌تواند موجب اختلال در کرنل یا فساد حافظه شود. همچنین Anthropic اجرای فرمان با دسترسی ریشه را در یک پیکربندی مشخص گزارش کرده است. توصیه عملی رادار آوید، بررسی وضعیت اصلاحیه و محدودسازی دسترسی‌های غیرضروری تا نصب و فعال‌شدن اصلاحیه معتبر است.

مدیران زیرساخت باید وضعیت سرورهای لینوکسی و میزبان‌های PVM را بررسی کنند و دسترسی از شبکه‌های نامطمئن به سرویس‌های مدیریتی و غیرعمومی را به مبدأها و مسیرهای ضروری محدود سازند. برای سامانه‌هایی که اصلاحیه سازگار آن‌ها منتشر شده است، نصب و تأیید فعال‌شدن اصلاحیه باید در اولویت قرار گیرد.

آسیب‌پذیری کرنل لینوکس CVE-2026-98432 چیست؟

این نقص در پردازش اتصال‌های TCP بر بستر IPv4 در کرنل لینوکس رخ می‌دهد. در شرایطی خاص، حافظه‌ای آزاد می‌شود که بخش دیگری از کرنل هنوز در حال استفاده از آن است. این خطا با عنوان استفاده از حافظه آزادشده یا Use After Free شناخته می‌شود و می‌تواند به اختلال در کرنل، از دسترس خارج‌شدن سرور یا فساد حافظه منجر شود.

امتیاز ثبت‌شده از سوی مرجع تخصیص‌دهنده این شناسه، در مقیاس CVSS 3.1 برابر با ۹٫۸ و در سطح بحرانی است؛ بااین‌حال، ارزیابی شدت نزد عرضه‌کنندگان مختلف یکسان نیست. برای تصمیم عملی، اطلاعیه عرضه‌کننده همان سیستم‌عامل یا محصول باید بررسی شود. [۷]

گزارش Anthropic درباره اجرای فرمان با دسترسی root

شرکت Anthropic در گزارش ۲۷ اکتبر ۲۰۲۶ اعلام کرد که در یک آزمایش پژوهشی، از این نقص برای اجرای فرمان با دسترسی ریشه یا root روی سروری دارای شنونده MPTCP استفاده کرده است. طبق این گزارش، اجرای حمله به حساب کاربری یا تعامل کاربر نیاز نداشت. این نتیجه، اجرای موفق حمله در یک پیکربندی مشخص را نشان می‌دهد و به‌تنهایی به معنای امکان تصرف همه سرورهای لینوکسی نیست.

MPTCP امکان استفاده از چند مسیر شبکه برای یک اتصال را فراهم می‌کند و استفاده از آن به پشتیبانی و نحوه عملکرد برنامه وابسته است. بااین‌حال، شرح عمومی آسیب‌پذیری به MPTCP محدود نشده است؛ بنابراین نبود این قابلیت یا غیرفعال‌کردن آن، به‌تنهایی اثبات نمی‌کند که نقص کرنل برطرف شده است.

محدودسازی دسترسی، احتمال رسیدن ترافیک مخرب به سرویس را کاهش می‌دهد؛ اما کد آسیب‌پذیر کرنل را اصلاح نمی‌کند.

وضعیت اصلاحیه آسیب‌پذیری کرنل لینوکس چگونه است؟

اصلاح این نقص در کرنل بالادستی انجام شده است، اما انتشار بسته قابل نصب برای هر توزیع یا محصول، زمان‌بندی جداگانه‌ای دارد. وجود اصلاحیه در کرنل بالادستی را نباید با آماده‌بودن بسته سازگار برای همه سامانه‌ها یکسان دانست. [۱]

در بازبینی منابع در ۸ آبان ۱۴۰۵، ردیاب Debian برای برخی شاخه‌ها بسته اصلاح‌شده نشان می‌داد. در مقابل، ردیاب Ubuntu برای تعدادی از بسته‌ها همچنان وضعیت آسیب‌پذیر و اصلاح در دست انجام داشت و اطلاعیه Red Hat نیز برای محصولات متأثر، وضعیت متفاوتی از انتشار اصلاحیه را گزارش می‌کرد. این اطلاعات باید پیش از اقدام، برای نسخه و بسته دقیق سامانه دوباره بررسی شود.

ملاک اقدام، نصب و فعال‌شدن اصلاحیه مناسب همان سامانه است. انتشار خبر، وجود بسته در مخزن یا حتی نصب بسته جدید، به‌تنهایی نشان نمی‌دهد که کرنل در حال اجرا اصلاح شده است. زمان راه‌اندازی مجدد یا روش پشتیبانی‌شده اعمال اصلاحیه باید متناسب با الزامات تداوم خدمت برنامه‌ریزی شود و نتیجه آن تأیید شود.

تا تکمیل به‌روزرسانی، چه اقداماتی انجام دهیم؟

اولویت عملی، کاهش تعداد مبدأهایی است که می‌توانند به سرویس‌های حساس متصل شوند. شبکه نامطمئن فقط اینترنت نیست؛ شبکه مهمان، شبکه عمومی کاربران، مسیرهای پیمانکاران، محیط آزمایش و ماشین‌های مجازی با سطح اعتماد پایین نیز باید در بازبینی دسترسی‌ها در نظر گرفته شوند.

دسترسی مستقیم به سرویس‌های مدیریتی را محدود کنید

پنل مدیریت، SSH و سایر سرویس‌های غیرعمومی سرورها و میزبان‌های PVM فقط از مبدأهای مشخص و موردنیاز قابل دسترس باشند. قواعد گسترده، مانند اجازه دسترسی از همه شبکه‌ها، را با حفظ مسیرهای ضروری مدیریت بازبینی کنید.

دسترسی شبکه‌های مختلف به مدیریت میزبان را بررسی کنید

دسترسی شبکه کاربران، مهمانان و ماشین‌های مجازی به مدیریت میزبان‌ها باید به نیاز عملیاتی محدود باشد. مسیرهای مدیریت، ذخیره‌سازی و ارتباط خوشه را نیز جداگانه بررسی کنید؛ تغییر در یک مسیر نباید بدون ارزیابی، ارتباط‌های ضروری مسیر دیگر را مختل کند.

دسترسی راه دور را از مسیر کنترل‌شده برقرار کنید

از راهکار پشتیبانی‌شده سازمان برای دسترسی راه دور یا درگاه مدیریتی استفاده کنید و مقصدها و سرویس‌های مجاز پشت آن را محدود نگه دارید. خود این درگاه نیز باید به‌روز باشد و دسترسی‌های آن به نیاز واقعی کاربران محدود شود.

سرویس‌های عمومی و اجزای داخلی را تفکیک کنید

برای خدماتی که باید در دسترس عموم بمانند، مسیر ورودی و دسترسی مستقیم به اجزای پشت آن را بازبینی کنید. بستن سرویس ضروری بدون طرح جایگزین می‌تواند تداوم خدمت را مختل کند؛ بنابراین هر تغییر باید متناسب با معماری و نیاز خدمت انجام شود.

سامانه‌های دارای شنونده MPTCP را زودتر بررسی کنید

وجود شنونده MPTCP در پیکربندی آزمایش‌شده Anthropic مطرح شده است؛ به همین دلیل، بررسی این سامانه‌ها در اولویت قرار می‌گیرد. هم‌زمان، پیگیری وضعیت اصلاحیه سایر سامانه‌های دارای کرنل آسیب‌پذیر را ادامه دهید. [۲]

اصلاحیه معتبر را نصب و فعال‌شدن آن را تأیید کنید

نسخه دقیق کرنل در حال اجرا و اطلاعیه امنیتی متناظر آن را ثبت کنید. اصلاحیه را از مسیر رسمی توزیع یا پشتیبانی محصول دریافت کنید و نصب آن را با برنامه آزمون، نگهداری و بازگشت متناسب با حساسیت سامانه انجام دهید.

احراز هویت برنامه، رمزنگاری ارتباط یا اسکن فایل، جای اصلاح نقصی را که در پردازش اتصال شبکه در کرنل رخ می‌دهد نمی‌گیرد. Red Hat در صفحه این آسیب‌پذیری، راهکار موقتی منطبق با معیارهای پشتیبانی خود معرفی نکرده است؛ بنابراین یک تنظیم MPTCP یا قاعده فایروال نباید بدون ارزیابی فنی، رفع قطعی نقص تلقی شود.

در محیط PVM، میزبان و مهمان را جداگانه بررسی کنید

در محیط PVM، وضعیت کرنل میزبان، گره‌های مدیریت و ماشین‌های مجازی لینوکسی باید جداگانه بررسی شود. ماشین مجازی کرنل مستقل خود را دارد؛ بنابراین به‌روزرسانی میزبان، کرنل مهمان را به‌روز نمی‌کند و به‌روزرسانی مهمان نیز جای اصلاح میزبان را نمی‌گیرد. در سرویس‌های کانتینری، وضعیت کرنل میزبان کانتینر اهمیت دارد.

• میزبان‌های PVM و گره‌های مدیریت: نسخه و ساخت محصول، کرنل در حال اجرا و وضعیت اصلاحیه سازگار با محصول را ثبت و بررسی کنید.
• ماشین‌های مجازی لینوکسی: وضعیت بسته کرنل و اصلاحیه را بر اساس توزیع نصب‌شده داخل هر ماشین بررسی کنید.
• میزبان‌های کانتینر: کرنل سامانه‌ای را بررسی کنید که کانتینرها روی آن اجرا می‌شوند؛ این سامانه ممکن است خود یک ماشین مجازی باشد.

تعیین اثرپذیری هر نسخه PVM به کرنل مورد استفاده، اصلاحیه‌های اعمال‌شده و پیکربندی همان نسخه وابسته است. مدیران این محیط‌ها باید وضعیت اصلاحیه سازگار با محصول را از مسیر رسمی پشتیبانی آوید پیگیری کنند. تا روشن‌شدن وضعیت و تکمیل اصلاح، محدودسازی دسترسی به سرویس‌های مدیریتی و غیرعمومی اقدامی احتیاطی است.

چک‌لیست بررسی اصلاحیه و دسترسی سرورها

برای پیگیری منظم، نتیجه بررسی هر سامانه را همراه با مسئول اقدام و زمان بازبینی ثبت کنید:

• نسخه و ساخت سیستم‌عامل یا محصول مشخص شده است.
• نسخه دقیق کرنل در حال اجرا ثبت شده است.
• وضعیت اثرپذیری با اطلاعیه رسمی همان عرضه‌کننده تطبیق داده شده است.
• مبدأهای دارای دسترسی به سرویس‌های مدیریتی و غیرعمومی بررسی شده‌اند.
• دسترسی‌های غیرضروری با حفظ مسیر مدیریت مجاز محدود شده‌اند.
• برای نصب اصلاحیه، آزمون و بازگشت برنامه مشخص وجود دارد.
• پس از نصب، فعال‌شدن اصلاحیه و وضعیت خدمات تأیید شده است.

پرسش‌های متداول درباره آسیب‌پذیری کرنل لینوکس

آیا همه سرورهای لینوکسی در معرض این آسیب‌پذیری هستند؟

نمی‌توان بدون بررسی نسخه، بسته کرنل و اصلاحیه‌های عرضه‌کننده چنین نتیجه‌ای گرفت. وضعیت هر سامانه باید با اطلاعیه رسمی مربوط به همان توزیع یا محصول تطبیق داده شود.

آیا غیرفعال‌کردن MPTCP برای رفع آسیب‌پذیری کافی است؟

خیر. MPTCP در پیکربندی آزمایش‌شده برای اجرای فرمان مطرح شده است، اما شرح عمومی نقص به آن محدود نیست. غیرفعال‌کردن این قابلیت به‌تنهایی اثبات نمی‌کند که آسیب‌پذیری کرنل برطرف شده است.

آیا نصب بسته جدید کرنل به معنی رفع نقص است؟

خیر. باید تأیید شود که اصلاحیه در کرنل در حال اجرا فعال شده است. این کار ممکن است به راه‌اندازی مجدد یا استفاده از روش پشتیبانی‌شده اعمال اصلاحیه نیاز داشته باشد.

آیا به‌روزرسانی میزبان PVM، ماشین‌های مجازی را هم اصلاح می‌کند؟

خیر. ماشین‌های مجازی کرنل مستقل دارند. وضعیت میزبان و هر مهمان لینوکسی باید جداگانه بررسی و در صورت نیاز اصلاح شود.

اقدام پیشنهادی رادار آوید

بررسی را با سه پرسش مشخص آغاز کنید: کدام کرنل اکنون در حال اجراست؟ چه مبدأهایی به سرویس‌های حساس دسترسی دارند؟ اصلاحیه مناسب این سامانه نصب و فعال شده است؟

کاهش دسترسی‌های غیرضروری را هم‌زمان با پیگیری اصلاحیه انجام دهید و اصل حداقل دسترسی را پس از به‌روزرسانی نیز حفظ کنید. در محیط PVM، وضعیت اصلاحیه باید با نسخه و ساخت محصول تطبیق داده شود تا اقدام امنیتی با الزامات پشتیبانی و تداوم خدمت سازگار باشد.