ترقية Uptime Kuma من v1 إلى v2: دليل الأمان

لماذا الترقية الآن: CVE-2026-45618 ونهاية دعم الفرع 1.x

‏CVE-2026-45618 ثغرة حرجة مصنَّفة CVSS 10.0 في ‏LiquidJS، محرك القوالب الذي تستخدمه Uptime Kuma لتنسيق الإشعارات. تتأثر إصدارات ‏LiquidJS الأقدم من 10.26.0: يمكن للمهاجم استغلال مُرشِّح valueOf في حقل قالب — مثل اسم جهاز مراقبة — لتسلسل التلاعب في النماذج الأولية والوصول إلى مُنشئ Function في JavaScript وتنفيذ أوامر اعتباطية على الخادم. تُثبت نماذج الاستغلال المتاحة للعموم إمكانية قراءة الملفات وتشغيل الأوامر عبر child_process.execSync.

لم يتلقَّ الفرع 1.x سوى إصلاح جزئي مقتصر على السياقات التي تتطلب مصادقة: يحتفظ المهاجم الذي يملك وصولاً إدارياً — أو القادر على انتزاعه بالقوة — بسطح الهجوم الأصلي. يضمّ الفرع 2.x الإصدار 10.26.0 من ‏LiquidJS مع معالجة كاملة للثغرة. لا تُخطَّط أي إصلاحات إضافية للفرع 1.x: يمثل الإصدار 2.5.0 الصادر في 1 أغسطس 2026 المسار النشط للمشروع. الاستمرار في تشغيل نسخة 1.x يعني إبقاء كل جهاز مراقبة — وعملاؤه — أمام سطح هجوم مفتوح بلا تاريخ إغلاق معروف.

التداعيات الفعلية لنسخة غير مُرقَّاة

تنفيذ كود عن بُعد: يستطيع المهاجم الذي يتحكم في اسم جهاز مراقبة أو حقل قالب تشغيل أوامر نظام على الخادم المستضيف.
كشف محفظة العملاء: تُعرِّض الوكالة التي تستضيف نسخة مشتركة إعدادات عملائها وعناوين URL الداخلية وبيانات الاعتماد الخاصة بالإشعارات.
تحميل المسؤولية: في حالة وقوع حادث على نسخة غير مُصانة، يُشكّل التقصير في الترقية بعد نشر CVE حرجة عاملاً مُشدِّداً.
تراكم الثغرات: لن يتلقى الفرع 1.x أي تصحيحات أمنية أو تحديثات للتبعيات — تتراكم كل ثغرة جديدة في LiquidJS أو تبعياتها دون علاج.
اكتشاف صامت: يُقيِّم LiquidJS القوالب من جانب الخادم؛ قد يظل الاستغلال غير مرئي في سجلات تطبيق Uptime Kuma.

المتطلبات الأساسية قبل البدء

تحقق من النقاط التالية قبل إطلاق عملية الترقية. قد يُعسِّر إهمال إحداها أي تراجع عن العملية.

الموارد الدنيا الموصى بها. تعمل Uptime Kuma v2 بالبصمة ذاتها لـ v1: يكفي 1 vCPU و512 ميغابايت RAM لأقل من 50 جهاز مراقبة. خطِّط لـ 2 vCPU وجيغابايت واحد لأسطول يضم 200 جهاز أو أكثر. قد تستغرق ترقية قاعدة بيانات SQLite عدة دقائق على تخزين بطيء — يُقلِّص VPS مع SSD من نوع NVMe هذه النافزة الزمنية.

‏Docker Compose v2. الأمر المطلوب هو docker compose (إضافة متكاملة)، لا docker-compose (ثنائي مستقل v1). تحقق بـ docker compose version: يُتوقع الحصول على رد يبدأ بـ Docker Compose version v2. إن فشل الأمر، ثبِّت الإضافة عبر مدير حزم توزيعتك قبل المتابعة.

وصول root أو sudo. تتطلب العملية التعامل مع أحجام Docker وملفات النظام؛ يُعدّ الوصول المميّز ضرورياً.

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

نسخ احتياطي إلزامي قبل الترقية

تُحوِّل عملية الترقية من v1 إلى v2 مخطط قاعدة بيانات SQLite بصورة لا رجعة فيها. بدون نسخة احتياطية صالحة، يستحيل التراجع الكامل.

