CVE-2026-98432: ثغرة حرجة في نواة لينكس وكيف تحمي خادمك

في 15/10/2026 نشر فريق أمان نواة لينكس الثغرة CVE-2026-98432، وبعد أيام منحها درجة 9.8 من 10. الثغرة في الشيفرة التي تستقبل اتصالات TCP الجديدة عبر IPv4، أي في الطريق الذي يمر به كل زائر لموقعك، وكل اتصال SSH، وكل طلب إلى قاعدة بيانات أو خادم بريد. يكفي المهاجمَ أن يصل إلى أي منفذ TCP مفتوح على خادم غير محدّث ليُسقطه، دون حساب أو كلمة مرور، وتحذّر Red Hat من أنها قد تقود إلى تنفيذ أوامر عن بُعد. وفي 27/10 أعلنت Anthropic أن نموذجاً بحثياً لديها كتب استغلالاً يمنح صلاحيات root على خوادم تستمع لاتصالات Multipath TCP. لم يُبلَّغ عن أي هجوم فعلي حتى 5/11، لكن الإصلاح منشور علناً منذ أسابيع، ومن يقرؤه يعرف أين الخلل. في هذا المقال: ما الذي حدث، وكيف تعمل الثغرة، ومن المتأثر، وأين صدر الإصلاح لكل توزيعة، وكيف تحدّث خادمك أو تحميه مؤقتاً حتى يصل التحديث.

01ما الذي حدث، ومتى

لم تبدأ القصة بإعلان طارئ، بل بإصلاح صغير في شيفرة النواة سبق التحذيرات بأسابيع:

المفارقة أن الإصلاح سبق التحذير بأسابيع، ومع ذلك لم تأخذه أغلب الخوادم. فالإصلاح المنشور خريطة للمهاجم أيضاً: يقرأ ما تغيّر في الشيفرة فيعرف أين يضرب، والخادم الذي لم يُحدَّث ولم يُعَد تشغيله ما زال يعمل بالشيفرة القديمة.

02كيف تعمل الثغرة

يبدأ كل اتصال TCP بمصافحة من ثلاث خطوات: يرسل العميل حزمة SYN، فيرد الخادم بحزمة SYN-ACK، ثم يؤكد العميل. وحين تحمل حزمة SYN خيارات IP، مثل تسجيل المسار (Record Route) أو الطابع الزمني (Timestamp)، يحفظها الخادم مع طلب الاتصال ليبني منها رده.

الخلل في لحظة تسليم هذه الخيارات. حين تكتمل المصافحة تنتقل الخيارات إلى الاتصال الجديد دون نسخها. وفي الوقت نفسه قد تصل نسخة معادة من حزمة SYN نفسها، فيعالجها معالج آخر في الخادم ويبني منها رداً جديداً. فإن أُغلق الاتصال الجديد وحرّر الخيارات في تلك اللحظة، قرأ المعالج الآخر ذاكرة حُررت للتو. هذا هو استخدام الذاكرة بعد تحريرها، وهو باب معروف إلى إسقاط النظام أو تسريب ذاكرته أو التحكم فيه.

دخل الخلل النواة في الإصدار 4.4 مطلع 2016، حين صارت طلبات الاتصال تُعالَج دون قفل المقبس المستمع، ليقبل الخادم اتصالات أكثر على معالجات أكثر. وللخلل نفسه مسار ثانٍ حين يُفعَّل ترحيل طلبات الاتصال بين المقابس بالإعداد net.ipv4.tcp_migrate_req، وهو معطّل افتراضياً. أما الإصلاح فبسيط: تنتظر النواة حتى ينتهي كل من يقرأ الخيارات قبل أن تحررها.

وما يجعل الثغرة خطرة أن المهاجم لا يخسر شيئاً حين يفشل: المحاولة التي تخسر السباق تُفشل المصافحة وحدها، فيعيد المحاولة مرة بعد مرة. وفي تجربة Anthropic احتاج الاستغلال 48 دقيقة ليسرّب عنواناً من ذاكرة النواة، ثم 5 دقائق أخرى ليشغّل أمراً بصلاحيات root.

وما علاقة Multipath TCP؟

