CVE-2026-41940 — cPanel & WHM: تجاوز الجذر غير المصادق عليه عبر حقن CRLF في ملفات الجلسة

تحليل فني معمق موجه للمدافعين

1. الملخص التنفيذي

cPanel & WHM هي البرنامج المهيمن للوحات التحكم في الاستضافة المشتركة واستضافة إعادة البيع. cPanel هي واجهة الحساب الموجهة للعميل؛ WHM هي الواجهة الإدارية على مستوى الجذر التي يستخدمها مزودو الاستضافة وأصحاب الخوادم. يتم تقديم كلتيهما بواسطة نفس البرنامج الخفي Perl، cpsrvd، الذي يستمع على أزواج من المنافذ لكل سطح (cPanel: 2082/2083، WHM: 2086/2087، البريد الإلكتروني: 2095/2096).

تسمح CVE-2026-41940 لمهاجم بدون أي بيانات اعتماد على الإطلاق بالتلاعب بحالة الجلسة على القرص قبل حدوث المصادقة، مما يتسبب في قيام cpsrvd لاحقًا بإعادة تفسير البيانات التي قدمها المهاجم على أنها سمات جلسة مشروعة وموثقة بالكامل وذات صلاحيات جذر. والنتيجة هي اختراق كامل لمستوى الإدارة لكل موقع وحساب مستضاف على الخادم — ليست مشكلة تتعلق بمستأجر واحد، بل مشكلة على مستوى المضيف، ومستوى المزود، وعلى المستوى الإجمالي، على مستوى الصناعة بأكملها، نظرًا لتركيز cPanel في السوق.

2. لماذا هذه الثغرة أكثر أهمية من درجة CVSS الخاصة بها

درجة CVSS البالغة 9.8 شائعة بما يكفي لدرجة أنها قد تصبح مسببة للخدر عند قراءتها. هناك ثلاثة عوامل هيكلية تجعل CVE-2026-41940 شديدة الخطورة بشكل غير عادي في الممارسة العملية:

1. نطاق الانفجار هو الخادم بأكمله، وليس حسابًا. اختراق WHM هو اختراق لجذر النظام. كل حساب عميل، وكل قاعدة بيانات، وكل مفتاح خاص لـ TLS، وكل نسخة احتياطية، وكل منطقة DNS على ذلك الخادم تصبح ضمن النطاق فورًا.

2. كانت ثغرة يوم-صفر حقيقية لمدة شهرين تقريبًا. تضع بيانات KnownHost الاستغلال الأولي حوالي 23 فبراير 2026، أي قبل التصحيح الصادر في 28 أبريل. أي منظمة كانت مكشوفة على الإنترنت خلال تلك الفترة يجب أن تفترض أن الاختراق ممكن، وليس مجرد نظري، ويجب أن تجري تقييمًا بأثر رجعي للاختراق بدلاً من الاعتماد على "لقد قمنا بالتصحيح، لذا نحن بخير."

3. معظم المنظمات المتضررة لا يمكنها تصحيح هذا بنفسها. يتم نشر cPanel عادةً بواسطة مزودي الاستضافة نيابة عن المستأجرين. ليس لدى العملاء النهائيين أي سيطرة على مستوى الكود على الإصلاح ويعتمدون كليًا على وتيرة تصحيح مزود الخدمة الخاص بهم — وهذا هو بالضبط السبب الذي جعل العديد من المضيفين الكبار (Namecheap, KnownHost, HostPapa, InMotion) يختارون بشكل استباقي حظر حركة المرور الواردة إلى المنافذ المتأثرة بدلاً من انتظار كل مستأجر للتحديث.

هذه النقطة الثالثة تستحق التأمل. تسيطر cPanel على ما يقدر بـ94% من سوق لوحات التحكم. خطأ منطقي واحد في كود معالجة الجلسات لبائع واحد أصبح، لفترة أسابيع، ثغرة وصول جذر على مستوى الصناعة بحكم الأمر الواقع. خطر التركيز هذا هو موضوع متكرر يستحق الاستيعاب بشكل مستقل عن هذا CVE المحدد.

3. الخلفية المعمارية

3.1 cpsrvd ونموذج المنفذ

