اسم البرنامج الإضافي	توتور LMS
نوع الضعف	ثغرة في التحكم بالوصول
رقم CVE	CVE-2026-5502
الاستعجال	قليل
تاريخ نشر CVE	2026-04-17
رابط المصدر	CVE-2026-5502

ملخص أمان عاجل - Tutor LMS (<= 3.9.8) تحكم وصول معطل (CVE-2026-5502) وماذا تفعل الآن

ملخص: ثغرة تحكم وصول معطل في Tutor LMS (الإصدارات ≤ 3.9.8) تسمح لمستخدم مصدق ذو امتيازات منخفضة (دور المشترك وما فوق) باستدعاء tutor_update_course_content_order الإجراء والتلاعب بترتيب محتوى الدورة والارتباطات. يجب على مواقع WordPress التي تستخدم Tutor LMS التحديث إلى 3.9.9 على الفور. إذا لم تتمكن من تطبيق التصحيح على الفور، قم بتطبيق تصحيح افتراضي باستخدام جدار حماية تطبيقات الويب، وقيّد الوصول إلى الإجراء المعرض للخطر، وفرض فحوصات nonce قوية، وتدقيق أدوار المستخدمين وسلامة الدورة، واتباع قائمة مراجعة استجابة الحوادث. أدناه سأرشدك خلال التفاصيل الفنية، سيناريوهات التأثير، تقنيات الكشف، التخفيفات العملية (بما في ذلك قواعد WAF النموذجية)، وخطة التعافي - من منظور فريق أمان WordPress ذو الخبرة في WP-Firewall.

---

ما أهمية ذلك

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

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

تصرف بسرعة: قم بالتحديث أو تطبيق التصحيح الافتراضي وأجرِ فحص سلامة محتوى دورتك.

---

ما هي الثغرة (على مستوى عالٍ)

• البرامج المتأثرة: مكون Tutor LMS لـ WordPress، الإصدارات ≤ 3.9.8.
• تم تصحيحه في: Tutor LMS 3.9.9.
• التصنيف: تحكم وصول معطل / OWASP A1.
• CVE: CVE-2026-5502.
• السبب الجذري: نقطة نهاية AJAX (الإجراء = tutor_update_course_content_order) التي تتعامل مع ترتيب محتوى الدورة لم تقم بإجراء فحوصات تفويض كافية (تحقق من القدرة/الدور مفقود أو غير كاف و/أو تحقق من nonce)، مما يسمح للحسابات المصدقة ذات الامتيازات المنخفضة (المشترك وما فوق) بتقديم طلبات تغير ترتيب محتوى الدورة والارتباطات.

باختصار: يكشف المكون عن وظيفة على جانب الخادم عبر admin-ajax.php (أو نقطة نهاية REST) تقوم بتحديث ترتيب محتوى الدورة دون تأكيد صحيح أن الطالب لديه الحق في تنفيذ تلك العملية. يمكن لمهاجم لديه حساب مشترك استدعاء هذا الإجراء لإعادة ترتيب أو نقل أو التلاعب بمحتوى الدورة.

---

كيف يتم استغلال الثغرة عادةً (سيناريوهات الهجوم)

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

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

---

التحليل الفني (ما الذي يجب البحث عنه)

يتم استدعاء العملية المعرضة عادةً عبر POST AJAX أو POST REST. السطح النموذجي للطلب:

• نقطة النهاية: admin-ajax.php?action=tutor_update_course_content_order (أو مسار REST المعادل)
• قد تشمل المعلمات course_id، مصفوفة ترتيب المحتوى، معرفات الدروس، إلخ.
• الفحوصات المفقودة: إما أن المعالج كان يفتقر إلى فحص القدرة (مثل،, current_user_can('manage_courses') أو قدرة محددة للمعلم) أو لم يتحقق من nonce صالح في ووردبريس مع wp_verify_nonce.

ما يجب التحقق منه في الكود (إذا كنت تستعرض ملفات المكون الإضافي):