Multipath TCP امتداد يسمح للاتصال الواحد بأن يستخدم أكثر من مسار شبكة معاً. الاستغلال الذي وصفته Anthropic استهدف خوادم فيها برنامج يستمع لاتصالات MPTCP، لكن الخلل نفسه ليس في MPTCP، بل في TCP العادي. لذلك تقول Red Hat إن خلوّ خادمك من مستمعي MPTCP معلومة لا ضمانة، وإن تعطيله لا يكفي وحده. وانتبه إلى أن البرامج المكتوبة بلغة Go، من إصدارها 1.24، تفعّل MPTCP على منافذ الاستماع في لينكس افتراضياً، بحسب فريق أمان Go.

03من المتأثر

كل خادم لينكس بنواة 4.4 أو أحدث، أي كل التوزيعات المدعومة تقريباً، ما دام يستقبل اتصالات TCP عبر IPv4 على أي منفذ: موقع ويب، أو SSH، أو قاعدة بيانات، أو بريد. والذي يحدد الخطر إصدار النواة لا البرامج التي فوقها، فلا يحميك أن تكون لوحة التحكم أو خادم الويب محدّثين. وانتبه إلى ثلاث حالات:

• أنظمة غير متأثرة: RHEL 7 وCentOS 7 وCloudLinux 7 (غير الهجينة)، لأنها تعمل بنواة 3.10 الأقدم من الخلل. ولا تتأثر Windows ولا FreeBSD ولا أي نظام غير لينكس.
• الخادم الافتراضي بتقنية KVM: خادم KVM يعمل بنواته الخاصة، المنفصلة عن نواة الخادم المضيف. فتحديث المزود لخوادمه لا يحدّث خادمك، وعليك أن تحدّث النواة داخله وتعيد تشغيله بنفسك.
• الحاويات: حاويات Docker وLXC، ومنها حاويات Proxmox، تعمل بنواة المضيف، فتحديث الحزم داخل الحاوية لا يغيّر شيئاً. حدّث نواة المضيف وأعد تشغيله.

04أين صدر الإصلاح

هذه حالة الإصلاح في التوزيعات الشائعة حتى 5/11/2026. ابحث عن توزيعتك، ثم اتبع الخطوة التي تناسب حالتها:

• صدر الإصلاح: خذ نسخة احتياطية، وحدّث النواة، وأعد تشغيل الخادم اليوم.
• يصل تدريجياً أو قيد الاختبار: طبّق الحماية المؤقتة الآن، وحدّث حين يصل الإصلاح إلى المستودع المستقر.
• لم يصدر أو لا إصلاح: طبّق الحماية المؤقتة الآن. وإن كان إصدارك قد انتهى دعمه، فلن يصله إصلاح مجاني: خطط للانتقال إلى إصدار مدعوم.

05حدّث النواة وأعد التشغيل

قبل أي شيء خذ نسخة احتياطية أو لقطة للخادم، فتحديث النواة يعني إعادة تشغيل، والخادم الذي لا يقلع بعدها مشكلة أكبر من خادم لم يُحدَّث. ثم حدّث بأوامر توزيعتك:

# Debian 12 و13 وProxmox VE، وUbuntu حين يصدر إصلاحهاsudo apt update && sudo apt full-upgradesudo reboot# RHEL 8 و9 و10 وAlmaLinux وRocky Linux وCloudLinux: هل وصل الإصلاح إلى مستودعاتك؟sudo dnf --refresh updateinfo info --cves CVE-2026-98432sudo dnf update 'kernel*'sudo reboot# openSUSE وSLESsudo zypper refresh && sudo zypper patch && sudo reboot

وإن كان خادمك يعمل بنظام CloudLinux، فلديه طريقان آخران: أن تأخذ النواة المرقّعة قبل أن يكتمل نشرها التدريجي، أو أن تطبّق الإصلاح عبر KernelCare، الذي يقدّم الترقيع الحي. وقد نشرت KernelCare رقعة هذه الثغرة لـ CloudLinux 7h و8 و9 و10، فتحمي النواة العاملة دون إعادة تشغيل:

# CloudLinux 7h و8: النواة المرقّعة قبل اكتمال نشرها، كما توصي CloudLinuxsudo yum update cloudlinux-releasesudo yum update kernel --enablerepo=cloudlinux-rollout-3-bypasssudo reboot# KernelCare: الرقعة على النواة العاملة دون إعادة تشغيل، ثم التحقق منهاsudo kcarectl --updatesudo kcarectl --patch-info | grep CVE-2026-98432

