هشدار امنیتی: آسیب‌پذیری Root در Linux Kernel (CVE-2026-64531)

یک آسیب‌پذیری جدی در هسته لینوکس شناسایی شده است که می‌تواند به کاربران محلی با دسترسی محدود اجازه دهد کنترل کامل سیستم را به دست آورند. این نقص با شناسه CVE-2026-64531 و نام OVSwrap شناخته می‌شود و بخش کرنلی Open vSwitch را تحت تأثیر قرار می‌دهد.

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

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

این نقص با شناسه CVE-2026-64531 ثبت شده و پژوهشگر کشف‌کننده آن نام OVSwrap را برایش انتخاب کرده است. امتیاز شدت این آسیب‌پذیری ۷.۸ از ۱۰ اعلام شده که آن را در دسته آسیب‌پذیری‌های مهم قرار می‌دهد.

خلاصه آسیب‌پذیری OVSwrap

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

مهاجم ممکن است بتواند:

• اطلاعاتی از حافظه کرنل استخراج کند؛
• بخش‌هایی از حافظه کرنل را بخواند یا تغییر دهد؛
• دسترسی یک پردازش را به root تبدیل کند؛
• فایل‌های تنظیمات sudo را تغییر دهد؛
• یک خط فرمان با دسترسی کامل مدیریتی باز کند.

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

برای مثال، ممکن است مهاجم ابتدا یکی از وب‌سایت‌های یک سرور اشتراکی را هک کند و سپس از OVSwrap برای به دست گرفتن کنترل کل سرور استفاده کند.

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

این مشکل در بخش کرنلی Open vSwitch قرار دارد، نه در برنامه‌ای که در فضای کاربری اجرا می‌شود.

به زبان ساده، حتی اگر سرویس اصلی Open vSwitch روی سرور اجرا نشده باشد، ممکن است همچنان امکان دسترسی به کد آسیب‌پذیر وجود داشته باشد.

برای انجام حمله لازم نیست:

• یک شبکه مجازی Open vSwitch از قبل ساخته شده باشد؛
• سرویس ovs-vswitchd در حال اجرا باشد؛
• کاربر در سطح اصلی سیستم مجوز مدیریت شبکه داشته باشد.

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

مهاجم می‌تواند چنین محیطی را با فرمانی مشابه زیر بسازد:

unshare -Urn

این فرمان به‌تنهایی باعث روت شدن کاربر نمی‌شود، اما در سیستم‌های آسیب‌پذیر می‌تواند راه رسیدن به بخش معیوب Open vSwitch را باز کند.

نبودن Open vSwitch در خروجی lsmod کافی نیست

ممکن است مدیر سرور فرمان lsmod را اجرا کند و نام ماژول openvswitch را در خروجی نبیند. این موضوع لزوماً به معنای امن بودن سیستم نیست.

اگر ماژول Open vSwitch روی سیستم نصب شده باشد، کرنل می‌تواند هنگام نیاز آن را به‌صورت خودکار بارگذاری کند.

بنابراین، تنها بررسی اینکه ماژول در حال حاضر فعال است یا نه کافی نیست. باید مشخص شود که:

• آیا ماژول Open vSwitch روی سیستم نصب شده است؛
• آیا امکان بارگذاری خودکار آن وجود دارد؛
• آیا کرنل نصب‌شده اصلاحیه امنیتی را دریافت کرده است.

علت اصلی آسیب‌پذیری چیست؟

Open vSwitch برای مدیریت ترافیک شبکه مجموعه‌ای از دستورها یا Actionها را در حافظه کرنل ایجاد می‌کند.

اندازه این دستورها در بخشی از حافظه ثبت می‌شود که فقط می‌تواند عددی تا ۶۵٬۵۳۵ را نگه دارد.

در گذشته محدودیتی وجود داشت که اجازه نمی‌داد اندازه مجموعه دستورها بیش از ۳۲ کیلوبایت شود. این محدودیت به‌طور غیرمستقیم مانع فعال شدن نقص امنیتی می‌شد.

در مارس ۲۰۲۵ این محدودیت حذف شد، زیرا در بعضی زیرساخت‌های بزرگ باعث خطا و اختلال می‌شد. با حذف آن، یک مشکل قدیمی که حدود ۱۳ سال در کد وجود داشت قابل بهره‌برداری شد.

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