• ابحث عن اسم الدالة tutor_update_course_content_order أو ما شابه ذلك.
• تحقق من استدعاءات الدالة wp_verify_nonce على nonce المرسل من قبل العميل.
• تحقق من فحوصات الدالة يمكن للمستخدم الحالي لوجود قدرة تتماشى مع إدارة محتوى الدورة التدريبية (ليس فقط التحقق تم تسجيل دخول المستخدم ()).
• تأكيد استخدام أي مسار REST إذن_استدعاء_العودة بشكل صحيح.

إذا كانت الوظيفة تعتمد ببساطة على تم تسجيل دخول المستخدم () أو لم تتحقق من nonce، فمن المحتمل أن تكون عرضة للخطر.

---

قابلية الاستغلال وتقييم الأثر

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

على الرغم من وجود CVSS معتدل، إلا أن التأثير التجاري يمكن أن يكون كبيرًا على منصات التعليم. تعامل مع الأمر بجدية.

---

الإجراءات الفورية (ماذا تفعل في الساعات 1-2 الأولى)

1. تحديث Tutor LMS إلى 3.9.9 على الفور على جميع المواقع حيثما كان ذلك ممكنًا. هذا هو الإصلاح النهائي.
2. إذا لم تتمكن من التحديث فورًا:
   • تفعيل تصحيح افتراضي (قاعدة WAF) تمنع الطلبات التي تحاول استدعاء الإجراء المعرض للخطر من حسابات غير إدارية (أمثلة أدناه).
   • تعطيل التسجيل العام مؤقتًا إذا كانت موقعك يسمح بتسجيل المستخدمين المفتوحين ولا يمكنك تقييد الحسابات الجديدة.
   • تدقيق حسابات المشتركين النشطين؛ تعطيل أو التحقق من أي حسابات تم إنشاؤها مؤخرًا أو ذات مجالات بريد إلكتروني مشبوهة.
3. قم بأخذ لقطة / نسخة احتياطية من الموقع (الملفات + قاعدة البيانات) قبل إجراء تغييرات. الحفاظ على الأدلة للتحليل الجنائي.
4. تدوير أوراق الاعتماد لحسابات المعلمين والمديرين إذا كنت تشك في الاختراق.
5. تمكين أو زيادة المراقبة وتسجيل الدخول لـ tutor_update_course_content_order الإجراء و admin-ajax.php أو نقاط نهاية REST.

---

الكشف: كيفية تحديد محاولات أو استغلال ناجح

فحص هذه المصادر:

• سجلات وصول خادم الويب: ابحث عن طلبات POST إلى admin-ajax.php أو نقاط نهاية REST تحتوي على action=tutor_update_course_content_order. انتبه إلى:
  • التكرار، الارتفاعات، عناوين IP غير العادية.
  • الطلبات التي تحتوي على ملفات تعريف الارتباط المعتمدة من المشتركين والتي تقوم بإجراء إجراءات POST.
• سجلات التطبيق: إذا كانت موقعك يسجل إجراءات AJAX أو أحداث المكونات الإضافية، ابحث عن أحداث إعادة ترتيب الدورات من حسابات غير المدربين.
• قاعدة البيانات: استعلام عن جداول meta الدورة أو postmeta للتغييرات المفاجئة في lesson_order أو العلاقات.
• سجلات تدقيق LMS (إذا كانت Tutor أو سجلات الموقع تسجل تحديثات المحتوى): ابحث عن التحديثات حيث يكون user_id مشتركًا أو مستخدمًا غير متوقع.
• سجلات WP-Firewall: ابحث عن محاولات محجوبة أو علامات شذوذ حول نقطة النهاية.

أمثلة البحث (شل):

• سجلات Apache/Nginx:
  grep "tutor_update_course_content_order" /var/log/nginx/access.log*
• تحقق من قاعدة بيانات WP (لترتيب meta؛ تعتمد الجدول والمفاتيح على المكون الإضافي):
  SELECT * FROM wp_postmeta WHERE meta_key LIKE '%order%' AND post_id IN (SELECT ID FROM wp_posts WHERE post_type='tutor_course');

مؤشرات الاختراق:

• تغييرات غير متوقعة في ترتيب الدروس مرئية في صفحات الدورة.
• طلبات POST متكررة إلى الإجراء المعرض للخطر من نفس عنوان IP أو النطاق.
• تغييرات مؤلفة بواسطة معرفات مستخدمين غير المدربين.

---

قواعد WAF / التصحيح الافتراضي الموصى بها (أمثلة على التوقيعات)

فيما يلي أمثلة توضيحية يمكنك استخدامها لصياغة تصحيحات افتراضية في WP-Firewall أو WAF على جانب الخادم. هذه القواعد دفاعية ومصممة لحظر الإجراء المعرض للخطر أو تتطلب nonce/referer.

مهم: قم بتكييف القواعد مع بناء جملة WAF الخاص بك. هذه قواعد زائفة ومثال على ModSecurity كإرشاد.

1) حظر طلبات POST التي تستدعي الإجراء المعرض للخطر عندما لا يكون nonce موجودًا

# نمط ModSecurity (مفاهيمي)"

2) رفض طلبات POST للعمل من حسابات مجهولة أو مسجلة حديثًا (استدلال)

# حظر إذا كان العمل مفقودًا/غير صالح WP auth cookie أو UA/IP مشبوه"

3) قاعدة صارمة: السماح بالعمل فقط إذا كان المرجع هو نطاق الإدارة الخاص بك و _wpnonce موجود (مفيد كإجراء طارئ)

SecRule REQUEST_METHOD "POST" "phase:1,chain,deny,id:100003,msg:'فرض المرجع لتحديث محتوى دورة المعلم'"

4) تحديد معدل المحاولات المتكررة (منع إعادة الطلب بالقوة أو الاستكشاف)

# تتبع وتحديد محاولات POST للعمل، على سبيل المثال، أكثر من 30 في الدقيقة محظورة"

ملحوظات:

• التصحيح الافتراضي هو إجراء طارئ قصير الأجل. الإصلاح المناسب = تحديث المكون الإضافي.
• اختبار أي قواعد ModSecurity بعناية على بيئة الاختبار لتجنب الإيجابيات الكاذبة.
• استخدم لوحة تحكم WP-Firewall لإنشاء قاعدة مخصصة تحظر الطلبات التي تتضمن action=tutor_update_course_content_order ما لم يكن المستخدم المسجل هو المسؤول/المدرب (إذا كان جدار الحماية الخاص بك يمكنه التحقق من سمات الجلسة).

---

تدابير التخفيف والخطوات الصلبة على مستوى WordPress

1. تحديث المكون الإضافي إلى 3.9.9 (أو الأحدث). هذا يغلق الثغرة.
2. فرض أقل امتياز:
   • مراجعة أدوار المستخدمين والقدرات. تأكد من أن المدربين أو المسؤولين أو الأدوار الموثوقة فقط لديهم قدرات تحرير الدورة.
   • إزالة أو تقييد القدرات غير الضرورية من دور المشترك.
3. تعزيز نقاط نهاية AJAX/REST:
   • التأكد من أن نقاط نهاية المكون الإضافي تتحقق wp_verify_nonce() و يمكن للمستخدم الحالي من القدرة المناسبة.
   • إذا كنت تحتفظ بشيفرة مخصصة، أضف إذن_استدعاء_العودة لمسارات REST.
4. تعطيل أو تقييد نقاط نهاية admin-ajax حيث لا يتطلب الأمر:
   • استخدم مكونًا إضافيًا أو تكوين خادم لتقييد الوصول إلى admin-ajax.php للمستخدمين الذين لا يحتاجون إليه، أو للسماح بالوصول فقط عندما يكون المرجع هو موقعك.
5. ضوابط تسجيل المستخدم:
   • تعطيل التسجيل المفتوح إذا لم يكن مطلوبًا.
   • تنفيذ التحقق من البريد الإلكتروني و CAPTCHA للتسجيلات.
   • استخدم الموافقة اليدوية للمدرسين الجدد أو الأدوار التي يمكنها تعديل المحتوى.
