نقص CVE-2026-98432 در بخش IPv4 TCP کرنل Linux: وضعیت CloudLinux
CVE-2026-98432 (با امتیاز CVSS برابر 9.8 و سطح «بحرانی» به گفته‌ی Red Hat) یک نقص use-after-free در کد IPv4 TCP کرنل Linux است که مهاجم از راه دور و بدون داشتن حساب کاربری روی سرور می‌تواند به آن برسد. برای بهره‌برداری از آن، مهاجم باید در یک رقابت زمانی (race) درون کرنل برنده شود و این کار ساده‌ای نیست. Anthropic، گزارش‌دهنده‌ی این نقص، می‌گوید مدل هوش مصنوعی‌اش اکسپلویتی ساخته که روی سرورهایی با شنونده‌ی Multipath TCP، از راه دور دسترسی root می‌گیرد. تیم کرنل ما نتوانست این ادعا را بازتولید کند. این اکسپلویت عمومی نشده و تا امروز هم گزارشی از سوءاستفاده از آن در دنیای واقعی منتشر نشده است.
- نسخه‌های آسیب‌پذیر: CloudLinux 7h، 8، 8 LTS، 9، 9 LTS و 10، و CloudLinux for Ubuntu 22.04. CloudLinux 7 آسیب‌پذیر نیست. ← نسخه‌های آسیب‌پذیر CloudLinux
- Multipath TCP: اکسپلویت ادعاشده به آن نیاز دارد و این قابلیت در CloudLinux 8، 9 و 10 به‌طور پیش‌فرض خاموش است. اما خودِ باگ در کد معمولی TCP است، پس این سرورها هم باید وصله شوند. ← اکسپلویت ادعاشده به چه چیزی نیاز دارد
- راهکار موقت: وجود ندارد. ← آیا راهکار موقتی وجود دارد؟
- وضعیت وصله: ← دستورالعمل به‌روزرسانی
- کرنل CloudLinux 7h و 8: کرنل وصله‌شده به‌تدریج در حال انتشار است.
- کرنل AlmaLinux (CloudLinux 9 و 10): کرنل وصله‌شده در مخزن آزمایشی AlmaLinux قرار دارد.
- کرنل‌های LTS (CloudLinux 8 LTS و 9 LTS): کرنل وصله‌شده به‌تدریج در حال انتشار است.
- وصله‌ی زنده‌ی KernelCare: برای CloudLinux 7h، 8، 9 و 10 در حال آماده‌سازی است.
- CloudLinux for Ubuntu 22.04: Canonical هنوز وصله‌ی خود را منتشر نکرده است.
- چرا اهمیت دارد: حمله از راه شبکه انجام می‌شود و مهاجم به هیچ حساب میزبانی نیاز ندارد. ← چرا این موضوع در میزبانی اشتراکی اهمیت دارد
- سازوکار باگ: با یک درخواست اتصال تکراری می‌شود کرنل را واداشت حافظه‌ای را بخواند که قبلاً آزاد کرده است. ← جزئیات فنی باگ
این اطلاعیه در صفحه‌ی وضعیت CloudLinux هم پیگیری می‌شود؛ برای دریافت آخرین وضعیت می‌توانید آنجا مشترک شوید.
CVE-2026-98432 یک نقص use-after-free در کد IPv4 TCP کرنل Linux است؛ همان بخشی که اتصال‌های جدید شبکه را برقرار می‌کند. هر کسی که بتواند به یک پورت باز IPv4 TCP روی سرور دسترسی پیدا کند، می‌تواند به کد آسیب‌پذیر برسد؛ آن هم بدون حساب کاربری یا گذرواژه. برای بهره‌برداری، مهاجم باید در یک رقابت زمانی درون کرنل برنده شود که کار دشواری است.
Anthropic، گزارش‌دهنده‌ی این نقص، در 27 اکتبر اعلام کرد مدل هوش مصنوعی‌اش اکسپلویتی ساخته است؛ اکسپلویتی که روی سرورهایی با شنونده‌ی Multipath TCP، از راه دور دسترسی root می‌گیرد. تیم کرنل ما نتوانست این ادعا را بازتولید کند. Anthropic این اکسپلویت را منتشر نکرده و گزارشی هم از سوءاستفاده از آن در دنیای واقعی وجود ندارد.
در CloudLinux، همه‌ی نسخه‌ها به‌جز CloudLinux 7 درگیر این نقص‌اند. Multipath TCP به‌طور پیش‌فرض غیرفعال است (در CloudLinux 8، 9 و 10)، اما خودِ باگ در کد معمولی TCP است؛ پس همه‌ی سرورهای آسیب‌پذیر باید وصله شوند.
هر سرور میزبانی اشتراکی برای وب‌سایت‌ها، ایمیل و SSH پورت‌های IPv4 TCP را باز نگه می‌دارد. روی سرور آسیب‌پذیر، همین پورت‌ها راه رسیدن به کد آسیب‌پذیرند.
💡 وصله بدون ریبوت
KernelCare را به کسانی توصیه می‌کنیم که وصله‌ی اضطراری و ریبوت پشت‌سرهم سرورها برایشان شدنی نیست. این ابزار کرنل را در همان حال اجرا وصله می‌کند؛ بدون ریبوت و بدون قطعی برای مشتریان. وصله‌ی زنده‌ی این مشکل برای CloudLinux 7h، 8، 9 و 10 در حال آماده‌سازی است و پس از انتشار، آن را در جریان 4 فهرست خواهیم کرد.
نسخه‌های آسیب‌پذیر CloudLinux
کد آسیب‌پذیر در Linux 4.4 وارد کرنل شد؛ پس همه‌ی کرنل‌های CloudLinux از آن نسخه به بعد آن را دارند.
| نسخه | آسیب‌پذیر | وضعیت |
|---|---|---|
| CloudLinux 7 (CL7) کرنل 3.10 |
✅ خیر: کد آسیب‌پذیر در Linux 4.4 وارد شد | ℹ️ نیازی به به‌روزرسانی نیست |
| CloudLinux 7h (CL7h) کرنل 4.18 |
❌ بله | ✅ وصله‌ی کرنل: 4.18.0-553.180.1.lve.1، در حال انتشار مرحله‌ای ⏳ وصله‌ی زنده: در حال آماده‌سازی |
| CloudLinux 8 (CL8) کرنل 4.18 |
❌ بله | ✅ وصله‌ی کرنل: 4.18.0-553.180.1.lve.1، در حال انتشار مرحله‌ای ⏳ وصله‌ی زنده: در حال آماده‌سازی |
| CloudLinux 8 LTS کرنل 5.14 (TuxCare ELS) |
❌ بله | ✅ وصله‌ی کرنل: kernel-lts els19، در حال انتشار مرحله‌ای ℹ️ وصله‌ی زنده: در دسترس نیست؛ کرنل وصله‌شده را نصب کنید |
| CloudLinux 9 (CL9) کرنل 5.14 |
❌ بله | ✅ وصله‌ی کرنل: 5.14.0-687.61.2.el9_8، در مخزن آزمایشی AlmaLinux ⏳ وصله‌ی زنده: در حال آماده‌سازی |
| CloudLinux 9 LTS کرنل 5.14 (TuxCare ELS) |
❌ بله | ✅ وصله‌ی کرنل: kernel-lts els19، در حال انتشار مرحله‌ای ℹ️ وصله‌ی زنده: در دسترس نیست؛ کرنل وصله‌شده را نصب کنید |
| CloudLinux 10 (CL10) کرنل 6.12 |
❌ بله | ✅ وصله‌ی کرنل: 6.12.0-211.69.2.el10_2، در مخزن آزمایشی AlmaLinux ⏳ وصله‌ی زنده: در حال آماده‌سازی |
| CloudLinux for Ubuntu 22.04 کرنل 5.15 |
❌ بله | ⏳ وصله‌ی کرنل: از طریق Canonical، هنوز منتشر نشده † ℹ️ وصله‌ی زنده: در دسترس نیست |
† CloudLinux for Ubuntu 22.04 کرنلش را از Ubuntu (Canonical) و با apt می‌گیرد، نه از جریان‌های CloudLinux. تا 30 اکتبر 2026، وضعیت وصله‌ی کرنل 22.04 در Canonical «در دست انجام» است و هر وقت Canonical آن را منتشر کند، همین‌جا خبر می‌دهیم.
اکسپلویت ادعاشده به چه چیزی نیاز دارد
اکسپلویتی که Anthropic توصیف می‌کند، سروری با شنونده‌ی Multipath TCP (MPTCP) لازم دارد. MPTCP افزونه‌ای بر TCP است که اجازه می‌دهد یک اتصال هم‌زمان از چند مسیر شبکه استفاده کند. برنامه فقط وقتی از آن استفاده می‌کند که اتصال‌هایش را به‌صورت MPTCP باز کند و کرنل در CloudLinux 8، 9 و 10 به‌طور پیش‌فرض چنین اجازه‌ای نمی‌دهد.
برای دیدن این تنظیم روی سرورتان، این دستور را اجرا کنید:
sysctl net.mptcp.enabledاگر خروجی net.mptcp.enabled = 0 باشد، این قابلیت غیرفعال است.
این تنظیم نقص را برطرف نمی‌کند. باگ در کد معمولی TCP است که همه‌ی اتصال‌های IPv4 از آن می‌گذرند. پس سروری که MPTCP در آن غیرفعال است، باز هم کد آسیب‌پذیر را اجرا می‌کند و باید وصله شود.
آیا راهکار موقتی وجود دارد؟
خیر. به گفته‌ی Red Hat، هیچ‌کدام از راهکارهای موقت موجود از نظر سادگی استقرار، کاربرد گسترده و پایداری، معیارهای این شرکت را برآورده نمی‌کنند. راه‌حل، به‌روزرسانی کرنل یا نصب وصله‌ی زنده‌ی نسخه‌ی شماست.
دستورالعمل به‌روزرسانی
وصله از چهار جریان زیر به سرورهای CloudLinux می‌رسد و CloudLinux for Ubuntu 22.04 آن را از Canonical می‌گیرد. هر وقت وضعیت یکی از جریان‌ها تغییر کند، همین‌جا به‌روزش می‌کنیم.
جریان 1: کرنل CloudLinux 7h و 8
به‌روزرسانی: 30 اکتبر 2026، ساعت 22:55 UTC.
CloudLinux یک کرنل وصله‌شده برای CloudLinux 7h و 8 منتشر کرده است: 4.18.0-553.180.1.lve.1. این کرنل به‌تدریج روی سرورهای عملیاتی منتشر می‌شود؛ پس به‌روزرسانی معمولی کرنل فقط وقتی آن را نصب می‌کند که نوبت به آن سرور برسد. برای نصب فوری، این دستورها را اجرا کنید:
yum update cloudlinux-release
yum update kernel --enablerepo=cloudlinux-rollout-3-bypass
rebootدستور اول بسته‌ای را به‌روز می‌کند که مخزن‌های CloudLinux را تعریف می‌کند تا دستور دوم به مخزن انتشار دسترسی داشته باشد. پس از ریبوت، خروجی uname -r باید با 4.18.0-553.180.1.lve.1 شروع شود. وقتی انتشار کامل شد، همین‌جا خبر می‌دهیم.
وضعیت: 30 اکتبر 2026.
هنوز کرنل وصله‌شده‌ای در دسترس نیست. کرنل‌های CloudLinux 7h و 8 را خود CloudLinux می‌سازد و نسخه‌ی وصله‌شده در حال آماده‌سازی است. پس از انتشار، نسخه‌ی کرنل را همین‌جا اضافه می‌کنیم.
جریان 2: کرنل AlmaLinux (CloudLinux 9 و 10)
به‌روزرسانی: 30 اکتبر 2026، ساعت 22:55 UTC.
AlmaLinux کرنل‌های وصله‌شده را در مخزن آزمایشی خود منتشر کرده است: kernel-5.14.0-687.61.2.el9_8 برای CloudLinux 9 و kernel-6.12.0-211.69.2.el10_2 برای CloudLinux 10. Red Hat هنوز وصله‌ی خودش را منتشر نکرده است. برای نصب فوری، بسته‌ی release مخزن آزمایشی AlmaLinux را مستقیم از AlmaLinux نصب کنید تا این مخزن فعال شود. بعد کرنل را به‌روز کنید، مخزن آزمایشی را غیرفعال کنید و سرور را دوباره راه‌اندازی کنید.
برای CloudLinux 9:
rpm -Uvh --nodeps https://repo.almalinux.org/almalinux/9/extras/x86_64/os/Packages/almalinux-release-testing-9-2.el9.noarch.rpm
dnf update 'kernel*'
dnf config-manager --disable almalinux-testing
rebootبرای CloudLinux 10:
dnf install -y https://repo.almalinux.org/almalinux/10/extras/x86_64/os/Packages/almalinux-release-testing-10-2.el10.x86_64.rpm
dnf update 'kernel*'
dnf config-manager --disable almalinux-testing
rebootپس از ریبوت، خروجی uname -r باید در CloudLinux 9 با 5.14.0-687.61.2 و در CloudLinux 10 با 6.12.0-211.69.2 شروع شود. وقتی این کرنل‌ها به مخزن‌های CloudLinux برسند، به‌روزرسانی معمولی کرنل آن‌ها را نصب می‌کند و این را همین‌جا اعلام می‌کنیم.
وضعیت: 30 اکتبر 2026.
هنوز کرنل وصله‌شده‌ای در دسترس نیست. CloudLinux 9 و 10 از کرنل AlmaLinux استفاده می‌کنند که پیرو Red Hat است. Red Hat کرنل‌های RHEL 9 و 10 را آسیب‌پذیر اعلام کرده، ولی هنوز وصله‌ای منتشر نکرده است. پس از انتشار، نسخه‌ی کرنل AlmaLinux را همین‌جا اضافه می‌کنیم.
جریان 3: کرنل TuxCare ELS LTS (CloudLinux 8 LTS و 9 LTS)
وضعیت: 30 اکتبر 2026.
کرنل‌های وصله‌شده منتشر شده‌اند: kernel-lts-5.14.0-284.1101.el8.tuxcare.11.els19 برای CloudLinux 8 LTS و kernel-lts-5.14.0-284.1101.el9.tuxcare.11.els19 برای CloudLinux 9 LTS. این کرنل‌ها 30 اکتبر به کانال بتا رسیدند و حالا به‌تدریج روی سرورهای عملیاتی منتشر می‌شوند؛ وقتی نوبت به هر سرور برسد، به‌روزرسانی معمولی کرنل آن‌ها را نصب می‌کند. برای اجرای کرنل وصله‌شده، سرور باید دوباره راه‌اندازی شود. وقتی انتشار کامل شد، همین‌جا خبر می‌دهیم.
جریان 4: وصله‌ی زنده‌ی KernelCare
وضعیت: 30 اکتبر 2026.
وصله‌ی زنده برای کرنل‌های CloudLinux 7h و 8 و همچنین کرنل‌های AlmaLinux مورد استفاده در CloudLinux 9 و 10 در حال آماده‌سازی است. پس از انتشار، این وصله بدون ریبوت روی سرورهای در حال کار اعمال می‌شود. هر انتشار را همین‌جا اضافه می‌کنیم.
چطور مطمئن شویم سرور وصله شده است
پس از ریبوت، uname -r را اجرا کنید و خروجی را با نسخه‌ی کرنلی که برای جریان شما آمده مقایسه کنید.
برای KernelCare، پس از انتشار وصله‌ی زنده:
kcarectl --patch-info | grep CVE-2026-98432روی سرور وصله‌شده، سطری برای این CVE چاپ می‌شود. حتماً از --patch-info استفاده کنید؛ kcarectl --info فقط سطح وصله را نشان می‌دهد و CVEها را فهرست نمی‌کند، پس سرور وصله‌شده را هم وصله‌نشده نشان می‌دهد.
چرا این موضوع در میزبانی اشتراکی اهمیت دارد
برای این حمله، مهاجم به هیچ حساب میزبانی یا سایت نفوذشده‌ای روی سرور نیاز ندارد. او درخواست‌های اتصال با گزینه‌های IPv4 می‌فرستد و آن‌قدر تکرارشان می‌کند تا در یک رقابت زمانی درون کرنل برنده شود. باختن در این رقابت فقط یک اتصال ناموفق برایش هزینه دارد و سرور هم به کارش ادامه می‌دهد؛ پس می‌تواند بارها تلاش کند.
هنوز ثابت نشده که مهاجم از این راه تا کجا می‌تواند پیش برود. Anthropic در نوشته‌اش نه نسخه‌ی کرنل را گفته و نه پیکربندی‌ای را که اکسپلویت روی آن اجرا شده است. تیم کرنل ما با تأخیرهای مصنوعی یک خطای حافظه ایجاد کرد، اما این خطا با اجرای کد از راه دور فاصله‌ی زیادی دارد و ما آن را روی کرنل CloudLinux بازتولید نکرده‌ایم.
جزئیات فنی باگ
وقتی کلاینت یک اتصال TCP باز می‌کند، اولین بسته‌اش (SYN) می‌تواند گزینه‌های IPv4 مثل Record Route یا Timestamp را داشته باشد. سرور این گزینه‌ها را کنار اتصالِ در انتظار نگه می‌دارد. با کامل شدن دست‌دهی (handshake)، کرنل همان‌ها را بدون کپی‌گرفتن به اتصال جدید می‌دهد.
اگر همان لحظه نسخه‌ی بازارسال‌شده‌ی همان SYN برسد و CPU دیگری پردازشش کند، آن CPU پاسخش را از روی همین گزینه‌ها می‌سازد. حالا اگر اتصال جدید زودتر آزاد شود، کرنل گزینه‌ها را آزاد می‌کند در حالی که پاسخ هنوز دارد آن‌ها را می‌خواند. همین خواندن از حافظه‌ی آزادشده، use-after-free است.
وصله‌ی بالادستی دو خط را تغییر می‌دهد تا کرنل پیش از آزادکردن گزینه‌ها صبر کند همه‌ی خواننده‌ها کارشان را تمام کنند. IPv6 به‌جای اشتراک‌گذاری، از گزینه‌ها کپی می‌گیرد؛ برای همین دست‌دهی IPv6 این نقص را ندارد.
منابع
- اعلامیه‌ی Kernel CNA درباره‌ی CVE-2026-98432
- کامیت وصله‌ی بالادستی
- نوشته‌ی Anthropic درباره‌ی اکسپلویت ادعاشده (27 اکتبر 2026)
- Red Hat: CVE-2026-98432
- Ubuntu: CVE-2026-98432
- رخداد مربوط به این اطلاعیه در صفحه‌ی وضعیت CloudLinux
منبع: CVE-2026-98432 Linux kernel IPv4 TCP flaw: status for CloudLinux، CloudLinux Blog