والتحديث وحده لا يكفي: النواة الجديدة تُثبَّت على القرص، ويبقى الخادم يعمل بالقديمة حتى تعيد تشغيله. فبعد إعادة التشغيل تأكد أن الخادم أقلع بالنواة الجديدة، وأنها تحمل الإصلاح:

# النواة التي يعمل بها الخادم الآنuname -r# RHEL وAlmaLinux وRocky Linux وCloudLinux 8 فما بعد: رقم أكبر من 0 يعني أن النواة العاملة مرقّعةrpm -q --changelog kernel-core-$(uname -r) | grep -c CVE-2026-98432# Debian: رقم الحزمة في آخر السطر. الإصلاح في 6.1.190-1 أو 6.12.113-1~deb12u1 لـ Debian 12، وفي 6.12.113-1 لـ Debian 13، أو أحدثuname -v

المشكلةحدّثت النواة وما زال uname -r يعرض الإصدار القديم

الحللم تُعِد تشغيل الخادم بعد، أو أن محمّل الإقلاع اختار نواة أخرى. أعد التشغيل، وإن تكرر الأمر فتحقق من النواة الافتراضية في إعداد GRUB.

المشكلةالأمر dnf لا يجد تحديثاً لهذه الثغرة

الحلالإصلاح لم يصل إلى مستودعاتك بعد، أو أن بيانات المستودعات قديمة عندك. نفّذ sudo dnf clean metadata ثم أعد المحاولة، وإن لم يصل فطبّق الحماية المؤقتة.

المشكلةحدّث المزود خوادمه وخادمك الافتراضي ما زال بالنواة القديمة

الحلخادم KVM يعمل بنواته الخاصة، فتحديثها مسؤوليتك داخله: حدّث النواة وأعد التشغيل.

المشكلةحدّثت الحزم داخل حاوية Docker وما زالت مكشوفة

الحلالحاوية تعمل بنواة المضيف، لا بنواة من داخلها. حدّث نواة المضيف وأعد تشغيله.

المشكلةاختفت قاعدة nftables بعد إعادة التشغيل

الحلالقاعدة التي تحمّلها بالأمر nft لا تبقى بعد إعادة التشغيل. أضف سطر include إلى ملف إعداد nftables وفعّل خدمته، كما في القسم التالي.

06إن لم يصل الإصلاح بعد: الحماية المؤقتة

الخلل يحتاج حزمة SYN تحمل خيارات IP، والاتصالات العادية لا تستخدم هذه الخيارات. فإن حجبت حزم TCP الواردة عبر IPv4 التي تحمل خيارات IP، حرمت المهاجم من المدخل الذي يحتاجه. ترويسة IPv4 دون خيارات طولها 20 بايتاً، أي 5 كلمات من 4 بايتات، فأي طول أكبر من 5 يعني أن الحزمة تحمل خيارات. هذه القاعدة نشرتها Red Hat في نشرتها RHSB-2026-016، وتنصح باختبارها على حركة خادمك قبل اعتمادها. ولا تتأثر بها خيارات TCP المعتادة، لأنها في ترويسة TCP لا في ترويسة IP.

# احفظ القاعدة في /etc/nftables.d/cve-2026-98432.nftsudo mkdir -p /etc/nftables.dsudo tee /etc/nftables.d/cve-2026-98432.nft >/dev/null <<'EOF'table inet cve_2026_98432 {    chain input {        type filter hook input priority -310; policy accept;        ip protocol tcp ip hdrlength > 5 counter drop    }}EOF# افحص الملف، ثم حمّله، ثم اعرض الجدول وعدّادهsudo nft --check --file /etc/nftables.d/cve-2026-98432.nftsudo nft --file /etc/nftables.d/cve-2026-98432.nftsudo nft list table inet cve_2026_98432