به این اتفاق سرریز یا Wraparound گفته می‌شود.

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

مهاجم چگونه به دسترسی روت می‌رسد؟

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

ابتدا یک آدرس مهم از حافظه کرنل را پیدا می‌کند. سپس بخش‌هایی از حافظه کرنل را می‌خواند و در مرحله بعد، اطلاعات مربوط به سطح دسترسی یک پردازش را تغییر می‌دهد.

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

پس از موفقیت حمله، مهاجم می‌تواند فایل‌های زیر را تغییر دهد:

/etc/sudoers
/etc/sudoers.d/

این فایل‌ها تعیین می‌کنند چه کاربرانی اجازه اجرای فرمان با دسترسی مدیریتی را دارند.

کد آزمایشی منتشرشده خطرناک است

برای این آسیب‌پذیری یک کد اثبات مفهوم یا PoC عمومی منتشر شده است.

PoC معمولاً برای اثبات عملی بودن یک آسیب‌پذیری ساخته می‌شود، اما کد منتشرشده برای OVSwrap صرفاً یک آزمایش بی‌خطر نیست. پژوهشگر آن را به‌صراحت تخریبی معرفی کرده است.

این کد پس از اجرا:

• اطلاعات دسترسی یک پردازش واقعی را در کرنل تغییر می‌دهد؛
• فایل‌های sudo را دست‌کاری می‌کند؛
• یک پوسته با دسترسی root باز می‌کند؛
• بعضی پردازش‌ها و اطلاعات Open vSwitch را در حافظه باقی می‌گذارد.

باقی ماندن این اطلاعات عمدی است، زیرا پاک‌سازی آن‌ها ممکن است باعث کرش یا ناپایداری سیستم شود.

به همین دلیل، اجرای این PoC روی سرور اصلی، سیستم کاری یا محیط تولیدی به‌هیچ‌وجه توصیه نمی‌شود.

چرا انتشار PoC اهمیت دارد؟

مخزن عمومی این اکسپلویت شامل اطلاعات آماده برای حدود ۸۰۰ نسخه دقیق از کرنل‌های x86-64 است.

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

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

البته موفقیت حمله همچنان به پیکربندی سیستم و وجود قابلیت‌های مورد نیاز بستگی دارد.

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

پژوهشگر اعلام کرده است که توانسته این حمله را روی پیکربندی پیش‌فرض چندین توزیع اجرا کند؛ از جمله:

• AlmaLinux 9 و 10
• Debian 12 و 13
• Rocky Linux 9 و 10
• CentOS Stream 9 و 10
• Amazon Linux 2023
• Ubuntu 22.04
• Fedora 42 تا 44
• Linux Mint 22.3
• Kali Linux 2026.1
• Arch Linux
• Alpine Linux
• Gentoo
• NixOS
• Pop!_OS
• openSUSE Tumbleweed

این فهرست کامل نیست. نبودن نام یک توزیع در آن به معنای ایمن بودن آن نیست.

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

وضعیت نسخه‌های مختلف اوبونتو

در آزمایش‌های انجام‌شده روی Ubuntu 24.04، تنظیمات AppArmor در ابتدا اجازه ساخت مستقیم محیط مورد نیاز حمله را نمی‌داد.

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

در Ubuntu 26.04، مسیر حمله برای کاربران عادی در تنظیمات پیش‌فرض مسدود بود. ولی زمانی که محدودیت AppArmor مربوط به User Namespace غیرفعال شد، حمله دوباره امکان‌پذیر شد.

نسخه‌های آزمایش‌شده زیر از این مسیر مشخص قابل بهره‌برداری نبودند:

• Ubuntu 20.04
• Debian 11
• Rocky Linux 8
• Amazon Linux 2

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

نسخه‌های اصلاح‌شده کرنل

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

با این حال، این شماره‌ها برای همه توزیع‌ها قابل استفاده نیستند.

توزیع‌هایی مانند Debian، Ubuntu، AlmaLinux و Rocky Linux معمولا اصلاحیه‌های امنیتی را روی کرنل اختصاصی خود اعمال می‌کنند. به همین دلیل، ممکن است شماره کرنل پایین‌تر باشد ولی اصلاحیه در آن وجود داشته باشد.

