اگر روی VPS یا سرور لینوکسی کاربر محلی، سرویس وب، کانتینر یا فرایندی دارید که ممکن است کد غیرقابلاعتماد اجرا کند، GhostLock (CVE-2026-43499) موضوعی نیست که بتوان آن را صرفاً با فایروال یا تغییر پورت SSH حل کرد. این آسیبپذیری در کرنل لینوکس قرار دارد و طبق ارزیابی Ubuntu امتیاز CVSS 7.8 (High) دارد. Red Hat نیز توضیح میدهد که نقص در مسیرهای rtmutex/futex میتواند به Use-After-Free منجر شود و یک مهاجم محلی را قادر به ارتقای سطح دسترسی یا اجرای کد غیرمجاز کند.
uname -r و ابزارهای امنیتی همان توزیع مطمئن شوید که واقعاً کرنل اصلاحشده در حال اجراست. فقط نگاهکردن به شماره upstream کرنل کافی نیست؛ بسیاری از توزیعها Fix را backport میکنند.GhostLock یا CVE-2026-43499 چیست؟
GhostLock نامی است که برای آسیبپذیری CVE-2026-43499 در کرنل لینوکس استفاده میشود. منشأ مشکل به مدیریت قفلهای real-time mutex و مسیر futex_requeue() برمیگردد. در یک سناریوی خاص، کرنل هنگام rollback یک proxy lock میتواند اشارهگر task را بهدرستی مدیریت نکند و شرایط Use-After-Free ایجاد شود.
از دید مدیر VPS، بخش مهمتر از جزئیات داخلی باگ این است که این نقص محلی است: مهاجم برای سوءاستفاده باید ابتدا امکان اجرای کد روی سیستم داشته باشد. اما اگر این شرط برقرار باشد، آسیبپذیری میتواند امنیت مرز بین یک کاربر عادی و دسترسیهای بالاتر را تضعیف کند. بنابراین روی سرورهای اشتراکی، CI/CD، هاست اپلیکیشن، محیطهای چندکاربره و سرورهایی که workloadهای غیرقابلاعتماد اجرا میکنند، اولویت پچ بالاتر است.
شدت GhostLock چقدر است و چه خطری برای VPS دارد؟
| پارامتر | وضعیت |
|---|---|
| شناسه | CVE-2026-43499 |
| شدت در Ubuntu | High — CVSS 7.8 |
| نوع نقص | Use-After-Free در کرنل |
| بردار اصلی | Local Privilege Escalation |
| سیستم هدف | Linux Kernel |
| اقدام اصلی | نصب Kernel Fix رسمی + فعالکردن کرنل اصلاحشده |
Openwall در اطلاعیه فنی مربوط به GhostLock به گسترهای از نسخههای قدیمی تا جدید کرنل اشاره کرده است. با این حال، برای تصمیم عملی روی یک VPS نباید فقط خروجی uname -r را با یک بازه upstream مقایسه کنید؛ Ubuntu، Red Hat، AlmaLinux و دیگر توزیعها ممکن است اصلاح امنیتی را روی همان شاخه کرنل backport کنند.
از کجا بفهمیم سرور در برابر CVE-2026-43499 آسیبپذیر است؟
بهترین روش این است که وضعیت را بر اساس Advisory همان توزیع بررسی کنید. شماره کرنل بهتنهایی پاسخ قطعی نمیدهد.
۱) توزیع و کرنل در حال اجرا را مشخص کنید
cat /etc/os-release
uname -r
این دو خروجی مشخص میکنند باید Advisory کدام Vendor را دنبال کنید و در حال حاضر چه کرنلی boot شده است.
۲) آپدیتهای امنیتی موجود را بررسی کنید
روی Ubuntu/Debian:
sudo apt update
apt list --upgradable
روی AlmaLinux/Rocky/RHEL-compatible:
sudo dnf check-update
وجود آپدیت kernel نشانهای برای اقدام است، اما نبودن آن نیز همیشه به معنی امنبودن نیست؛ مخزن، نسخه توزیع و وضعیت EOL سیستمعامل را هم باید در نظر گرفت.
روش رفع GhostLock در Ubuntu و Debian
برای بیشتر VPSهای Ubuntu/Debian، مسیر امن این است که پکیجهای کرنل را از مخازن رسمی همان توزیع بهروز کنید:
sudo apt update
sudo apt full-upgrade -y
sudo reboot
پس از بالا آمدن سرور:
uname -r
سپس صفحه امنیتی توزیع را برای CVE-2026-43499 بررسی کنید و مطمئن شوید نسخه در حال اجرا در وضعیت Fixed قرار دارد. Ubuntu برای این CVE یک صفحه رسمی با وضعیت شاخههای مختلف و نسخههای اصلاحشده منتشر کرده است.
روش رفع GhostLock در AlmaLinux، Rocky Linux و RHEL
در خانواده RHEL، باید بسته کرنل را از مخازن معتبر توزیع نصب کنید. AlmaLinux برای GhostLock بهصراحت انتشار کرنلهای اصلاحشده را اعلام کرده و نصب آپدیت و reboot را توصیه کرده است:
sudo dnf clean metadata
sudo dnf upgrade -y
sudo reboot
بعد از reboot:
uname -r
برای Rocky Linux و RHEL نیز معیار نهایی باید Advisory همان Vendor و بستههای رسمی آن باشد؛ صرفاً نسخه پیشنهادی توزیع دیگری را روی سرور خود معیار قرار ندهید.
آیا بدون reboot میتوان GhostLock را رفع کرد؟
در بعضی محیطها ممکن است Vendor یا سرویس Live Patching یک Fix معتبر برای CVE ارائه کرده باشد. اگر پوشش این CVE برای کرنل دقیق شما تأیید شده باشد، میتوان زمان Downtime را کاهش داد. اما وجود یک سرویس Livepatch بهتنهایی تضمین نمیکند که همین CVE پوشش داده شده است.
اگر uptime برای شما حیاتی است، راهنمای Live Kernel Patching و کاهش Downtime را بخوانید و قبل از حذف reboot از برنامه، وضعیت پوشش CVE-2026-43499 را در Vendor خود تأیید کنید.
چرا کانتینرها این مشکل را بیاهمیت نمیکنند؟
Docker و بسیاری از runtimeهای کانتینری کرنل میزبان را با workloadها به اشتراک میگذارند. بنابراین «اپلیکیشن داخل کانتینر است» دلیل کافی برای عقبانداختن پچ کرنل نیست. ریسک دقیق به runtime، namespaceها، capabilityها و تنظیمات isolation بستگی دارد، اما قاعده عملی روشن است: Host Kernel باید پچ شود.
اگر روی VPS چند سرویس یا کانتینر دارید، علاوه بر کرنل، سطح دسترسی کاربران، capabilityهای کانتینر، bind mountها و سرویسهایی که کد خارجی اجرا میکنند را نیز بررسی کنید.
بعد از نصب پچ چه چیزهایی را بررسی کنیم؟
- کرنل در حال اجرا: با
uname -rمطمئن شوید سیستم با نسخه مورد انتظار boot شده است. - Advisory Vendor: وضعیت CVE-2026-43499 را برای نسخه توزیع خود روی Fixed/Resolved بررسی کنید.
- سرویسها: وبسرور، دیتابیس، Docker و سرویسهای اصلی را پس از reboot تست کنید.
- لاگها: خطاهای boot و kernel را با
journalctl -b -p warningمرور کنید. - دسترسیهای محلی: کاربران و سرویسهایی که shell یا اجرای کد دارند را بازبینی کنید.
- Snapshot/Backup: قبل و بعد از تغییرات مهم، مسیر بازیابی قابلتست داشته باشید.
GhostLock چه ارتباطی با امنسازی کلی VPS دارد؟
این CVE نمونه خوبی از تفاوت «امنیت شبکه» و «امنیت سیستمعامل» است. فایروال، Fail2Ban و SSH Key مهماند، اما نقصهای Local Privilege Escalation در لایه کرنل قرار دارند و با بستن پورت حل نمیشوند. برای یک چکلیست کاملتر، مقاله راهنمای امنسازی VPS لینوکس در سال ۲۰۲۶ را هم ببینید.
چکلیست فوری برای مدیر VPS
| مرحله | اقدام |
|---|---|
| ۱ | تشخیص توزیع و نسخه کرنل |
| ۲ | بررسی CVE-2026-43499 در Advisory رسمی Vendor |
| ۳ | نصب Kernel Update از مخزن رسمی |
| ۴ | Reboot یا تأیید Livepatch معتبر |
| ۵ | Verify نسخه در حال اجرا و تست سرویسها |
| ۶ | بازبینی دسترسیهای محلی و workloadهای پرریسک |
آیا کاربران سرور مجازی وانسرور باید کاری انجام دهند؟
اگر VPS شما Self-managed است و مدیریت سیستمعامل با خودتان است، باید وضعیت کرنل و Advisory توزیع را بررسی کنید و در صورت وجود Fix، آن را نصب کنید. این موضوع وابسته به یک ارائهدهنده خاص نیست؛ GhostLock یک آسیبپذیری در اکوسیستم Linux Kernel است. اگر برای پروژه خود به VPS با منابع اختصاصی نیاز دارید، میتوانید پلنهای سرور مجازی وانسرور را بررسی کنید.
سوالات متداول درباره GhostLock
آیا GhostLock از راه دور قابل سوءاستفاده است؟
بردار اصلی گزارششده برای CVE-2026-43499 محلی است؛ یعنی مهاجم ابتدا باید امکان اجرای کد روی سیستم داشته باشد. با این حال، روی سرورهایی که اپلیکیشن عمومی، حسابهای متعدد یا workloadهای غیرقابلاعتماد دارند، همین شرط میتواند در زنجیره حمله ایجاد شود.
آیا فقط با بستن پورتها مشکل حل میشود؟
خیر. فایروال سطح حمله شبکه را کم میکند، اما GhostLock در کرنل است. راهکار اصلی، نصب Fix رسمی کرنل و فعالشدن نسخه اصلاحشده است.
آیا باید حتماً reboot کنیم؟
اگر کرنل جدید بهصورت بسته معمولی نصب شده باشد، معمولاً برای اجرای آن reboot لازم است. فقط زمانی reboot را حذف کنید که Vendor یا سرویس Livepatch بهطور مشخص پوشش CVE-2026-43499 را برای کرنل شما تأیید کرده باشد.
آیا شماره کرنل پایینتر به معنی آسیبپذیر بودن است؟
نه لزوماً. توزیعهای لینوکسی بسیاری از اصلاحات امنیتی را backport میکنند. وضعیت بسته در Advisory رسمی توزیع از مقایسه ساده شماره upstream قابلاعتمادتر است.
آیا Docker از GhostLock در امان است؟
کانتینرها معمولاً کرنل میزبان را به اشتراک میگذارند. بنابراین Host Kernel باید اصلاح شود؛ سطح ریسک دقیق به تنظیمات isolation و runtime بستگی دارد.
جمعبندی
GhostLock یا CVE-2026-43499 یک آسیبپذیری مهم در Linux Kernel است که میتواند مرز دسترسی محلی را تضعیف کند. برای مدیر VPS، مسیر درست پیچیده نیست: Advisory توزیع را بررسی کنید، کرنل را از مخزن رسمی بهروز کنید، reboot یا Livepatch معتبر را انجام دهید و سپس نسخه در حال اجرا را Verify کنید. در کنار آن، دسترسیهای محلی، کانتینرها و سرویسهایی که امکان اجرای کد دارند را محدود نگه دارید.