cpsrvd هو برنامج خفي طويل الأمد بلغة Perl يخدم جميع أسطح منتجات cPanel الثلاثة من نفس الملف الثنائي، والأهم من ذلك، من نفس مسار كود معالجة الجلسة:

نظرًا لأن جميع الأسطح الثلاثة تشترك في منطق الجلسة الضعيف، فإن تعرض أي من هذه المنافذ الستة يكفي للاستغلال — لا يوجد سطح "أقل تعرضًا" بشكل ذي معنى بينها. في البيئات المجزأة بشكل جيد، لا ينبغي أن تكون أي من هذه المنافذ قابلة للوصول مباشرة من الإنترنت في المقام الأول؛ في الممارسة العملية، فإن سهولة الإدارة والترتيبات الاستضافة الهجينة وانجراف جدران الحماية تعني أن العديد منها كان كذلك.

3.2 التمثيل المزدوج للجلسة

يتم الاحتفاظ بجلسات cPanel في تمثيلين متوازيين على القرص، على ما يبدو لأسباب تتعلق بالأداء:

1. ملف الجلسة الخام (/var/cpanel/sessions/raw/<session-id>) — تنسيق نص عادي موجه بالأسطر بصيغة key=value، سمة واحدة لكل سطر.
2. ذاكرة التخزين المؤقت JSON (/var/cpanel/sessions/cache/<session-id>، من الناحية النظرية) — مستند JSON منظم، يُقرأ بشكل تفضيلي بواسطة مسار الطلب العادي لأن تحليله أرخص.

تحت التشغيل العادي، تكون ذاكرة التخزين المؤقت JSON هي المرجعية وملف الجلسة الخام هو دعامة للاستمرارية. الثغرة موجودة على وجه التحديد لأنه توجد ظروف يتم فيها إعادة تحليل الملف الخام واستخدامه لتجديد ذاكرة التخزين المؤقت JSON، والتنسيقان يختلفان حول معنى حرف السطر الجديد المضمن.

4. السبب الجذري: أربعة إخفاقات مستقلة تتسلسل معًا

CVE-2026-41940 ليست خطأ واحدًا. إنها نتاج أربعة نقاط ضعف منفصلة، كل منها معقول بشكل فردي كقرار تصميمي معزول، والتي تصطف لإنتاج تجاوز كامل للمصادقة. هيكل "الجبن السويسري" هذا مفيد للمدافعين ومراجعي الكود إلى أبعد من هذا المنتج المحدد.

4.1 الطبقة 1 — التعقيم مفروض بالاتفاقية، وليس بواسطة مسار الكتابة نفسه

كان لدى نظام جلسات cPanel بالفعل روتين تعقيم مسؤول عن إزالة الأحرف الخطرة — إرجاع العربة، وتغذية الأسطر، و = — من قيم الجلسة قبل حفظها. المشكلة هي أين تم استدعاء هذا الروتين: كان يعيش داخل وظائف الغلاف ذات المستوى الأعلى (واجهة برمجة تطبيقات "إنشاء"/"تعديل" الجلسة)، وكانت مسؤولية المستدعي هي التوجيه عبر هذه الأغلفة بدلاً من كتابة بيانات الجلسة مباشرة.

قام معالج مصادقة HTTP الأساسي داخل cpsrvd — مسار الكود الذي يقبل بيانات الاعتماد مباشرة من رأس Authorization HTTP — بحفظ كلمة المرور المقدمة في ملف جلسة ما قبل المصادقة من خلال روتين حفظ منخفض المستوى تجاوز الغلاف المعقم تمامًا. نظرًا لأن التعقيم كان اختياريًا وليس إلزاميًا عند نقطة الكتابة على القرص، فإن هذا المستدعي الواحد تخطاه بصمت.

هذا هو نمط الفشل النموذجي لـ "التحقق عند المصدر، وليس عند المصب": طالما يمكن تجاوز عنصر تحكم أمني ببساطة عن طريق استدعاء وظيفة مختلفة، فسيتم تجاوزه في النهاية، سواء من خلال الإشراف، أو إعادة الهيكلة، أو مسار كود لم يفكر أحد في تدقيقه ضد هذا التحكم المحدد. الإصلاح الدائم الذي أصدرته cPanel ينقل استدعاء التعقيم داخل وظيفة الحفظ نفسها، بحيث لا يمكن لأي مستدعي، حاضرًا أو مستقبليًا، تخطيه بعد الآن.