6. مسح التغييرات الضارة:
   • استخدم ماسحات البرامج الضارة ومراقبة سلامة الملفات لاكتشاف التغييرات غير المصرح بها في الملفات أو المحتوى.
7. النسخ الاحتياطية:
   • تأكد من وجود نسخ احتياطية نظيفة حديثة. إذا تم اكتشاف إساءة، قد تحتاج إلى استعادة محتوى الدورة من لقطة تم أخذها قبل التسلل مباشرة.

---

قائمة التحقق من الاستجابة للحوادث (خطوة بخطوة)

إذا اكتشفت استغلالًا أو اشتبهت في إساءة:

1. ضع الموقع في وضع الصيانة (إذا لزم الأمر) لمنع المزيد من الضرر وتسرب البيانات.
2. قم بعمل نسخة احتياطية كاملة (الملفات + قاعدة البيانات) وعزلها (لا تكتب فوق النسخ الاحتياطية الموجودة).
3. تحديد النطاق:
   • ما هي الدورات والدروس التي تم تعديلها؟
   • أي حسابات مستخدمين قامت بالتغييرات؟ (المعرفات والأدوار)
   • متى حدثت التغييرات (الطوابع الزمنية، عناوين IP)؟
4. حظر المحاولات الإضافية:
   • قم بتمكين قاعدة التصحيح الافتراضية/ WAF على الفور لحظر الإجراء.
   • قم بتعطيل التسجيل المفتوح مؤقتًا وحظر عناوين IP أو نطاقات مشبوهة.
5. احتواء وتنظيف:
   • استعد محتوى الدورة المعدل من نسخة احتياطية موثوقة أو استعد النظام يدويًا.
   • تعطيل الحسابات المشبوهة (خاصة التي تم إنشاؤها مؤخرًا).
6. تدوير أوراق الاعتماد:
   • فرض إعادة تعيين كلمات المرور لحسابات المعلمين والمديرين.
   • تدوير مفاتيح API والرموز المستخدمة على الموقع.
7. المراقبة بعد الحادث:
   • مراقبة السجلات للظهور مرة أخرى لمدة 30 يومًا على الأقل.
   • إجراء فحوصات شاملة للبرامج الضارة وسلامة النظام.
8. بعد الوفاة:
   • توثيق الجدول الزمني، السبب الجذري، خطوات العلاج المتخذة، والدروس المستفادة.
   • تحديث سياسات الأمان وتواتر تحديثات الإضافات.

---

للمطورين: تحسينات في التعليمات البرمجية والتكوين

إذا كنت تدير مواقع أو تساهم في تكامل Tutor، تأكد من:

• أن مسارات REST تتضمن إذن_استدعاء_العودة التي تتحقق من القدرات:

