ثغرة Watchdog API في Phusion Passenger: صلاحيات روت على سيرفرات cPanel

أعلنت cPanel في 14 أغسطس 2026 عن ثغرة أمنية في Watchdog API الخاص بـ Phusion Passenger — تطبيق السيرفر المسؤول عن تشغيل تطبيقات Ruby و Node.js و Python خلف Apache أو NGINX.

تأثير الثغرة سطر واحد قصير وغير مريح على الإطلاق: تصعيد صلاحيات محلي (Local Privilege Escalation).

الإعلان الرسمي يحمل الجملة التي تجعل معظم مديري السيرفرات يتجاوزون الخبر بالكامل: “هذه الثغرة لا تؤثر على التثبيتات الافتراضية لـ cPanel”. وهذه بالضبط النقطة التي يجب التوقف عندها — لأن “ليست افتراضية” لا تعني “نادرة”، بل تعني “اختيارية”. والحزم الاختيارية هي تحديدًا التي لا أحد يتذكر أنه ثبّتها، ولا أحد يوثّقها، ولا أحد يحدّثها.

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

لماذا كلمة “محلي” هي الأخطر في بيئة الاستضافة المشتركة؟

إذا كنت تدير سيرفرًا مخصصًا لتطبيق واحد، فإن عبارة “تصعيد صلاحيات محلي” تبدو خطورتها متوسطة: المهاجم يحتاج أولًا إلى موطئ قدم داخل النظام.

أما على سيرفر استضافة مشتركة، فالجملة تحمل معنى مختلفًا تمامًا.

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

هذا هو نموذج الخطر بالكامل:

• إضافة WordPress قديمة على حساب عميل واحد
• أو بيانات دخول مسربة من قاعدة بيانات مخترقة
• أو سكربت رفع ملفات غير آمن على حساب عشوائي

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

لهذا السبب تحديدًا، هذه الثغرة تعني شركات الاستضافة والبيئات متعددة المستخدمين أكثر بكثير مما تعني من يشغّل VPS لموقع واحد.

ملاحظة: لم يُنشر حتى كتابة هذه السطور معرّف CVE رسمي للثغرة، ولم تنشر cPanel تفاصيل تقنية عن آلية الاستغلال وهو القرار الصحيح أمنيًا. لكن هذا يعني أيضًا أن التعامل مع التحديث يجب أن يكون فوريًا، لا انتظارًا لظهور Proof of Concept على منصات التواصل.

أولًا: هل الحزم مثبتة عندك أصلًا؟

لا تعتمد على الذاكرة. افحص.

على CentOS / AlmaLinux / CloudLinux:

bash

rpm -q ea-apache24-mod-passenger ea-passenger-src ea-ruby27-rubygem-passenger ea-ruby27-mod_passenger ea-ruby24-rubygem-passenger ea-ruby24-mod_passenger ea-nginx-passenger

على Ubuntu:

bash

dpkg-query -W -f='${Package} ${Version}\n' ea-apache24-mod-passenger ea-passenger-src ea-ruby27-rubygem-passenger ea-ruby27-mod_passenger ea-ruby24-rubygem-passenger ea-ruby24-mod_passenger ea-nginx-passenger

إذا كانت النتيجة أن جميع الحزم غير مثبتة (not installed)، فأنت خارج نطاق الخطر ويمكنك التوقف هنا.

أما إذا ظهرت أي حزمة برقم إصدار، فسجّل الرقم الذي ظهر لك — ستحتاج مقارنته بجدول الإصدارات المُرقّعة بعد قليل، ثم أكمل القراءة.

---

جدول الحزم المتأثرة والإصدارات المُرقّعة

الحزمة	الإصدار المُرقّع
ea-apache24-mod-passenger	6.1.8-2
ea-passenger-src	6.1.8-2
ea-nginx-passenger	6.1.8-2
ea-ruby27-rubygem-passenger	6.0.27-2 على EL7 — 6.1.8-2 على EL8
ea-ruby27-mod_passenger	6.0.27-2 على EL7 — 6.1.8-2 على EL8
ea-ruby24-rubygem-passenger	6.0.20-4
ea-ruby24-mod_passenger	6.0.20-4

أي إصدار أقدم من هذه الأرقام يُعد إصدارًا مصابًا.

---

ثانيًا: التحديث

الطريقة المباشرة، وهي الأنسب على معظم سيرفرات cPanel:

bash

/scripts/update-packages

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

CentOS 7 / CloudLinux 7:

bash

yum update ea-apache24-mod-passenger ea-nginx-passenger ea-ruby27-rubygem-passenger ea-ruby27-mod_passenger ea-ruby24-rubygem-passenger ea-ruby24-mod_passenger

AlmaLinux / CloudLinux 8 و 9 و 10:

bash

dnf update ea-apache24-mod-passenger ea-nginx-passenger ea-ruby27-rubygem-passenger ea-ruby27-mod_passenger ea-ruby24-rubygem-passenger ea-ruby24-mod_passenger

Ubuntu:

bash

apt update && apt install --only-upgrade ea-apache24-mod-passenger

بعد الانتهاء، أعد تنفيذ أمر rpm -q أو dpkg-query وتأكد من مطابقة الإصدارات للجدول أعلاه.

إذا بقيت حزمة على إصدار أقدم بعد التحديث، فالمشكلة غالبًا في المستودعات لا في Passenger نفسه. تحقق من أن مستودعات EasyApache مفعّلة، وابحث عن سطر exclude= في إعدادات yum/dnf — غالبًا أضافه أحدهم أثناء حل مشكلة غير ذات صلة قبل سنتين ونسي إزالته.