4.2 الطبقة 2 — تشفير يمكن تعطيله بواسطة المدخلات التي يتحكم فيها المهاجم

يقوم كاتب الجلسة بتشفير الحقول الحساسة (لا سيما حقل كلمة المرور) باستخدام مفتاح متماثل لكل جلسة. هذا المفتاح مشتق من مكون مضمن في ملف تعريف ارتباط الجلسة الذي يقدمه العميل. في الكود الضعيف، إذا كان مكون المفتاح هذا غائبًا عن الطلب — وهو أمر يقع بالكامل تحت سيطرة المهاجم، لأنه يختار ملف تعريف الارتباط الذي يرسله — تم تخطي خطوة التشفير بصمت بدلاً من رفض الكتابة.

بعبارة أخرى: المهاجم الذي يحذف عمدًا أو يبتلع جزءًا من ملف تعريف ارتباط الجلسة الخاص به يمكن أن يتسبب في كتابة بياناته المقدمة على القرص بدون تشفير. التشفير الذي يمكن تبديل تنشيطه عن طريق الطرف غير الموثوق الذي يزود المدخلات ليس حدًا أمنيًا ذا معنى؛ يجب أن يفشل مغلقًا (رفض الحفظ، أو رفض الطلب) بدلاً من أن يفشل مفتوحًا (الحفظ دون حماية).

4.3 الطبقة 3 — اختلاف التنسيق بين الملف الخام وذاكرة التخزين المؤقت JSON

هذا هو جوهر "الحقن" في حقن CRLF. ملف الجلسة الخام محدد بالأسطر: تسلسل إرجاع العربة / تغذية السطر ينهي سجل key=value ويبدأ السجل التالي. تنسيق ذاكرة التخزين المؤقت JSON، على النقيض من ذلك، يمثل نفس تسلسل الأحرف كسلسلة فرعية مفلترة داخل قيمة سلسلة JSON واحدة — غير ضارة دلاليًا، مجرد بيانات.

طالما توجد الجلسة فقط في ذاكرة التخزين المؤقت JSON، فإن CRLF المضمن في حقل مثل كلمة المرور غير ضار — إنها مجرد بايتات داخل سلسلة. يظهر الخطر في مسار الكود الذي يعيد تحليل الملف الخام ويجدد ذاكرة التخزين المؤقت. يحدث هذا، وفقًا للتحليلات الفنية العامة، عندما يتم رفض طلب لفشله في فحص رمز الأمان المرتبط بعنوان URL؛ المعالج المسؤول عن هذا الرفض يعيد تحميل الجلسة عن طريق تجاوز ذاكرة التخزين المؤقت وإعادة قراءة الملف الخام سطرًا بسطر، ثم يعيد كتابة ذاكرة التخزين المؤقت JSON من ذلك التحليل.

في تلك اللحظة، تتوقف تسلسلات CRLF التي قام المهاجم بتضمينها في "كلمة المرور" المقدمة عن كونها بايتات غير ضارة داخل حقل واحد وتصبح فواصل سجلات، تقسم ما كان يجب أن يكون قيمة واحدة إلى عدة أسطر key=value مستقلة. كل من هذه الأسطر — بما في ذلك تلك التي يتحكم المهاجم بالكامل في اسمها وقيمتها — يتم بعد ذلك ترقيتها إلى إدخال من المستوى الأعلى في ذاكرة التخزين المؤقت JSON المجددة للجلسة، لا يمكن تمييزه عن بقية قاعدة الكود عن سمة جلسة تم تعيينها بشكل شرعي.

الدرس العام: كلما أمكن جعل محللين يفسران نفس تسلسل البايت بشكل مختلف — خام مقابل ذاكرة تخزين مؤقت، مشفر بنموذج مقابل JSON، اصطلاح هروب مقابل آخر — فإن هذا الخلاف هو أساس حقن كامن. لا يهم أي محلل "أكثر صحة"؛ المهم هو أن البيانات غير الموثوقة يمكن أن تعبر بين التمثيلين دون إعادة التحقق منها مقابل قواعد المحلل الثاني.

