Fragnesia (CVE-2026-46300) تُستغل الآن: هل ما زال مضيف Docker لديك يعمل بالنواة القديمة؟

في 28 أكتوبر 2026 أضافت CISA الثغرة CVE-2026-46300 إلى كتالوج الثغرات المعروفة المُستغلة (KEV). الثغرة هي Fragnesia، وهي ثغرة لرفع الصلاحيات في نواة لينكس كُشف عنها في قائمة oss-security في 13 مايو 2026. ويذكر مدخلها في كتالوج KEV أنه يمكن ربطها بالثغرتين CVE-2026-109618 وCVE-2026-109619 لزرع webshell بلغة PHP وتنفيذ الأوامر بصلاحيات root. هاتان الثغرتان هما PHP2Shell. ثغرة PHP عن بُعد تمنح المهاجم shell بصلاحيات مستخدم خادم الويب، ثم تحوّل Fragnesia هذا الـshell إلى root.

الأنوية المُصلحة متاحة منذ مايو، وهذا بالضبط ما يجعل الخطأ هنا سهلًا. على خادم VPS يعمل بـunattended-upgrades، ربما ثُبّتت حزمة النواة المُصلحة قبل أشهر بينما بقي الجهاز يعمل بالنواة القديمة لأن أحدًا لم يُعد تشغيله. قائمة الحزم تقول إن التصحيح موجود، والنواة العاملة تقول شيئًا آخر. نشرح فيما يلي من المعرّض فعلًا، وكيف تعرف ما تشغّله خوادمك وحاوياتك حقًا، وكيف تُصلح، وما الذي تفحصه إن كان أحد قد سبقك إلى الخادم.

ماذا تفعل Fragnesia

يصف مكتشفوها، William Bowling وفريق V12، الثغرة في تقريرهم العلني بأنها "استغلال شامل لرفع الصلاحيات محليًا في لينكس" داخل شيفرة XFRM ESP-in-TCP. أثناء دمج حزم TCP الواردة، تنسى النواة أن جزءًا من مخزن الشبكة مشترك مع page cache لأحد الملفات (يرجع وصف NVD المشكلة إلى skb_try_coalesce()). بعد ذلك تفك شيفرة ESP تشفير البيانات في مكانها، فوق صفحة الملف المخزنة مؤقتًا. وباختيار قيمة nonce للتشفير يستطيع المهاجم تغيير أي بايت في أي ملف يملك صلاحية قراءته، ويقول التقرير إن ذلك يتم "دون الحاجة إلى أي race condition".

يعيد إثبات المفهوم المنشور كتابة أول 192 بايت من /usr/bin/su في الذاكرة ثم ينفّذه للحصول على shell بصلاحيات root. منحت جهة الترقيم في kernel.org الثغرة درجة CVSS 3.1 تبلغ 7.8 (High). وتضعها صفحة CVE في Ubuntu في أولوية عالية، وتبرر ذلك بأنها "رفع صلاحيات محلي سهل"، وتضيف أن المهاجم "ربما يستطيع الهروب من الحاوية".

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

من المعرّض فعلًا

Fragnesia ثغرة محلية، أي أن المهاجم يحتاج أولًا إلى تشغيل شيفرة على الجهاز. على خادم فريق صغير يأتي ذلك عادة من أحد هذه المصادر:

• تطبيق ويب فيه ثغرة تنفيذ شيفرة عن بُعد تمنح shell بصلاحيات www-data أو مستخدم مشابه. هذه هي السلسلة التي تصفها CISA.
• حاويات شُغّلت بـ--privileged أو --security-opt seccomp=unconfined، ومنها مشغّلات CI التي تبني الصور على خادم الإنتاج نفسه.
• خوادم يملك فيها عدة أشخاص أو عملاء حسابات shell خاصة بهم.

يحتاج الاستغلال إلى إنشاء namespaces. وفق التقرير، يستدعي unshare(CLONE_NEWUSER | CLONE_NEWNET) للحصول على CAP_NET_ADMIN دون أي صلاحيات حقيقية على المضيف. هناك ضابطان موجودان يعترضان هذه الخطوة، ولا يغني أيٌّ منهما عن التصحيح.