تحديد الحجم أو مجلد البيانات. عند استخدام Docker Compose مع حجم مُسمَّى، الاسم الافتراضي هو uptime-kuma_uptime-kuma-data. أكِّد ذلك بـ docker volume ls | grep kuma. عند استخدام ربط مباشر (bind mount)، حدِّد المسار في ملف docker-compose.yml — عادةً ./data:/app/data.

إيقاف الحاوية قبل النسخ الاحتياطي. قد تكون قاعدة بيانات SQLite المُنسخة احتياطياً أثناء الكتابة تالفة. لا تستخدم علامة -v عند الإيقاف أبداً: ستؤدي إلى حذف الحجم ومحتوياته.

النسخ الاحتياطي لحجم البيانات

إيقاف Uptime Kuma

أوقف الحاوية دون حذف الحجم:

docker compose down

انتظر التأكيد Container uptime-kuma Stopped قبل المتابعة.

نسخ احتياطي لحجم Docker مُسمَّى

استخدم حاوية busybox لإنشاء أرشيف مضغوط للحجم:

docker run --rm \
  --volume uptime-kuma_uptime-kuma-data:/app/data \
  --volume $(pwd):/backup \
  busybox \
  tar czf /backup/uptime-kuma-v1-backup.tar.gz -C /app/data .

تحقق من حجم الأرشيف بـ ls -lh uptime-kuma-v1-backup.tar.gz. أرشيف لا يتجاوز بضعة بايتات يُشير إلى مشكلة في التركيب — صحِّحها قبل المتابعة.

نسخ احتياطي لربط مباشر

إن كانت بياناتك في مجلد على المضيف (مثال: ./data):

tar czf uptime-kuma-v1-backup.tar.gz ./data

احتفظ بهذا الأرشيف خارج الخادم (تخزين الكائنات، خادم بعيد) قبل المضي في الترقية.

ترقية v1 إلى v2: الإجراء خطوة بخطوة

تحديث صورة Docker في ‏docker-compose.yml

افتح ملف docker-compose.yml وعدِّل علامة الصورة:

# قبل
image: louislam/uptime-kuma:1
# بعد
image: louislam/uptime-kuma:2

إن كنت تستخدم علامة latest، فضِّل علامة إصدار صريحة كـ louislam/uptime-kuma:2.5.0 لتجنب الانحدارات عند الترقية التلقائية المستقبلية.

سحب الصورة الجديدة

حمِّل صورة v2 قبل تشغيل الخدمة:

docker pull louislam/uptime-kuma:2

تحقق من وجود الصورة: docker images | grep uptime-kuma.

تشغيل حاوية v2

شغِّل الخدمة. يكتشف Docker Compose تغيير الصورة ويُعيد إنشاء الحاوية:

docker compose up -d

انتظر التأكيد Container uptime-kuma Started.

متابعة ترقية قاعدة البيانات

عند أول تشغيل، ترقِّي Uptime Kuma مخطط SQLite إلى تنسيق v2. قد تستغرق هذه العملية من ثوانٍ إلى عشرات الدقائق حسب حجم قاعدة البيانات:

docker compose logs -f uptime-kuma

لا توقف الحاوية خلال هذه المرحلة. انتظر السطر الذي يؤكد انتهاء الترقية قبل المتابعة.

التحقق من فحص الصحة

تحقق من أن الحاوية في حالة healthy:

docker compose ps

يجب أن تُظهر عمود Status القيمة healthy. إن ظلت على starting أكثر من دقيقتين بعد انتهاء سجلات الترقية، راجع السجلات لتحديد الخطأ.

تأكيد الإصدار النشط في الواجهة

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

الفحوصات بعد الترقية

الترقية الناجحة لا تقتصر على حاوية تعمل. راجع هذه النقاط قبل اعتبار العملية مكتملة.

أجهزة المراقبة. افتح لوحة التحكم وقارن عدد أجهزة المراقبة بقائمتك في v1. قد يُشير الجهاز المفقود إلى ترقية جزئية — راجع السجلات على مستوى ERROR أو WARN.

الإشعارات. شغِّل يدوياً اختبار إشعار لكل قناة مُهيَّأة (البريد الإلكتروني، Telegram، webhook). تُطبِّق v2 التحقق الصارم من قوالب Liquid: سيُرفض أي حقل يحتوي على علامات غير مطابقة. استغل هذه الفرصة لمراجعة أسماء أجهزة المراقبة وحذف أي محتوى قوالب غير متوقع — هذا هو المتجه الدقيق لـ CVE-2026-45618.