4.4 الطبقة 4 — علامة "تمت المصادقة بالفعل" بدون ربط تشفيري

الحلقة الأخيرة في السلسلة موجودة في منطق التحقق من كلمة المرور نفسه. إذا كانت الجلسة تحمل بالفعل حقلاً يسجل طابعًا زمنيًا حديثًا للمصادقة الداخلية الناجحة، يتم تخطي تحدى كلمة المرور تمامًا — وجود هذا الحقل وحده يعتبر دليلاً كافيًا على أن المصادقة قد نجحت بالفعل. علامة مصاحبة للتحقق من عاملين (2FA) تقمع أيضًا تحدى 2FA استنادًا فقط إلى وجودها.

كلا الحقلين موجودان لأغراض داخلية مشروعة (عمليات تسليم الدخول الموحد بين مكونات cPanel، والأدوات الداخلية التي قامت بالفعل بالتحقق من صحة المستخدم من خلال وسيلة أخرى). عيب التصميم هو أن أيًا من الحقلين غير مرتبط تشفيريًا بأي حدث مصادقة فعلي — إنهما مجرد سمات جلسة عادية يمكن، بمجرد أن تسمح الطبقة 3 للمهاجم بكتابة سمات جلسة عشوائية، تزويرهما ببساطة. علامة تعني "ثق بي، تم التحقق من هذا بالفعل" تكون ذات معنى فقط إذا لم يكن من الممكن تعيينها من قبل الطرف الذي يتم الوثوق به.

4.5 التأثير المركب

لا شيء من نقاط الضعف الأربعة هذه كارثي بشكل مستقل:

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

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

5. تدفق الهجوم المفاهيمي

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

من المرحلة 5 فصاعدًا، يمتلك المهاجم وصولًا عاديًا ومرخصًا بالكامل لواجهة برمجة تطبيقات WHM. مجموعة ميزات WHM المشروعة — الخطافات المخصصة، إدارة الحزم/القوالب، تكوين معالج PHP، إدارة كرون والحسابات، تحرير منطقة DNS — هي أكثر من كافية لتصعيد هذا إلى تنفيذ أوامر جذر تفاعلي من خلال وظائف إدارية "مدعومة" بالكامل، دون حاجة لثغرة أخرى.

تشير التقارير العامة إلى أن السلسلة من البداية إلى النهاية تتطلب فقط عددًا صغيرًا من طلبات HTTP وتتضمن حالة سباق حميدة حول ترتيب المفاتيح العشوائي غير الحتمي لـ Perl أثناء تجديد ذاكرة التخزين المؤقت — مما يعني أن عددًا صغيرًا من إعادة المحاولة قد يكون ضروريًا للموثوقية الكاملة، وهي تفاصيل ذات قيمة كشفية (انظر §7.3).

6. الجدول الزمني

7. هندسة الكشف

7.1 مؤشرات قائمة على نظام الملفات (أعلى إشارة)

أقوى دليل يعيش في مخزن الجلسات الخام نفسه، /var/cpanel/sessions/raw/. الجلسة التي نشأت من محاولة تسجيل دخول فاشلة أو غير مميزة لا ينبغي أبدًا أن تحتوي بشكل شرعي على أي من الحقول التالية من المستوى الأعلى:

• user=root
• hasroot=1
• tfa_verified=1
• successful_internal_auth_with_timestamp=<قيمة>

... ما لم تكن تلك الجلسة قد أكملت بالفعل مصادقة جذر حقيقية وتحدي 2FA من خلال تدفق تسجيل الدخول العادي. وجود هذه الحقول على جلسة تظهر بياناتها الوصفية الأصلية محاولة كلمة مرور فاشلة هو مؤشر قوي على الاستغلال.