الأول هو قيد AppArmor في Ubuntu. يقول الملف README نفسه إن AppArmor في Ubuntu يقيّد user namespaces غير المميزة افتراضيًا، وإن الاستغلال العلني لا يعمل إلا بعد تعطيل هذا القيد. ويقول أيضًا إن ربط ثغرات أخرى يمكن أن يتجاوز هذا الشرط. تحقق من خادمك بالأمر sysctl kernel.apparmor_restrict_unprivileged_userns؛ القيمة 1 تعني أن القيد مفعّل.

الثاني هو ملف seccomp الافتراضي في Docker. جرّبنا ذلك على أحد خوادمنا بنظام Ubuntu 24.04 مع Docker Engine 29.9.2. في حاوية افتراضية فشل الأمر unshare -U -r -n id برسالة "Operation not permitted". ونجح الأمر نفسه في حاوية شُغّلت بـ--security-opt seccomp=unconfined وطبع uid=0(root) داخل الـnamespace الجديد. الحاويات التي تعمل دون seccomp هي أول ما يستحق انتباهك.

الخطوة 1: افحص النواة العاملة، لا النواة المثبتة

الحاوية لا تملك نواة خاصة بها. شغّل docker run --rm alpine uname -r وستحصل على إصدار نواة المضيف. لذلك فالنصيحة المعتادة لثغرات المكتبات، أي إعادة بناء الصور بـdocker build --pull، لا تفيد شيئًا مع Fragnesia. الإصلاح على المضيف، ولا يُحتسب إلا بعد إعادة التشغيل.

على كل خادم، قارن النواة العاملة بما هو مثبت:

uname -r
dpkg -l 'linux-image*' | grep ^ii
cat /var/run/reboot-required.pkgs 2>/dev/null
sudo needrestart -k -b

على خوادم Ubuntu يعرض needrestart -k -b النواة العاملة تحت NEEDRESTART-KCUR وأحدث نواة مثبتة تحت NEEDRESTART-KEXP. إذا اختلفت القيمتان فأنت تعمل بنواة أقدم من تلك الموجودة على القرص. وفي Debian يتضمن ناتج uname -v إصدار حزمة Debian.

ثم قارن بالإصدارات المُصلحة. من صفحة CVE-2026-46300 في Ubuntu:

• Ubuntu 26.04 LTS: مُصلحة في 7.0.0-22.22
• Ubuntu 24.04 LTS: مُصلحة في 6.8.0-124.124
• Ubuntu 22.04 LTS: مُصلحة في 5.15.0-181.191، وفي 6.8.0-124.124~22.04.1 لنواة HWE
• Ubuntu 20.04 LTS: النواة الافتراضية 5.4 مدرجة على أنها غير متأثرة؛ ونواة HWE ذات الإصدار 5.15 مُصلحة في 5.15.0-181.191~20.04.1 عبر Ubuntu Pro
• Ubuntu 26.10: غير متأثرة

ومن متتبع أمان Debian:

• Debian 13 trixie: مُصلحة في 6.12.90-1 (DSA-6295-1)
• Debian 12 bookworm: مُصلحة في 6.1.174-1 (DSA-6306-1)
• Debian 11 bullseye LTS: مُصلحة في 5.10.257-1 (DLA-4606-1)، أو 6.1.174-1~deb11u1 لنسخة linux-6.1 المنقولة (DLA-4607-1)

أنوية السحابة مثل linux-aws أو linux-azure لها أرقام إصدارات خاصة بها، فابحث عن نوع نواتك في صفحة Ubuntu بدل مطابقتها برقم النواة العامة.

الخطوة 2: التصحيح وإعادة التشغيل

إرشادات Canonical الخاصة بـDirty Frag، التي تحيل إليها صفحة Fragnesia في Ubuntu لخطوات التخفيف نفسها، تنتهي إلى ترقية عادية ثم إعادة تشغيل:

sudo apt update && sudo apt upgrade
sudo reboot

ويذكر المقال نفسه أن unattended-upgrades يطبّق التحديثات الأمنية كل 24 ساعة، "لكن إعادة التشغيل تبقى مطلوبة". هذا الجزء الأخير يسهل إغفاله. بعد إعادة التشغيل شغّل uname -r مرة أخرى وتأكد من مطابقته للقائمة أعلاه. ثم شغّل docker ps -a وابحث عن الحاويات التي لم تعد للعمل، وهي عادة تلك التي لا تملك سياسة restart: في ملف compose.

وما دمت على الخادم، اعرض الحاويات التي تعمل دون seccomp أو في الوضع المميز:

docker inspect --format '{{.Name}} privileged={{.HostConfig.Privileged}} {{.HostConfig.SecurityOpt}}' $(docker ps -q) \
  | grep -E 'privileged=true|unconfined'

إذا لم يظهر أي ناتج فلا توجد حاوية عاملة بهذه الإعدادات. وأي حاوية تظهر يجب أن يكون لها سبب مكتوب.

الخطوة 3: إن لم تستطع إعادة التشغيل اليوم

التخفيف المؤقت هو نفسه المستخدم مع Dirty Frag: منع النواة من تحميل الوحدات esp4 وesp6 وrxrpc. هذه الأوامر مأخوذة من مقال Canonical:

echo "install esp4 /bin/false" | sudo tee /etc/modprobe.d/dirty-frag.conf
echo "install esp6 /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf
echo "install rxrpc /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf
sudo update-initramfs -u -k all
sudo rmmod esp4 esp6 rxrpc 2>/dev/null
grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules && echo "Affected modules are loaded" || echo "Affected modules are NOT loaded"

اعرف ما الذي سيتعطل قبل التنفيذ. تحذّر Canonical من أن ذلك يؤثر في عمليات نشر IPsec، وهي "شائعة في شبكات VPN مثل StrongSwan". ولمستخدمي Docker حالة أخرى: شبكات overlay المنشأة بـ--opt encrypted تستخدم تشفير IPsec، لذا ستفقد عناقيد Swarm ذات الشبكات المشفرة هذه الحركة. بعد أن تعمل النواة المُصلحة، احذف الملف /etc/modprobe.d/dirty-frag.conf وشغّل sudo update-initramfs -u -k all مرة أخرى.

الخطوة 4: إن كنت تظن أنها استُغلت بالفعل

يحمل مدخل KEV لهذه الثغرة عبارة أن الفحص الجنائي مطلوب وفق BOD 26-04. هذه القاعدة مُلزمة للجهات الفيدرالية الأمريكية فقط، لكن منطقها ينطبق على الجميع: الخادم الذي شغّل نواة معرّضة بجانب تطبيق PHP مكشوف على الإنترنت يجب فحصه بحثًا عن اختراق، لا تصحيحه فقط.

إعادة التشغيل تزيل page cache المعدّل، لكنها لا تزيل ما كتبه المهاجم على القرص بعد حصوله على root. ابحث عن ملفات PHP في مجلدات الرفع والتخزين المؤقت لم ينشئها تطبيقك، وحسابات جديدة في /etc/passwd، ومفاتيح مجهولة في authorized_keys، ومهام cron أو وحدات systemd جديدة. على خادم لا يستخدم IPsec أبدًا، ظهور esp4 أو esp6 في /proc/modules يستحق نظرة أدق، لأن الاستغلال يُنشئ security association من نوع ESP. اعتبره خيطًا، لا دليلًا.

صلاحية root على مضيف Docker تعني الوصول إلى كل حاوية وكل volume وكل سرّ مُمرّر كمتغير بيئة. إذا وجدت علامات اختراق فأعد بناء الخادم من صورة سليمة بدل تنظيفه، وغيّر بيانات الاعتماد التي كانت عليه. كتبنا عن ترتيب هذا العمل في صحّح أولًا، ثم غيّر كل سرّ كان على الجهاز. وإن كانت نقطة الدخول PHP فإن دليل PHP2Shell يشرح تصحيح PHP داخل صورك. أما السجلات التي غادرت الخادم مسبقًا فهي التي لا يستطيع مهاجم بصلاحيات root تعديلها بصمت، وهذا أحد أسباب إرسالنا سجلات الحاويات إلى stdout ونقلها خارج الخادم.

الأسئلة الشائعة

المصادر: تنبيه KEV من CISA، 28 أكتوبر 2026، كتالوج KEV من CISA، NVD للثغرة CVE-2026-46300، متتبع CVE في Ubuntu، متتبع أمان Debian، سلسلة الإفصاح في oss-security، تقرير Fragnesia من V12، مقال Canonical عن تخفيف Dirty Frag وتوثيق شبكات overlay في Docker. اختُبرت الأوامر في 1 نوفمبر 2026 على Ubuntu 24.04.5 LTS بنواة 6.8.0-147-generic وDocker Engine 29.9.2. لم يُطبّق تخفيف حظر الوحدات على ذلك الخادم.