Fragnesia باختصار: ثغرة من مايو عادت عاجلة
Fragnesia هو الاسم المعطى لـ CVE-2026-46300، وهي ثغرة في نواة لينكس كُشف عنها في 13 مايو 2026 مع إثبات مفهوم علني. يمكن تلخيص الخلل في جملة: الدالة skb_try_coalesce() تفقد العلامة التي تشير إلى جزء مشترك، فيُنفَّذ فك تشفير ESP في المكان نفسه على صفحات من page cache. عندئذ تستطيع عملية بلا صلاحيات أن تعدّل في الذاكرة ملفًا يُفترض أنه للقراءة فقط، مثل /usr/bin/su، وأن تحصل على root. درجة CVSS 3 هي 7.8، وتصنّف Ubuntu الثغرة بأولوية High. الإصلاحات موجودة منذ مايو: وضعتها AlmaLinux في الإنتاج في 16 مايو 2026. ما تغيّر في أواخر أكتوبر 2026 هو السياق، لأن CISA أدرجت الثغرة في كتالوج الثغرات المستغلّة في 28 أكتوبر 2026.
الخلاصة قبل فتح الطرفية
- محلية لا عن بُعد — لا يمكن مهاجمة Fragnesia من الإنترنت: يجب أن ينفّذ المهاجم شيفرة على الجهاز أصلًا. إنها الخطوة التي تلي اختراقًا عبر الويب.
- النواة العاملة لا النواة المثبّتة — حزمة محدّثة لا تحمي شيئًا ما دام الجهاز لم يُعد التشغيل عليها.
- توجد نوى مصححة — نشرت Ubuntu وDebian وAlmaLinux وCloudLinux إصداراتها؛ والجدول أدناه يسردها.
- يوجد حل مؤقت له ثمن — حظر ثلاث وحدات (esp4 وesp6 وrxrpc) يغلق الطريق، لكنه يعطّل IPsec وAFS.
- جسر لا حل — يصمد الحل المؤقت حتى إعادة التشغيل على النواة المصححة، ولا يتجاوز ذلك.
لماذا يغيّر PHP2Shell الجدول الزمني
لا تنطلق ثغرة رفع الصلاحيات المحلية من تلقاء نفسها: تحتاج أولًا إلى نقطة دخول. وعلى خادم وكالة، نقطة الدخول جاهزة: موقع PHP. يشير PHP2Shell إلى ثغرتين في المفسّر هما CVE-2026-109618 وCVE-2026-109619، تتيحان تنفيذ شيفرة دون مصادقة. يعمل الـ webshell عندئذ تحت حساب الموقع، بلا صلاحيات. وFragnesia هي الخطوة التالية: ترفع ذلك الحساب إلى root. تفيد شركة Dream بأنها رصدت هذه التركيبة في حملة استهدفت جدران حماية؛ وهذه رواية جهة واحدة، ولا تؤكدها CISA. أما من جهة CISA، فالثغرة CVE-2026-46300 مدرجة في الكتالوج بموعد نهائي هو 31 أكتوبر 2026 مع طلب فرز جنائي من الوكالات الأمريكية. والأهم أن تتذكر: إصلاح PHP يغلق المدخل لا التصعيد. وخادم زاره مهاجم قبل إصلاح PHP يبقى خطرًا ما دامت نواته غير محدّثة. يتناول دليل PHP2Shell المرتبط أسفل هذا المقال الجزء الأول.
النوى المصححة لكل توزيعة
مرّر الجدول أفقيًا
| التوزيعة | النواة المصححة (أو أحدث) | معلومة مفيدة |
|---|---|---|
| Ubuntu 22.04 LTS | 5.15.0-181.191 | يعرض `uname -r` القيمة 5.15.0-181-generic |
| Ubuntu 24.04 LTS | 6.8.0-124.124 | يعرض `uname -r` القيمة 6.8.0-124-generic |
| Ubuntu 25.10 و26.04 LTS | 6.17.0-35.35 و7.0.0-22.22 | إصدار لكل نسخة؛ النسخة 26.10 غير متأثرة |
| Debian 12 (bookworm) | 6.1.190-1 | مستودع security؛ يعرض `uname -v` إصدار الحزمة |
| Debian 13 (trixie) | 6.12.113-1 | مستودع security؛ القراءة نفسها مع `uname -v` |
| AlmaLinux 8 و9 و10 | 4.18.0-553.124.3.el8_10 ; 5.14.0-611.54.5.el9_7 ; 6.12.0-124.56.3.el10_1 | في الإنتاج منذ 16 مايو 2026 |
| CloudLinux 7h و8 | 4.18.0-553.124.3.lve.el7h ; 4.18.0-553.124.3.lve.el8 | تعتمد CloudLinux 9 و10 نوى AlmaLinux؛ تحقق من قناة التوزيع |
| غير متأثرة | Ubuntu 20.04 LTS وما قبلها، CloudLinux 7 | لا شيء لإصلاحه في هذه النسخ |
النواة المثبّتة ليست النواة العاملة
هذا هو الفخ الذي يحوّل «كل شيء محدّث» إلى خادم ما زال ضعيفًا. تثبيت حزمة نواة يضع ملفات جديدة في /boot، لكن النواة في الذاكرة تبقى نواة آخر إقلاع. وما دام الجهاز لم يُعد التشغيل، قد يعرض apt أو dnf نظامًا محدّثًا بينما يجيب uname -r بالرقم القديم. هذا شائع في أسطول الخوادم لسبب بسيط: لا أحد يحب إعادة تشغيل خادم يحمل مواقع عملاء، فتنتظر إعادة التشغيل. مرجعان يتفادى بهما الالتباس. في Ubuntu يُكتب الرقم في الجدول من جزأين: 5.15.0-181.191 يقابل 5.15.0-181-generic في uname -r. وفي Debian يعرض uname -r واجهة ABI للنواة لا إصدار الحزمة؛ أما uname -v فيعرض الإصدار الكامل، مثل «Debian 6.1.190-1».
تحقق من تعرّض الخادم في عشر دقائق
اقرأ النواة العاملة
uname -rثمuname -v. دوّن النتيجة جهازًا جهازًا: هي القيمة الوحيدة المهمة، لا قيمة مدير الحزم. قارنها بالجدول أعلاه.اسرد النوى المثبّتة
Debian وUbuntu:
dpkg -l 'linux-image*'. AlmaLinux وCloudLinux:rpm -q kernel. إن كانت نواة مصححة مثبّتة بينما يعرضuname -rرقمًا آخر، فالخادم لم يُعد التشغيل: إنه معرّض.اكتشف إعادات التشغيل المعلّقة
في AlmaLinux وCloudLinux يبيّن الأمر
sudo needs-restarting -rهل إعادة التشغيل لازمة. وفي Ubuntu يدل وجود الملف/var/run/reboot-requiredعلى الأمر نفسه.انظر إلى الوحدات المعنية
lsmod | grep -E 'esp4|esp6|rxrpc'. النتيجة الفارغة لا تجعل الخادم آمنًا: فالوحدة الغائبة قد تُحمَّل عند الطلب. هي تقول فقط إنها غير محمّلة في هذه اللحظة.تحقق من rxrpc في AlmaLinux 9 و10
rpm -q kernel-modules-partner. في هاتين النسختين لا تكون وحدة rxrpc معرّضة إلا إذا كانت هذه الحزمة مثبّتة؛ أما AlmaLinux 8 فلا تبني هذه الوحدة.حدّد بوابات VPN
systemctl list-units | grep -Ei 'strongswan|libreswan|ipsec'. أعدّ قائمة بالأجهزة التي تنهي أنفاق IPsec أو تمرّرها، أو التي تستخدم AFS: الحل المؤقت أدناه لا يناسبها.
تحديث النواة حسب البيئة
Debian وUbuntu
sudo apt update && sudo apt full-upgradeثمsudo reboot. نستخدمfull-upgradeلأن النواة الجديدة تصل كحزمة جديدة قد يتركهاupgradeوحده.AlmaLinux وسائر RHEL
sudo dnf clean metadata && sudo dnf upgradeثمsudo reboot. بعد إعادة التشغيل يجب أن يسردrpm -q kernelنواة تساوي على الأقل ما في الجدول.CloudLinux
في CloudLinux 9 و10 تُطبَّق نوى AlmaLinux: الأمر نفسه أعلاه. وفي CloudLinux 7h و8 تكون النواة المصححة نواة CloudLinux تُوزَّع عبر قنوات؛ ويبيّن مقال CloudLinux المرتبط في آخر الصفحة هل تتيحها قناتك. بعد ذلك
sudo yum update 'kernel*'ثمsudo reboot.حاويات Docker
ليس للحاوية نواة خاصة: تستخدم نواة المضيف. إعادة بناء الصورة لا تصلح شيئًا هنا، بينما تحديث المضيف وإعادة تشغيله يحمي جميع حاوياته دفعة واحدة. وتذكر Ubuntu أيضًا إمكان الهروب من الحاوية: لا تؤجّل هذه النقطة. أما صور PHP التي تلزم إعادة بنائها بسبب PHP2Shell فمكانها دليل آخر.
تحقق بعد إعادة التشغيل
يجب أن يعرض
uname -r(وuname -vفي Debian) رقمًا يساوي ما في الجدول أو يفوقه. ثم شغّلsudo systemctl --failedلاكتشاف الخدمات التي لم تعد.
الحل المؤقت أم النواة: القرار حسب دور الخادم
إعادة التشغيل تقطع المواقع، والاعتراض مشروع. ولهذا وُجد الحل المؤقت: يمنع تحميل esp4 وesp6 وrxrpc، وهي الوحدات الثلاث التي تمرّ منها الثغرة، دون إعادة تشغيل. وثمنه محدد. ESP هو بروتوكول التشفير في IPsec، وrxrpc يخدم AFS؛ فإن كان الخادم ينهي أنفاق IPsec (strongSwan وLibreswan) أو يمرّرها أو يركّب AFS، عطّلها الحل المؤقت، وتقول AlmaLinux ذلك بوضوح. قاعدة بسيطة: على خادم ويب بلا VPN طبّق الحل المؤقت فورًا ثم النواة في الموعد القادم؛ وعلى بوابة VPN ركّب النواة المصححة في موعد إعادة تشغيل دون حل مؤقت. وفي الحالتين لا يعدو الحل المؤقت جسرًا حتى إعادة التشغيل على النواة المصححة. وتوضح AlmaLinux أيضًا أن الحل المؤقت المنشور لـ Dirty Frag يغطي Fragnesia أصلًا: إن كان مطبّقًا فلا شيء يُضاف.
طبّق الحل المؤقت، وتحقق منه، وتراجع عنه
اكتب الملف وأزل تحميل الوحدات
sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/fragnesia.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"
ينشئ الأمر/etc/modprobe.d/fragnesia.confالذي يمنع تحميل الوحدات الثلاث، ثم يزيل تحميل ما كان محمّلًا منها.تحقق
يجب ألا يُرجع
lsmod | grep -E 'esp4|esp6|rxrpc'شيئًا. يبقى الحل المؤقت بعد إعادة التشغيل ما دام الملف موجودًا.أفرغ page cache إن كان الجهاز قد استُهدف
sudo sh -c "echo 3 > /proc/sys/vm/drop_caches". تُعاد الملفات التنفيذية من القرص. إن أردت الاحتفاظ بأدلة فأجرِ أولًا فحوص القسم التالي.تراجع عن الحل المؤقت
بعد إعادة تشغيل الجهاز على النواة المصححة:
sudo rm /etc/modprobe.d/fragnesia.conf. وإن كان حل Dirty Frag مطبّقًا مسبقًا باسم ملف آخر فله دورته الخاصة.
KernelCare للخوادم التي لا يمكن إعادة تشغيلها
إن كان الخادم يستخدم KernelCare (ترقيع النواة أثناء التشغيل) فإن kcarectl --update يطبّق الإصلاح دون إعادة تشغيل، ويؤكد kcarectl --patch-info | grep CVE-2026-46300 وجوده. تذكر CloudLinux نشرًا كاملًا لنسخ AlmaLinux ELS وFIPS وعائلة EL8 وDebian 11 و12 وUbuntu Jammy، دون ذكر صريح لـ CloudLinux 9 و10 العاديتين. لا تعمّم: تحقق لكل توزيعة، وإن لم يُرجع الأمر شيئًا فارجع إلى الحل المؤقت أو إلى النواة.
ابحث عن الآثار قبل إعادة التشغيل
الخادم المحدّث منذ مايو غير معني؛ أما الذي لم يُعد التشغيل قط فمعني، وإن حمل موقع PHP ضعيفًا فربما زاره مهاجم. يحدث التعديل في page cache: لا يُكتب بالضرورة على القرص، وتمحوه إعادة التشغيل أو drop_caches. لذا أجرِ فحوصك أولًا. ثلاثة مسارات. ملفات .php الحديثة تحت جذور الويب: sudo find /var/www /home -name '*.php' -mtime -7 -type f، مع تكييف المسارات. الملفات التنفيذية setuid غير المتوقعة: sudo find / -xdev -perm -4000 -type f -mtime -30. سلامة الحزم: rpm -V util-linux في عائلة RHEL، وsudo debsums -s util-linux في Debian وUbuntu بعد apt install debsums؛ فحزمة util-linux توفّر /usr/bin/su، الهدف الذي ذكرته AlmaLinux. النتيجة المريبة لا تُنظَّف يدويًا: اعزل الجهاز وعامله كجهاز مخترق.
للوكالة: موعد مشترك لا خادمًا بعد خادم
لا يضيع الوقت في الأمر نفسه، بل في معرفة أي جهاز يحمل أي عملاء، وأيها بوابة VPN، ومتى يمكن إعادة تشغيله. أعدّ جدولًا لكل خادم: النواة العاملة، النواة المثبّتة، الدور (ويب، VPN، قاعدة بيانات)، هل طُبّق الحل المؤقت. ثم صنّف في ثلاث دفعات: خوادم الويب البسيطة، حل مؤقت فوري ثم النواة في الموعد؛ والبوابات، النواة في الموعد دون حل مؤقت؛ والأجهزة المحدّثة أصلًا، فحص بسيط للنواة العاملة. نبّه العملاء مرة واحدة، في موعد مشترك، بدل جهاز بعد جهاز. وطريقة إعادة تشغيل VPS يحمل مواقع عملاء مفصّلة في دليل PwnEscape وVghost المرتبط أسفل هذا المقال، فلا داعي لتكرارها هنا. هذا الدليل مقدَّم كما هو: إدارة خوادمك تبقى مسؤوليتك، دون دعم من جانبنا.
التوثيق الرسمي
صفحة Ubuntu لـ CVE-2026-46300: https://ubuntu.com/security/CVE-2026-46300
متتبع الأمان في Debian: https://security-tracker.debian.org/tracker/CVE-2026-46300
إشعار AlmaLinux عن Fragnesia: https://almalinux.org/blog/2026-05-13-fragnesia-cve-2026-46300/
مقال CloudLinux (النوى وKernelCare): https://blog.cloudlinux.com/fragnesia-mitigation-and-kernel-update
تنبيه CISA بتاريخ 28 أكتوبر 2026: https://www.cisa.gov/news-events/alerts/2026/10/28/cisa-adds-two-known-exploited-vulnerabilities-catalog
تقرير SecurityWeek عن سلسلة PHP2Shell: https://www.securityweek.com/china-linked-hackers-exploit-php2shell-to-root-firewalls/
الإصلاح في المصدر الأصلي للنواة: https://git.kernel.org/linus/f84eca5817390257cef78013d0112481c503b4a3