بهترین کار مراجعه به اطلاعیه امنیتی رسمی سازنده توزیع و نصب آخرین کرنل ارائه‌شده از مخازن رسمی است.

راهکار اصلی: نصب کرنل اصلاح‌شده

مطمئن‌ترین راه مقابله با OVSwrap، نصب به‌روزرسانی امنیتی توزیع لینوکس است.

پس از نصب کرنل جدید، معمولاً باید سرور راه‌اندازی مجدد شود؛ زیرا تا قبل از ریبوت، سیستم همچنان از کرنل قدیمی موجود در حافظه استفاده می‌کند.

مدیر سرور باید بعد از راه‌اندازی مجدد بررسی کند که سیستم واقعاً با نسخه جدید کرنل بالا آمده باشد.

راهکار موقت در صورت عدم نیاز به Open vSwitch

اگر Open vSwitch در سرور استفاده نمی‌شود، می‌توان به‌صورت موقت از بارگذاری ماژول آن جلوگیری کرد:

echo 'install openvswitch /bin/false' > /etc/modprobe.d/ovswrap.conf

این تنظیم مانع بارگذاری‌های بعدی ماژول می‌شود.

اما اگر ماژول از قبل در حافظه قرار گرفته باشد، این فرمان آن را حذف نمی‌کند. در چنین شرایطی باید ماژول با احتیاط خارج شود یا سیستم راه‌اندازی مجدد گردد.

پیش از این کار باید مطمئن شد که سرویس‌های شبکه، ماشین‌های مجازی یا زیرساخت ابری به Open vSwitch وابسته نیستند. حذف ناگهانی این ماژول ممکن است ارتباط شبکه سرور را قطع کند.

غیرفعال کردن User Namespace

یک راهکار موقت دیگر، غیرفعال کردن ساخت User Namespace توسط کاربران عادی است.

این کار مسیر حمله برای یک کاربر محلی معمولی را می‌بندد، اما محافظت کامل ایجاد نمی‌کند.

برای نمونه، یک کانتینر یا پردازشی که از قبل مجوز CAP_NET_ADMIN دارد ممکن است همچنان بتواند به بخش آسیب‌پذیر دسترسی پیدا کند.

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

چه سرورهایی بیشتر در خطر هستند؟

خطر این آسیب‌پذیری در سرورهایی بیشتر است که چند کاربر یا چند سرویس غیرقابل اعتماد را هم‌زمان میزبانی می‌کنند.

سرورهای زیر باید موضوع را جدی‌تر بررسی کنند:

• سرورهای میزبانی اشتراکی؛
• زیرساخت‌های ابری و مجازی‌سازی؛
• سرورهای دارای کانتینر؛
• محیط‌های اجرای کد کاربران؛
• سرورهای دانشگاهی یا چندکاربره؛
• سامانه‌های CI/CD؛
• سرورهایی که چند مشتری مستقل دارند.

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

مدیران سرور چه کاری انجام دهند؟

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

همچنین لازم است بررسی شود که آیا Open vSwitch روی سیستم نصب یا فعال است. در صورت عدم نیاز می‌توان بارگذاری آن را موقتاً مسدود کرد.

مدیران بهتر است تغییرات مشکوک در فایل‌های /etc/sudoers و /etc/sudoers.d را نیز بررسی کنند. اجرای غیرعادی فرمان‌هایی مانند unshare یا ایجاد محیط‌های شبکه جدید توسط کاربران ناشناس نیز می‌تواند نیازمند بررسی بیشتر باشد.

جمع‌بندی

آسیب‌پذیری CVE-2026-64531 یا OVSwrap یک نقص افزایش سطح دسترسی در کرنل لینوکس است.

این مشکل به کاربری که از قبل به سیستم دسترسی محدود دارد اجازه می‌دهد در بعضی پیکربندی‌ها حافظه کرنل را دست‌کاری کرده و به دسترسی root برسد.

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

نصب کرنل اصلاح‌شده مهم‌ترین اقدام دفاعی است. مسدود کردن Open vSwitch یا محدود کردن User Namespace فقط باید به‌عنوان راهکار موقت تا زمان نصب به‌روزرسانی استفاده شود.