• القاعدة تعمل فوراً: تسري على الاتصالات الجديدة والقائمة، فلا تحتاج إعادة تشغيل أي خدمة. والعداد counter في نتيجة الأمر الأخير يخبرك كم حزمة حُجبت: إن ارتفع، فهناك من يرسل إلى خادمك حزماً بخيارات IP.
• إن كان خادمك يمرّر حركة إلى حاويات Docker أو LXC: غيّر hook input إلى prerouting، لتمر على القاعدة أيضاً الحزمُ الموجهة إلى الحاويات.
• لا تطبّقها على شبكات CIPSO أو NetLabel: هذه الأنظمة تضع وسوم الأمان في خيارات IP نفسها، فتقطع القاعدة اتصالاتها.
• لتبقى القاعدة بعد إعادة التشغيل: أضف السطر include "/etc/nftables.d/cve-2026-98432.nft" إلى ملف /etc/nftables.conf في Debian وUbuntu، أو إلى /etc/sysconfig/nftables.conf في عائلة RHEL، ثم نفّذ sudo systemctl enable nftables. وانتبه إلى أن إيقاف خدمة nftables لاحقاً يمسح القاعدة، فأعد تحميلها إن أوقفتها.

وإن كان خادمك يعمل بـ iptables وحده، فهذه القاعدة تؤدي العمل نفسه، فتحجب حزم TCP التي يزيد طول ترويستها على 5 كلمات:

# iptables: حزم TCP بترويسة IPv4 أطول من 20 بايتاًsudo iptables -t raw -I PREROUTING -p tcp -m u32 --u32 "0>>24&0x0F=6:15" -j DROP

وإن لم تكن تستخدم Multipath TCP، فعطّله لتغلق الطريق الذي سلكه الاستغلال المعروف. الإعداد يسري على المقابس الجديدة وحدها، فالبرامج التي بدأت قبله تبقى تستمع بـ MPTCP حتى تعيد تشغيلها:

# عطّل MPTCP الآن، واجعل الإعداد دائماًsudo sysctl -w net.mptcp.enabled=0echo 'net.mptcp.enabled = 0' | sudo tee /etc/sysctl.d/99-cve-2026-98432.conf# أعد تشغيل كل خدمة تظهر هنا حتى تصير النتيجة فارغةsudo ss -lnMp# ترحيل طلبات الاتصال يفتح المسار الثاني للخلل: القيمة يجب أن تكون 0sysctl net.ipv4.tcp_migrate_req

تعطيل MPTCP يضيّق الهجوم ولا يزيل الخلل، لأن الخلل ليس خاصاً بـ MPTCP، فلا تكتفِ به عن قاعدة جدار الحماية.

07إن كنت من عملاء إليفانتي

ما تفعله يتوقف على نوع خدمتك:

• خادم CoreVPS: يعمل بتقنية KVM وبنواته الخاصة، المنفصلة عن نواة خوادمنا المضيفة، فتحديثنا لخوادمنا لا يحدّث نواة خادمك. حدّث النواة داخل خادمك وأعد تشغيله كما في الخطوات أعلاه، وخذ قبلها نسخة احتياطية. والنسخ الاحتياطي خارج الخادم متاح لخوادم CoreVPS.
• CoreVPS مع لوحة cPanel: يمكنك أن تضيف إلى خادمك رخصة KernelCare الشهرية، فتصل رقع النواة الأمنية إلى خادمك دون إعادة تشغيل.
• استضافة cPanel: نواة الخادم مسؤوليتنا لا مسؤوليتك: حسابك لا يملك صلاحية تغييرها، وموقعك لا يحتاج أي إجراء منك. وخوادم الاستضافة تعمل بنظام CloudLinux ومعه KernelCare.
• إن احتجت يداً: فريق الدعم الفني معك على مدار الساعة إن احتجت مساعدة في التحديث أو في تطبيق الحماية المؤقتة.

08ما بعد هذه الثغرة

هذه الثغرة لن تكون الأخيرة في النواة. ثلاث عادات تجعل المرة القادمة أسهل:

1. 01موعد ثابت لإعادة التشغيل: تحديث النواة لا يحميك قبل إعادة التشغيل. حدّد موعد صيانة دورياً تعيد فيه تشغيل خوادمك، أو اعتمد الترقيع الحي حيث يتوفر.
2. 02إصدار مدعوم: CentOS 8 وDebian 11 وUbuntu 20.04 وما قبلها لا تصلها إصلاحات مجانية. خطط للانتقال الآن، لا حين تصدر الثغرة التالية.
3. 03جرد للنوى العاملة: اعرف لكل خادم ومضيف حاويات إصدار النواة الذي يعمل الآن، لا المثبّت فقط، فهو ما يحدد إن كنت محمياً.

واشترك في نشرات الأمان لتوزيعتك، فهي أول من يخبرك بصدور الإصلاح، قبل أن تقرأ عنه في الأخبار.