نقص بحرانی با امتیاز ۱۰ در LXD و MicroCloud؛ جعل هویت کلاینت مورد اعتماد بدون داشتن کلید خصوصی
اخبار داغ فناوری اطلاعات و امنیت شبکهکنونیکال وصله CVE-2026-112816 را منتشر کرد؛ بدون شواهدی از بهره‌برداری فعال
یک نقص بحرانی در LXD و MicroCloud (محصولات شرکت کنونیکال) به مهاجم اجازه می‌داد بدون در اختیار داشتن کلید خصوصی یک کلاینت مورد اعتماد، به‌جای آن کلاینت وارد سیستم شود. برای این کار، مهاجم باید از طریق شبکه به API مبتنی بر HTTPS سرویس دسترسی داشته باشد و گواهی عمومی همان کلاینت مورد اعتماد را در اختیار داشته باشد.
چه پیامدی دارد؟
پس از ورود، مهاجم به‌جای آن کلاینت عمل می‌کند و به خوشه (Cluster) و ماشین‌های مجازی آن دسترسی پیدا می‌کند. اگر حساب جعل‌شده دارای امتیاز بالا باشد، کنونیکال هشدار داده مهاجم می‌تواند به دسترسی روت روی ماشین میزبان دست یابد.
این نقص با شناسه CVE-2026-112816 ردیابی می‌شود و بالاترین امتیاز ممکن، یعنی ۱۰.۰ در مقیاس CVSS را دارد. کنونیکال نسخه‌های اصلاح‌شده هر دو محصول را منتشر کرده است.
سازوکار فنی: اعتماد به کل زنجیره گواهی
LXD و MicroCloud اجازه می‌دهند کلاینت‌های راه‌دور از طریق TLS دوطرفه (Mutual TLS) به API دسترسی پیدا کنند؛ روشی که در آن کلاینت برای اثبات هویت، یک گواهی ارائه می‌دهد. یک کلاینت زمانی «مورد اعتماد» است که گواهی‌اش در مخزن اعتماد (Trust Store) سرور — فهرست هویت‌هایی که سرور می‌پذیرد — قرار داشته باشد.
مشکل در نحوه بررسی این گواهی توسط سرور بود. سرور تمام گواهی‌هایی را که کلاینت می‌فرستد با مخزن اعتماد مقایسه می‌کرد؛ در حالی که یک اتصال TLS تنها ثابت می‌کند کلاینت صاحب کلید خصوصی نخستین گواهی در زنجیره (گواهی برگ یا Leaf) است. بقیه زنجیره، هرچه باشد، همان چیزی است که کلاینت خودش انتخاب کرده و به آن پیوست می‌کند.
نتیجه: مهاجم می‌تواند گواهی عمومی یک کلاینت مورد اعتماد — که محرمانه نیست — را پشت گواهی خودش در زنجیره قرار دهد و سرور او را به‌عنوان همان کلاینت می‌پذیرد.
چه کسانی تحت تأثیرند؟
سوءاستفاده از این نقص به دو چیز نیاز دارد: دسترسی شبکه‌ای به API HTTPS و گواهی عمومی یک کلاینت مورد اعتماد.
- LXD مستقل (Standalone): به‌طور پیش‌فرض API شبکه‌ای را در معرض دید قرار نمی‌دهد و فقط روی یک سوکت محلی گوش می‌دهد، مگر این‌که مدیر با تنظیم
core.https_addressآن را فعال کرده باشد. - MicroCloud: که چند ماشین دارای LXD را به یک خوشه واحد پیوند می‌دهد، یک نقطه ضعف ویژه دارد. کنونیکال می‌گوید مهاجمی که بتواند گواهی عمومی یک عضو را در لحظه پیوستن آن به خوشه شنود کند، سپس می‌تواند به‌جای آن عضو وارد شود.
نسخه‌های آسیب‌دیده و اصلاح‌شده
رکورد CVE نسخه‌های LXD 4.0.14، 5.0.10، 5.21.8 و 6.9 را به‌عنوان آسیب‌دیده (پیش از نسخه اصلاح‌شده هر شاخه) فهرست کرده است. نسخه‌های اصلاح‌شده اسنپ (Snap) به شرح زیر است:
| محصول | کانال اسنپ | نسخه اصلاح‌شده |
|---|---|---|
| LXD | 6/stable | 6.10.1 |
| LXD | 5.21/stable | 5.21.9 |
| LXD | 5.0/stable | 5.0.11 |
| LXD | 4.0/stable | 4.0.15 |
| MicroCloud | 3/stable | 3.4.1 |
| MicroCloud | 2/stable | 2.1.5 |
بسته‌های LXD در آرشیو رسمی اوبونتو به‌عنوان «تحت‌تأثیرنبودن یا عدم ارائه» فهرست شده‌اند؛ بنابراین نسخه‌های اصلاح‌شده، همان اسنپ‌ها هستند.
ریشه نقص در Incus
این باگ از خود کنونیکال شروع نشد. پروژه Incus — که ابتدا به‌صورت یک فورک جامعه‌محور از LXD آغاز شد — آن را گزارش داد و کنونیکال تأیید کرد که LXD نیز تحت تأثیر است. Incus همان نقص را در نسخه ۷.۶.۰ رفع کرده است.
وضعیت بهره‌برداری
هیچ نشانه عمومی از استفاده از این نقص در حملات وجود ندارد. رکورد CVE شامل ارزیابی CISA به تاریخ ۳۰ اکتبر است که می‌گوید این نقص در حملات شناخته‌شده‌ای استفاده نشده؛ در فهرست KEV نیز نیست و هیچ کد بهره‌برداری فعالی منتشر نشده است.
چه باید کرد؟
- LXD و MicroCloud را به نسخه‌های اصلاح‌شده ارتقا دهید. روی نصب‌های مبتنی بر اسنپ، از دستورهای
sudo snap refresh lxdوsudo snap refresh microcloudاستفاده کنید. - کنونیکال اعلام کرده در زمان انتشار اطلاعیه، نسخه‌های اصلاح‌شده LXD هنوز در حال انتقال از کانال Candidate به Stable بودند؛ بنابراین پس از Refresh، نسخه واقعی نصب‌شده را بررسی کنید و صرفاً فرض نکنید وصله رسیده است.
- کنونیکال برای LXD راهکار موقتی ارائه نکرده است. چون حمله به دسترسی شبکه‌ای به API نیاز دارد، محدود کردن این‌که چه کسانی می‌توانند به آن برسند، ریسک را تا زمان به‌روزرسانی کاهش می‌دهد. Incus نیز می‌گوید راه‌حل پیکربندی وجود ندارد و تنها اقدام، محدود کردن دسترسی شبکه‌ای به شنوند (Listener) است.
- کاربران Incus باید به نسخه ۷.۶.۰ مهاجرت کنند که این نقص را همراه با ۱۷ مشکل امنیتی دیگر برطرف کرده است.
چرا این نقص اهمیت دارد؟
نخست، ماهیت منطقی این نقص: مشکل از رمزنگاری یا الگوریتم نیست، بلکه از یک فرض نادرست درباره معنای «اعتماد» در TLS دوطرفه ناشی می‌شود: اثبات مالکیت کلید فقط برای گواهی برگ برقرار است، نه کل زنجیره. این نوع اشتباه در بررسی گواهی، در سیستم‌های مختلف تکرار شده و برای مهاجم، گواهی‌های عمومی (که محرمانه نیستند) را به یک دروازه ورود تبدیل می‌کند.
دوم، اهمیت زیرساختی LXD و MicroCloud: این ابزارها برای مدیریت کانتینرها و ماشین‌های مجازی به‌کار می‌روند و دسترسی به آن‌ها، به معنای دسترسی به بار کاری و در بدترین حالت، به میزبان است. سوم، سناریوی خاص MicroCloud که در آن شنود گواهی عمومی هنگام پیوستن یک عضو به خوشه می‌تواند کافی باشد، نشان می‌دهد حتی شبکه‌های داخلی نیز مصون نیستند.
در مقابل، شرایط لازم برای بهره‌برداری (دسترسی شبکه‌ای به API و داشتن گواهی عمومی) و فعال نبودن API شبکه‌ای در پیکربندی پیش‌فرض LXD مستقل، دامنه عملی ریسک را محدود می‌کند؛ اما برای سازمان‌هایی که API را عمداً در معرض شبکه قرار داده‌اند، فوریت اقدام بالاست.
جمع‌بندی
CVE-2026-112816 با امتیاز ۱۰.۰، نمونه‌ای از یک خطای ظریف در اعتبارسنجی زنجیره گواهی است که به مهاجم اجازه می‌دهد بدون کلید خصوصی، هویت یک کلاینت مورد اعتماد را جعل کند. کنونیکال نسخه‌های اصلاح‌شده LXD (۶.۱۰.۱، ۵.۲۱.۹، ۵.۰.۱۱، ۴.۰.۱۵) و MicroCloud (۳.۴.۱ و ۲.۱.۵) را منتشر کرده و Incus نیز در ۷.۶.۰ آن را رفع کرده است. هرچند هیچ شواهدی از بهره‌برداری وجود ندارد، مدیران باید به‌روزرسانی کنند، نسخه واقعی را پس از Refresh تأیید کنند و تا آن زمان دسترسی شبکه‌ای به API را محدود نگه دارند.
برچسب ها: MicroCloud, امنیت_اطلاعات, امنیت_سایبری, Cyberattack, cybersecurity, حمله سایبری, news