register_rest_route( 'tutor/v1', '/update-content-order', array(;

• للتحقق من إجراءات AJAX، تحقق من nonce والقدرات:

function my_ajax_update_course_content_order() {;

• تجنب الاعتماد فقط على الفحوصات من جانب العميل (مثل فحوصات دور JS). التحقق من جانب الخادم مطلوب.

---

كيفية التحقق من أنك آمن بعد التحديث

بعد تطبيق تصحيح الإضافة (3.9.9+) والتخفيفات المؤقتة:

1. تأكيد إصدار الإضافة:
   • WP-Admin → الإضافات → Tutor LMS يظهر 3.9.9.
   • أو CLI: wp قائمة المكونات الإضافية | grep معلم
2. إعادة تشغيل فحوصات السلامة:
   • سلامة الملف: قارن ملفات الإضافات مع النسخة الأصلية.
   • قاعدة البيانات: تأكد من أن ترتيب الدورة يتطابق مع النسخ الاحتياطية السابقة للحادث أو الهيكل المتوقع.
3. أعد إنشاء واختبار مستخدم مشترك للتحقق من أنهم لا يمكنهم إعادة ترتيب محتوى الدورة أو استدعاء الإجراء.
4. راجع سجلات الوصول والأحداث لمحاولات التأكيد على أن WAF قد حظرها أو أنه لم تحدث أي طلبات تعديل أخرى بعد التصحيح.

---

المراقبة والتوصيات طويلة الأجل

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

---

مثال: كيف قد يبدو قاعدة الكشف في WP-Firewall (مفاهيمي)

إذا كنت تستخدم WP-Firewall، أنشئ قاعدة مستهدفة لحظر الإجراء المعرض للخطر حتى تتمكن من التحديث:

• نوع القاعدة: فلتر طلب مخصص
• الهدف: طلبات POST إلى admin-ajax.php أو مسار REST يحتوي على إجراء تحديث المعلم
• الشروط:
  • يحتوي جسم الطلب أو URL على action=tutor_update_course_content_order
  • و لا يوجد _wpnonce معلمة صالحة موجودة أو الطلب ليس من منطقة الإدارة
• الإجراء: حظر + تسجيل + تنبيه عبر البريد الإلكتروني

هذا يمنع محاولات الهجوم المحتملة مع تقليل الإيجابيات الكاذبة. بعد التحديث إلى 3.9.9، يمكنك الاسترخاء أو حذف القاعدة.

---

قائمة مراجعة قصيرة يمكنك تطبيقها الآن.

• قم بتحديث Tutor LMS إلى 3.9.9 أو أحدث.
• أنشئ قاعدة WAF طارئة للحظر. tutor_update_course_content_order من غير الإداريين.
• قم بأخذ لقطة لموقعك (الملفات + قاعدة البيانات) واحفظها في وضع عدم الاتصال.
• تحقق من حسابات المشتركين التي تم إنشاؤها في آخر 30 يومًا.
• ابحث في السجلات عن tutor_update_course_content_order المحاولات وطلبات POST غير العادية.
• عُد أو أصلح شذوذ ترتيب الدورات من النسخة الاحتياطية الموثوقة.
• فرض إعادة تعيين كلمات المرور لأي حسابات مشبوهة وحسابات المعلمين/الإداريين ذات الصلة.
• قم بتشغيل فحوصات البرمجيات الضارة والسلامة.
• ضع تدابير تعزيز طويلة الأجل (تدقيق الأدوار، استدعاءات أذونات النقاط النهائية، ضوابط التسجيل).

---

احمِ موقعك — جرب خطة WP-Firewall المجانية (التفاصيل وكيف تساعد).

احمِ دورات WordPress الخاصة بك اليوم — جرب خطة WP-Firewall المجانية.

إذا كنت تريد طريقة سريعة وسهلة للحصول على حماية فورية أثناء التحديث والتدقيق، فإن خطة WP-Firewall الأساسية (المجانية) مصممة لمثل هذه الحالات:

• حماية أساسية: جدار ناري مُدار يمنع أنماط الاستغلال الشائعة والتوقيعات.
• عرض نطاق غير محدود لفحص حركة مرور WAF.
• جدار حماية تطبيقات الويب (WAF) مع القدرة على تطبيق تصحيحات افتراضية للنقاط النهائية عالية المخاطر.
• ماسح للبرمجيات الضارة واكتشاف سلوك الاستغلال النموذجي.
• التخفيف من مخاطر OWASP Top 10، بما في ذلك أنماط التحكم في الوصول المكسور.

يمكنك التسجيل في الخطة الأساسية المجانية هنا: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

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

---

أفكار نهائية من مهندسي أمان WP-Firewall

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

النقاط الرئيسية:

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

إذا كنت ترغب، يمكن لفريق WP-Firewall مساعدتك:

• تطبيق تصحيحات افتراضية طارئة لحظر النقطة النهائية الضعيفة.
• فحص المواقع بحثًا عن علامات الاستغلال واستعادة سلامة الدورة.
• تعزيز أذونات النقاط النهائية وإعداد مراقبة مصممة لحمولات LMS.

ابق آمنًا. قم بالتحديث الآن، وضع طبقة WAF بين مستخدميك العموميين ونقاط النهاية الحرجة في LMS الخاصة بك - غالبًا ما يحدث الفرق بين انقطاع قصير وتوقف مكلف.