صفحة الحالة. إن كنت تعرض صفحة حالة عامة، تحقق من استجابتها الصحيحة وعرضها للخدمات الصحيحة. يُحفظ عنوان URL والمعرّف بعد الترقية.

شهادات SSL. تُعيد مجسات TLS دورة التحقق بعد الترقية. قد تُطلق شهادة كانت قريبة من انتهاء الصلاحية قبل الترقية تنبيهاً فورياً: تحقق من التاريخ الفعلي قبل معالجته كحادثة.

تعزيز أمان النسخة بعد الترقية

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

نطاق فرعي مخصص خلف وكيل عكسي. لا تعرض Uptime Kuma على منفذ مباشر (:3001). ضعها خلف ‏Nginx أو ‏Caddy على نطاق فرعي مخصص (‏status.your-domain.com) مع TLS. أغلق المنفذ 3001 على مستوى جدار الحماية: ufw deny 3001.

‏Fail2ban أو ‏CrowdSec أمام الوكيل. أضف قاعدة كشف للقوة الغاشمة على محاولات تسجيل الدخول إلى الواجهة. يمتلك CrowdSec سيناريو uptime-kuma في موزَّعه Hub. راجع المقال Sécuriser votre VPS avec CrowdSec للإجراء الكامل.

عزل الشبكة. ضع Uptime Kuma في شبكة Docker مخصصة. لا يحتاج إلا إلى الوصول إلى الأهداف التي يراقبها — لا إلى قواعد البيانات الإنتاجية ولا إلى الواجهات البرمجية الداخلية.

استكشاف الأخطاء: الأخطاء الشائعة

حجم غير متوافق أو قاعدة بيانات تالفة. إن أظهرت السجلات SQLITE_ERROR: no such table أو database disk image is malformed، فقاعدة البيانات المُركَّبة غير صالحة أو أُخذت النسخة الاحتياطية أثناء الكتابة. استعد الأرشيف، أوقف الحاوية بشكل سليم، وأعد الإجراء من خطوة النسخ الاحتياطي.

المنفذ 3001 مستخدَم بالفعل. يُشير الخطأ address already in use :::3001 إلى احتلال منفذ من قِبل عملية أخرى. حدِّدها بـ ss -tlnp | grep 3001 وأوقفها، أو عدِّل تعيين المنفذ في docker-compose.yml (مثلاً 3002:3001) وحدِّث إعدادات الوكيل العكسي.

رفض قالب الإشعار بعد الترقية. إن أظهرت قناة إشعار خطأ في القالب، رفض التحقق الصارم في LiquidJS 10.26.0 قالباً كان مقبولاً في v1. عدِّل القالب المعني في الإعدادات ← الإشعارات واحذف العلامات الخاطئة أو صحِّحها.

شهادة TLS تُعرض منتهية الصلاحية. تُعيد مجسات TLS دورتها بعد الترقية. تحقق من التاريخ الفعلي بـ echo | openssl s_client -connect your-domain.com:443 2>/dev/null | openssl x509 -noout -dates قبل معالجة هذا التنبيه كحادثة.

حاوية في حلقة إعادة تشغيل. إن فشلت الترقية وكانت السياسة restart: always، يُعيد Docker تشغيل الحاوية إلى ما لا نهاية. انتقل إلى restart: no، صحِّح المشكلة المُحدَّدة في السجلات، ثم استعد السياسة الأصلية.

ما تحميه هذه الترقية

ترقية Uptime Kuma إلى الإصدار 2.x تُغلق CVE-2026-45618 على سطح متاح مباشرةً من واجهة الإدارة. بالنسبة لوكالة تدير بنية تحتية لعدة عملاء من نسخة مشتركة، يتناسب هذا السطح مع عدد الحسابات وأجهزة المراقبة المُهيَّأة: كل عميل إضافي كان يُوسِّع المحيط المكشوف.

تجلب v2 أيضاً تغييرات هيكلية تُقلِّص سطح الهجوم على المدى البعيد: صورة Docker بلا صلاحيات جذر افتراضياً، تبعيات مُصانة بنشاط، وآلية تأخير 14 يوماً قبل دمج تبعيات npm جديدة — للحد من هجمات سلسلة التوريد، كما يوثِّق المقال Sécuriser la chaîne d'approvisionnement npm en CI.

إدارة بنية تحتية لعدة عملاء من مكان مركزي واحد، دون تحمُّل مخاطر نهاية الدعم وحدك، هو ما يُتيحه فضاء وكالة ServOrbit.