إشارة ذات ثقة أعلى: أسطر pass= متعددة داخل ملف جلسة واحد. تحت التشغيل العادي، تحتوي الجلسة على حقل كلمة مرور واحد بالضبط. لا يتم إنتاج التكرارات المتعددة إلا من خلال سلوك تقسيم CRLF الكامن وراء هذه الثغرة ويجب التعامل معها كمؤشر شبه مؤكد على الاختراق.```bash

Sessions carrying privileged top-level fields

grep -lE '^(hasroot|tfa_verified|successful_internal_auth_with_timestamp)=1'
/var/cpanel/sessions/raw/* 2>/dev/null

Sessions with an embedded carriage return inside the password field

(indicative of CRLF-split injection rather than a single legitimate value)

grep -lP 'pass=.\r' /var/cpanel/sessions/raw/ 2>/dev/null

Sessions with more than one "pass=" line — should never legitimately occur

for f in /var/cpanel/sessions/raw/*; do n=$(grep -c '^pass=' "$f" 2>/dev/null) [ "${n:-0}" -gt 1 ] && echo "SUSPECT: $f ($n pass= lines)" done

### 7.2 ترابط سجلات الوصول (عندما لا يتم إرسال ملفات الجلسة مركزيًا)

إذا لم يتم الاحتفاظ بملفات الجلسة الخام لمدة كافية، أو لم يتم إرسالها إلى نظام تسجيل مركزي، يمكن لسجلات الوصول من `cpsrvd` أن تحل محلها. هناك نمطان مفيدان للترابط:

**النمط أ — محاولة تسجيل دخول فاشلة متبوعة فورًا برأس Basic-auth غير مناسب.** لا يرسل العميل العادي رأس `Authorization: Basic` في طلب إلى URL عشوائي غير خاص بتسجيل الدخول مباشرة بعد إرسال POST لكلمة مرور فاشلة من نفس المصدر. هذه التسلسل — استجابة `401` على نقطة تسجيل الدخول متبوعة خلال فترة زمنية قصيرة بطلب يحمل Basic-auth في مكان آخر، مترابطة حسب مصدر IP و/أو ملف تعريف ارتباط الجلسة — هو أمر شاذ ويستحق التنبيه.

**النمط ب — رمز من نمط `cpsess` يظهر في URL قبل أن يتم إصداره بشكل شرعي.** يتم إنشاء رموز الأمان المشروعة لكل جلسة من جانب الخادم وتظهر لأول مرة في استجابة `Set-Cookie`/إعادة التوجيه *قبل* استخدامها في عناوين URL للطلبات اللاحقة. الرمز الذي يظهر في URL طلب وارد دون حدوث إصدار سابق من الخادم مطابق له يتعارض مع سلوك العميل العادي ويستحق الإشارة، خاصة إذا كان الرمز لا يتطابق مع التنسيق المتوقع من الخادم.

### 7.3 إشارة سلوكية / إعادة المحاولة

نظرًا لأن إعادة توليد الذاكرة المؤقتة تخضع للترتيب غير الحتمي لمفاتيح هاش في بيرل، لوحظ أن الاستغلال الناجح في الميدان قد يتطلب أحيانًا عددًا صغيرًا من إعادة المحاولة قبل أن "تنتصر" الحقول المطلوبة في الذاكرة المؤقتة المعاد توليدها. دفعة قصيرة من الطلبات المتشابهة هيكليًا (نفس المصدر، نفس الجلسة، نفس نمط URL الهدف، تحدث في غضون ثوانٍ من بعضها البعض) متبوعة فورًا باستخدام ناجح لواجهة برمجة تطبيقات إدارية هي إشارة تأكيد ثانوية تستحق الترجيح إلى جانب §7.1 و §7.2 — بمفردها عامة جدًا بحيث لا يمكن التنبيه عليها، ولكنها تعزز الثقة عند دمجها مع مؤشرات نظام الملفات أو سجلات الوصول أعلاه.

### 7.4 مؤشرات ما بعد الاختراق

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

- حسابات مستخدمين غير متوقعة على مستوى WHM/الجذر أو حسابات تاجر تم إنشاؤها خارج عمليات إدارة التغيير
- مفاتيح SSH عامة جديدة أو غير معروفة في ملفات `~/.ssh/authorized_keys` الخاصة بـ `root` أو أي حساب مستضاف
- إدخالات cron غير معروفة، على مستوى النظام وعلى مستوى كل حساب مستضاف
- خطافات WHM مخصصة لم يتم توفيرها من قبل مسؤولين معروفين
- تغييرات غير متوقعة في تكوين معالج PHP، أو تعريفات الحزم/القوالب، أو ملفات مناطق DNS
- اتصالات صادرة أو عمليات تعمل كجذر لا تتطابق مع خدمات cPanel/WHM المعروفة

---

## 8. دليل التخفيف والاستجابة للحوادث

### 8.1 إجراءات فورية

1. **احصر** كل مثيل cPanel/WHM/WP Squared تحت سيطرتك أو سيطرة مزود الخدمة الخاص بك.
2. **حدد التعرض للإنترنت** لكل مثيل خلال فترات الكشف وما قبل الكشف (تعامل مع 23 فبراير – 28 أبريل 2026 كنافذة التعرض المثيرة للقلق).
3. **طبق التصحيح إلى إصدار مُصلَح:**

   | الفرع | أقل إصدار تم تصحيحه |
   |---|---|
   | 11.110.0.x | 11.110.0.97 |
   | 11.118.0.x | 11.118.0.63 |
   | 11.126.0.x | 11.126.0.54 |
   | 11.132.0.x | 11.132.0.29 |
   | 11.134.0.x | 11.134.0.20 |
   | 11.136.0.x | 11.136.0.5 |
   | WP Squared | 11.136.1.7 |

4. **تحقق** من الإصدار المطبق باستخدام `/usr/local/cpanel/cpanel -V`.
5. **أعد تشغيل `cpsrvd`** بعد التصحيح — قد يستمر البرنامج الخفي غير المعاد تشغيله في تشغيل كود ضعيف في الذاكرة (`/scripts/restartsrv_cpsrvd`).
6. إذا كنت تعتمد على مضيف تابع لجهة خارجية، **تأكد من حالة التصحيح مباشرة مع المزود** بدلاً من افتراض أنه تم تطبيقه.
7. الخوادم التي تم **تعطيل التحديث التلقائي أو تثبيت الإصدار** لن تتعافى ذاتيًا — تتطلب هذه تدخلًا يدويًا صريحًا ويجب إعطاؤها أولوية، لأنها إحصائيًا الأكثر عرضة لكونها لا تزال ضعيفة.

### 8.2 قصير المدى (في غضون أيام من التصحيح)

- شغّل استعلامات الكشف المستندة إلى نظام الملفات والسجلات من §7 ضد نافذة التعرض الكاملة، وليس فقط "منذ أن لاحظنا".
- دقق WHM بحثًا عن حسابات غير متوقعة، ومفاتيح SSH، وإدخالات cron، وخطافات مخصصة.
- تحقق من سلامة ملفات `/etc/` و `/usr/local/cpanel/` وتكوين شل الجذر/ملفات `authorized_keys` مقابل خطوط أساس معروفة وجيدة أو نسخ احتياطية.
- قم بتدوير كلمات مرور WHM للجذر والتجار، ورموز API، ومفاتيح SSH **بغض النظر عما إذا تم العثور على مؤشرات اختراق** — نظرًا لنافذة الاستغلال التي تبلغ شهرين قبل الكشف، فإن غياب الأدلة ليس دليلاً قويًا على الغياب على مضيف كان معرضًا طوال تلك الفترة.
- قم بتنظيف حالة الجلسة (`/var/cpanel/sessions/raw/` ودليل ذاكرة التخزين المؤقت JSON) بعد التصحيح، بحيث لا يمكن إعادة تشغيل أي جلسات مزورة متبقية.

### 8.3 تعزيز طويل المدى

- قيّد الوصول الوارد إلى منافذ cPanel/WHM/Webmail (2082, 2083, 2086, 2087, 2095, 2096) لنطاقات IP إدارية معروفة عبر قائمة السماح لجدار الحماية. لا ينبغي أن تكون منافذ مستوى الإدارة هذه متاحة على نطاق واسع عبر الإنترنت في ظل ظروف التشغيل العادية.
- قم بإعادة توجيه سجلات الوصول لـ `cpsrvd` — ومن الناحية المثالية أحداث كتابة الجلسة — إلى SIEM محتفظ به مركزيًا، نظرًا لأن ملفات الجلسة على المضيف مؤقتة ويمكن فقدانها بسهولة أثناء الفرز إذا لم يتم الاحتفاظ بها بسرعة.
- أنشئ جردًا أساسيًا لحسابات WHM المتوقعة ومفاتيح SSH ووظائف cron، وراقب أي انحراف.
- تتبع إصدار cPanel/WHM وإيقاع التصحيح كمقياس لإدارة الأصول من الدرجة الأولى، خاصة لأي مثيلات مُدارة ذاتيًا (غير مستعان بمصادر خارجية).

### 8.4 إذا تم تأكيد الاختراق

- **لا تحاول إجراء معالجة في المكان لمضيف تم اختراق جذره.** بمجرد الحصول على صلاحيات الجذر، كان لدى المهاجم القدرة على تعديل أي شيء، بما في ذلك الأدوات التي ستستخدمها للتحقيق. تعامل مع "التنظيف" في المكان على أنه غير موثوق.
- **أعد البناء من صور معروفة بأنها نظيفة ومصححة** بدلاً من التصحيح والاستمرار في تشغيل النظام الذي قد يكون مخترقًا.
- **قم بتدوير جميع بيانات اعتماد الإدارة** على مستوى الخادم، وليس فقط تلك المتورطة مباشرة.
- **استبدل جميع مفاتيح SSH**، بما في ذلك تلك التابعة لحسابات العملاء المستضافة، حيث يمكن للمهاجم على مستوى الجذر أن يكون قد حصد أو زرع أيًا منها.
- **افترض أن جميع بيانات العملاء المستضافة على الجهاز قد تم كشفها** واتبع التزامات الإخطار بالاختراق المعمول بها.
- **حقق في الحركة الجانبية** إلى قطاعات الشبكة الداخلية المجاورة، نظرًا لأن البنية التحتية للاستضافة المخترقة هي نقطة محورية شائعة إلى بيئات الشركات (على سبيل المثال، عبر بيانات الاعتماد، أو علاقات الثقة SSH، أو الأسرار المشتركة المعاد استخدامها في أماكن أخرى).

---

## 9. الأسئلة الشائعة

**هل هذا قابل للانتشار الدودي / مناسب للاستغلال الآلي الجماعي؟**
السلسلة الأساسية غير موثقة بالكامل وتتضمن عددًا صغيرًا ثابتًا من طلبات HTTP، وهذا هو السبب في أن CISA رفعته إلى حالة KEV ولماذا ظهرت أدوات المسح الجماعي التي تشير إلى CVE هذا بالفعل علنًا. تعامل مع أي مثيل غير مصحح يمكن الوصول إليه عبر الإنترنت على أنه في خطر نشط من الاختراق الآلي الانتهازي، وليس مجرد هجوم مستهدف.

**هل تحمي المصادقة ذات العاملين من هذا؟**
لا. يقوم الحقن مباشرة بتزوير علامة الجلسة "تم التحقق من المصادقة الثنائية بالفعل"، وبالتالي لا يتم تقديم تحديث المصادقة الثنائية على الإطلاق. لا توفر المصادقة الثنائية أي تخفيف لهذه الثغرة المحددة.

**هل سيكتشف جدار حماية تطبيق الويب (WAF) الخاص بي هذا؟**
فقط إذا كان يقوم بتطبيع/فحص حمولات `Authorization: Basic` بحثًا عن تسلسلات CRLF مضمنة *و* يفحص بشكل منفصل ملفات تعريف ارتباط الجلسة بحثًا عن النمط المشوه/المبتور المرتبط بحالة تخطي التشفير. لم تكتشف مجموعات قواعد WAF العامة بشكل عام الاستغلال قبل الكشف لهذه المشكلة. يظل التصحيح إلزاميًا بغض النظر عن وضع WAF.

**هل يؤثر هذا على نشر cPanel DNSOnly؟**
نعم، وفقًا لإرشادات البائع — تثبيتات DNSOnly ضمن النطاق.

**هل الإصدارات الأقدم غير المدعومة (قبل 11.40) من cPanel متأثرة؟**
لا — وفقًا للتحليل العام، لم يكن مسار الكود الضعيف موجودًا في الإصدارات السابقة لفرع 11.40، نظرًا لأن الإصدارات القديمة غير المدعومة تسبق تنفيذ معالجة الجلسة ذي الصلة.

**هل يوجد حل بديل متاح إذا لم أتمكن من التصحيح فورًا؟**
لا يوجد حل بديل وظيفي يغلق الثغرة بالكامل دون التصحيح. التخفيف المؤقت الفعال الوحيد هو حظر الوصول الوارد إلى المنافذ المتأثرة (2082/2083, 2086/2087, 2095/2096) عند محيط الشبكة، أو إيقاف خدمات `cpsrvd`/`cpdavd` بالكامل، وكلاهما يأتي على حساب الوصول المشروع أيضًا.

---

## 10. دروس أوسع لهندسة البرمجيات والأمن

بغض النظر عن cPanel على وجه التحديد، هذه الثغرة هي دراسة حالة مفيدة لأي شخص يراجع كود المصادقة ومعالجة الجلسات في أماكن أخرى:

1. **قم بالتعقيم عند نقطة الثبات، وليس وفقًا لتقدير المتصل.** أي عنصر تحكم أمني يمكن تجاوزه بمجرد استدعاء وظيفة مختلفة في نفس النظام الفرعي سيتم تجاوزه في النهاية — سواء من قبل مهاجم يجد الفجوة، أو مهندس مستقبلي لا يعلم بوجودها.
2. **يجب أن تفشل عناصر التحكم الأمنية في الحالة المغلقة عند فقدان الإدخال أو تشوهه، ولا تفشل أبدًا في الحالة المفتوحة.** إذا كانت عملية تشفير تعتمد على مواد يقدمها العميل، فيجب أن يؤدي غياب تلك المواد إلى إحباط العملية، وليس تخطي الحماية التي كان من المفترض أن توفرها بصمت.
3. **كل تمثيل مزدوج لنفس البيانات هو بدائية تهريب محتملة.** أينما يحتفظ النظام بتسلسلين لنفس الحالة (خام مقابل مخبأ، مشفر بالنموذج مقابل JSON، مهرب مقابل غير مهرب) ويعيد اشتقاق أحدهما من الآخر لاحقًا، دقق في مسار إعادة الاشتقاق هذا تحديدًا بحثًا عن الحالات التي يمكن أن تعبر فيها البيانات غير الموثوقة الحدود دون تصفية.
4. **يجب ربط علامات الثقة تشفيريًا بالحدث الذي تؤكده، وليس مجرد وجودها.** سمة جلسة تعني "نجحت المصادقة بالفعل" تكون آمنة فقط إذا لم يتمكن المهاجم من تعيين تلك السمة بشكل مستقل — عبر توقيع أو MAC أو ربط مكافئ لحدث المصادقة الفعلي، وليس من خلال تخزين غير موثق.
5. **أي شيء يُكتب على القرص نتيجة لطلب غير موثق يجب معاملته على أنه تحت سيطرة المهاجم**، بما في ذلك البيانات التي لا تُقرأ إلا من قبل مسارات كود *أخرى* تبدو غير مرتبطة. الخطر في هذه الثغرة لم يكن في الكود الذي كتب البيانات — بل في مسار كود مختلف تمامًا ولاحق أعاد تفسيرها تحت قواعد تحليل مختلفة.

---

## 11. المراجع

- إعلان أمني من cPanel — *ثغرة حرجة في مصادقة تسجيل الدخول إلى cPanel وWHM*، 28 أبريل 2026 — `docs.cpanel.net/release-notes/release-notes`
- مختبرات watchTowr — التحليل الأصلي للسبب الجذري وإثبات المفهوم، سينا خيرخاه، 29 أبريل 2026 — `labs.watchtowr.com`
- Rapid7 — تقرير التهديد الناشئ حول CVE-2026-41940 — `rapid7.com`
- Arctic Wolf — ملخص التهديد CVE-2026-41940 — `arcticwolf.com`
- Hadrian — *CVE-2026-41940: تجاوز مصادقة حرج في cPanel* — `hadrian.io`
- Picus Security — *شرح CVE-2026-41940: تجاوز مصادقة cPanel وWHM الذي أثر على 1.5 مليون خادم* — `picussecurity.com`
- إدخال كتالوج الثغرات المستغلة المعروفة (KEV) لـ CISA لـ CVE-2026-41940 — `cisa.gov`
- BleepingComputer, The Hacker News, CyberScoop — تغطية متزامنة للكشف والاستغلال في البرية
- سجل تغييرات WP Squared — `docs.wpsquared.com/changelogs`
- استشارة مجتمع KnownHost التي توثق الاستغلال المشتبه به قبل الكشف