---

ثالثًا: هل حاول أحد استغلالها قبل التحديث؟

هذه هي الخطوة التي يتخطاها معظم الناس، وهي الأهم فعليًا — لأن التحديث وحده لا يخبرك بشيء عن الماضي.

إذا كانت Passenger مثبتة ومتاحة على سيرفرك قبل التحديث، فهناك نافذة زمنية كانت مفتوحة. ومدة هذه النافذة تساوي المدة التي بقيت فيها الحزم غير محدّثة — ولا يحق لك افتراض أنها كانت قصيرة.

يمكنك البحث في سجلات أخطاء Apache عن مؤشرين محددين:

bash

grep -E 'API account database is empty|Authentication failed for UID' /etc/apache2/logs/error_log /usr/local/apache/logs/error_log 2>/dev/null

اقرأ هذه الفقرة بتركيز — فهي أكثر نقطة سيسيء الجميع فهمها

النتيجة النظيفة لا تعني أنك لم تكن مستهدفًا.

هذه السطور لا تُكتب في السجلات إلا عند رفع مستوى تسجيل Passenger. وفي الإعداد الافتراضي، مستوى التسجيل ليس مرتفعًا بما يكفي لتظهر أصلًا.

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

تعامل مع النتيجة النظيفة على أنها “لا يوجد دليل”، وليست “لا يوجد اختراق”. العبارتان ليستا واحدة، والخلط بينهما هو ما يجعل تقارير ما بعد الحوادث محرجة.

رفع مستوى التسجيل لالتقاط أي محاولات مستقبلية

من خلال WHM:

1. اذهب إلى Home → Service Configuration → Apache Configuration → Include Editor
2. من قسم Pre Main Include اختر All Versions
3. أضف السطر التالي:

apache

PassengerLogLevel 4

4. اضغط Update، ثم Restart Apache في الصفحة التالية.

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

---

ماذا تفعل إذا ظهرت نتائج فعلية؟

لا تحدّث الحزم وتمضي. ظهور تلك السطور يعني احتمال اختراق بصلاحيات الروت، واختراق الروت لا يُعالَج بتحديث حزمة — التحديث يغلق الباب، لكنه لا يُخرج من دخل بالفعل.

كحد أدنى، قبل أن تقنع نفسك بأن السيرفر سليم:

• افحص /etc/passwd بحثًا عن حسابات بصلاحية UID 0 لا يُفترض وجودها
• راجع /etc/sudoers ومجلد /etc/sudoers.d/ بحثًا عن أي إدخالات لم تكتبها بنفسك
• افحص ملفات authorized_keys لجميع المستخدمين بما فيهم root — وابحث في المسارات غير القياسية، لا في ~/.ssh/ فقط
• راجع مهام cron لجميع الحسابات إضافة إلى root، وكذلك مؤقتات systemd
• قارن العمليات الجارية والمنافذ المفتوحة بما تتوقع وجوده فعليًا
• افحص الملفات المعدّلة حديثًا داخل /usr/local/ و /etc/ و /root

إذا ظهر لك أي شيء من ذلك، توقف عن التعامل مع الأمر كمهمة تحديث وابدأ التعامل معه كحادث أمني. عقلية مختلفة، وخطة مختلفة — وأول ما يجب الحفاظ عليه هو الأدلة قبل حذف أي شيء.

---

الدرس الأهم: الحزم المنسية

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

الأهمية في الفئة التي تنتمي إليها: المكوّنات الاختيارية في الاستضافة — Passenger، وحدات Ruby، معالجات PHP الإضافية، وكل ما فُعِّل يومًا لمشروع عميل معيّن — هي باستمرار أقل البرمجيات مراقبةً على سيرفرات الاستضافة. نواة cPanel تحدّث نفسها، بينما تبقى إضافات EasyApache تراكم الثغرات بصمت، في المنطقة العمياء بين “النظام يتولى ذلك” و”cPanel يتولى ذلك”.

هناك إجراءان يعالجان معظم هذه المشكلة، وكلاهما لا يستغرق وقتًا يُذكر:

1. فعّل التحديث التلقائي للحزم من WHM ← Update Preferences. هناك حجة منطقية لتأجيل ترقية إصدارات cPanel الرئيسية على سيرفرات الإنتاج، لكن لا توجد حجة واحدة مقنعة لتأجيل التحديثات الأمنية لحزم اختيارية لا تراقبها أساسًا.

2. نفّذ جردًا لقائمة حزم EasyApache المثبتة، واسأل نفسك بصدق عن كل حزمة: هل ما زالت تؤدي وظيفة فعلية؟ وكل ما لا يؤدي وظيفة، احذفه. كل حزمة اختيارية تزيلها تعني إعلانًا أمنيًا أقل تقرؤه، وتحديثًا أقل تجدوله، وبابًا أقل يمكن من خلاله تحويل حساب مشترك رخيص إلى صلاحيات روت.

المصدر الرسمي: cPanel Security Alert: Privilege Escalation via Phusion Passenger’s Watchdog API

هل تحتاج مساعدة؟

إذا كنت تدير سيرفرات cPanel/WHM وترغب في أن تُدار التحديثات الأمنية والتحصين والاستجابة للحوادث بشكل احترافي، فريق استضافة الدعم العربي جاهز لمساعدتك — نتعامل مع التقارير الأمنية قبل أن تتحول إلى كارثة تؤثر على عملك وبياناتك.