وقتی صحبت از امنیت زیرساخت و سرورهای مجازی به میان میآید، هیچ خبری به اندازه کشف یک حفره امنیتی قدیمی در قلب سیستمعامل نمیتواند مدیران سرور را غافلگیر کند. به تازگی یک آسیب پذیری لینوکس با شناسه CVE-2026-74580 (ملقب به Vghost) افشا شده که نزدیک به یک دهه در کدهای کرنل پنهان مانده بود. این نقص امنیتی که در زیرسیستم vhost قرار دارد، به یک کاربر محلی و بدون دسترسی خاص اجازه میدهد تا حافظه کرنل را به دلخواه خود بخواند، در آن بنویسد و در نهایت دسترسی کامل Root را روی سرور به دست بگیرد. خطرناکتر اینکه در برخی سناریوهای مجازیسازی، این باگ به ماشین مجازی (Guest) اجازه میدهد از محیط ایزوله خود فرار کرده و کنترل پردازش میزبان (Host) را در دست بگیرد.
آسیب پذیری لینوکس CVE-2026-74580 (Vghost) دقیقاً چیست؟
این آسیب پذیری هسته لینوکس توسط تیم تحقیقاتی Tencent Zhuque Lab و با کمک سیستم هوش مصنوعی چندعاملی آنها به نام Corvus AI شناسایی شده است. زیرسیستم vhost در واقع بخشی از کرنل است که وظیفه شتابدهی به ترافیک شبکه و عملیات ورودی/خروجی (I/O) را برای ماشینهای مجازی (KVM/QEMU) و کانتینرها بر عهده دارد. کاربران محلی معمولاً از طریق نودهای دستگاه مانند /dev/vhost-net یا /dev/vhost-vsock با این بخش تعامل میکنند.
نکته نگرانکننده درباره آسیب پذیری CVE-2026-74580، قطعی بودن (Deterministic) اکسپلویت آن است. برخلاف بسیاری از باگهای حافظه که مهاجم برای بهرهبرداری از آنها نیازمند تکنیکهای پیچیده چیدمان حافظه (Memory Grooming) یا شانس و زمانبندی دقیق (Race Condition) است، در اینجا مهاجم میتواند بسیار مستقیم و پایدار، مکانیزم امنیتی KASLR را دور بزند و سطح دسترسی خود را روی سرور به Root ارتقا دهد.
کالبدشکافی فنی: این باگ لینوکس چطور کار میکند؟
ریشه اصلی این آسیب پذیری کرنل لینوکس به نحوه مدیریت کش (Cache) در نگاشتهای حافظه برمیگردد. زیرسیستم vhost برای افزایش سرعت، یک کش کوچک از نگاشتهای حافظه مربوط به هر حلقه مجازی (Virtual Ring) و صفهای اشتراکی نگه میدارد. وقتی درخواستی با این کش تطابق پیدا کند (Cache Hit)، کرنل فرض را بر این میگذارد که محدوده حافظه قبلاً بررسی و تایید شده است.
مشکل دقیقاً زمانی رخ میدهد که دستورات VHOST_SET_VRING_ADDR یا VHOST_SET_VRING_NUM آدرسها یا اندازه حلقه را در حالی که صف (Queue) فعال است تغییر میدهند. در حالتی که یک Device-IOTLB متصل باشد، کرنل آدرسهای جدید را بدون بررسی فوری قبول میکند و اعتبارسنجی را به مرحله بعد موکول میکند. اما چون کش قبلاً پر شده است، آن بررسی بعدی هرگز اجرا نمیشود! در نتیجه، vhost به ترجمه آدرسهای جدید با استفاده از نگاشت قدیمی ادامه میدهد و کرنل بدون بررسی محدوده (Bounds Check)، دادهها را خارج از فضای مجاز میخواند یا مینویسد.
چرا این حفره امنیتی ۹ سال پنهان ماند؟
جالب است بدانید که این باگ لینوکس حاصل ترکیب دو تغییر کاملاً منطقی در طول زمان بوده است و به همین دلیل سالها از چشم توسعهدهندگان دور مانده بود:
- تغییر اول در سال ۲۰۱۷ (کرنل ۴.۱۱): مکانیزم کش و میانبر مربوط به آن برای بهبود کارایی به کدهای کرنل اضافه شد.
- تغییر دوم در سال ۲۰۲۰ (کرنل ۵.۹): فرآیند بررسی آدرسها از داخل دستور اصلی خارج شد و به مرحله بعد منتقل گردید؛ تغییری که عملاً سد دفاعی در برابر ترجمههای منقضیشده کش را از بین برد.
دو سناریوی حمله: از ارتقای دسترسی تا فرار از ماشین مجازی (VM Escape)
محققان امنیتی دو مسیر حمله کاملاً عملیاتی را برای این آسیب پذیری لینوکس اثبات کردهاند که هر کدام ریسک متفاوتی را به زیرساخت تحمیل میکنند:
- سناریوی اول (ارتقای دسترسی محلی به Root): در سیستمهایی که دسترسی به نودهای
vhostباز است، هر کاربر عادی میتواند با فراخوانی این باگ، هر آدرسی در کرنل را بخواند یا بازنویسی کند و بلافاصله به کاربر Root تبدیل شود. - سناریوی دوم (فرار از Guest به Host): این سناریو کمی خاصتر اما بسیار خطرناکتر است. اگر دستگاه
virtioیک ماشین مجازی پشت یک IOMMU مجازی با قابلیتiommu_platformفعال قرار گرفته باشد وvhostدر مد Device-IOTLB اجرا شود، یک ماشین مجازی غیرقابلاعتماد میتواند کرنل میزبان را مجبور به نوشتن خارج از محدوده در پردازش QEMU روی سرور اصلی کند. از این طریق، مهاجم میتواند یک اشارهگر تابع (Function Pointer) را در QEMU بازنویسی کرده و اجرای کد را روی سرور مادر (Host) در دست بگیرد.
کدام نسخهها و توزیعها در معرض خطر هستند؟
این آسیب پذیری هسته لینوکس تمام نسخههای کرنل از 4.11 تا 7.2-rc4 را تحت تاثیر قرار میدهد. تیم کاشف باگ موفق شده زنجیره کامل دسترسی Root را روی ۵ توزیع پرکاربرد زیر به صورت عملی اجرا کند:
- Ubuntu 26.04 (و نسخههای ۲۲.۰۴ و ۲۴.۰۴)
- RHEL 9.8 (رد هت)
- Amazon Linux 2023
- Microsoft Azure Linux 3.0
- Oracle Linux 10.2
در توزیع اوبونتو، دسترسی به نود دستگاه به گروه kvm محدود شده بود، بنابراین مهاجم برای شروع حمله باید عضو این گروه باشد. اما در چهار توزیع دیگر، مجوز دسترسی به این نود روی 0666 (قابل خواندن و نوشتن برای همه کاربران) تنظیم شده بود که کار را برای هر کاربر محلی بسیار ساده میکرد. به همین دلیل، تیم CVE کرنل به دلیل شکستن مرز امنیتی بین Guest و Host، امتیاز خطر 8.8 (High) را به آن اختصاص داده است.
راهکار عملیاتی و نحوه پچ کردن آسیب پذیری CVE-2026-74580
وصله امنیتی این باگ (با شناسه کامیت de845981da67) به گونهای طراحی شده که هر زمان حلقه مجازی (Ring) مجدداً پیکربندی شود، کش به صورت کامل پاکسازی میشود. اگر مدیریت سرورهای لینوکسی را بر عهده دارید، مطمئن شوید که کرنل سیستم خود را حداقل به یکی از نسخههای پایدار زیر (یا پچهای معادل توزیع خودتان) ارتقا داده و سرور را ریبوت کنید:
- شاخه 5.10.y: نسخه 5.10.265 و بالاتر
- شاخه 5.15.y: نسخه 5.15.216 و بالاتر
- شاخه 6.1.y: نسخه 6.1.183 و بالاتر
- شاخه 6.6.y: نسخه 6.6.152 و بالاتر
- شاخه 6.12.y: نسخه 6.12.104 و بالاتر
- شاخه 6.18.y: نسخه 6.18.45 و بالاتر
- شاخه 7.1.y و 7.2: نسخههای 7.1.9 و 7.2
اقدام فوری و موقت (در صورت عدم امکان ریبوت سرور)
اگر روی سرورهای عملیاتی خود فعلاً امکان آپدیت کرنل و ریبوت را ندارید، برای جلوگیری از ارتقای سطح دسترسی کاربران محلی باید فوراً دسترسی عمومی (World Access) به نودهای vhost را ببندید و آن را فقط به سرویسهای مجازیسازی مورد اعتماد محدود کنید. برای بررسی و محدود کردن دسترسیها میتوانید از دستورات زیر استفاده کنید:
# بررسی وضعیت فعلی دسترسی نودهای vhost
ls -l /dev/vhost-net /dev/vhost-vsock
# حذف دسترسی عمومی (Other) و محدود کردن به مالک و گروه مجاز
sudo chmod 0660 /dev/vhost-net /dev/vhost-vsock
sudo chown root:kvm /dev/vhost-net /dev/vhost-vsockالبته توجه داشته باشید که این محدودسازی فقط جلوی سناریوی اول (ارتقای دسترسی کاربر محلی) را میگیرد. برای جلوگیری از سناریوی فرار از ماشین مجازی (Guest-to-Host Escape)، هیچ راهکار موقتی وجود ندارد و تنها راه ایمنسازی زیرساخت، نصب کرنل پچشده است.
توصیه نهایی برای مدیران سرور و دیتاسنتر
کشف آسیب پذیری لینوکس CVE-2026-74580 توسط هوش مصنوعی نشان میدهد که سرعت پیدا شدن باگهای عمیق و قدیمی در کرنل به شدت بالا رفته است. اگرچه هنوز گزارشی از سوءاستفاده عمومی از باگ Vghost در دنیای واقعی منتشر نشده، اما با توجه به انتشار جزئیات فنی و کدهای اثبات مفهوم (PoC)، تعلل در آپدیت سرورها ریسک بزرگی است. پیشنهاد میکنیم همین امروز وضعیت دسترسی فایلهای /dev/vhost-* را روی سرورهای خود بررسی کرده و برنامه بهروزرسانی کرنل را در اولویت قرار دهید.














