اسم البرنامج الإضافي	6إيجارات التخزين
نوع الضعف	IDOR
رقم CVE	CVE-2026-9185
الاستعجال	عالي
تاريخ نشر CVE	2026-06-09
رابط المصدر	CVE-2026-9185

ثغرة IDOR غير مصادق عليها في 6إيجارات التخزين (CVE-2026-9185): ما يجب على مالكي مواقع ووردبريس القيام به الآن

تاريخ: 9 يونيو، 2026
مؤلف: WP‑Firewall — فريق أمان ووردبريس

ملخص: تم الكشف عن ثغرة خطيرة في مرجع الكائن المباشر غير الآمن (IDOR) تؤثر على مكون ووردبريس 6إيجارات التخزين (الإصدارات <= 2.22.0) (CVE‑2026‑9185). تتيح الثغرة للمهاجمين غير المصدق عليهم عرض وتعديل بيانات المستخدمين العشوائية عبر نقاط نهاية المكون التي تفتقر إلى فحوصات التفويض المناسبة. هذه مخاطرة خطيرة: فهي تمكن من تعداد المستخدمين، وكشف المعلومات الشخصية، وتصعيد الامتيازات في بعض التكوينات. إذا كنت تستخدم هذا المكون على أي موقع ووردبريس، اعتبر ذلك أمرًا عاجلاً واتبع الإرشادات أدناه.

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

---

ما هو IDOR (مرجع كائن مباشر غير آمن)؟

يشير مرجع الكائن المباشر غير الآمن (IDOR) إلى نوع من فشل التحكم في الوصول حيث يكشف التطبيق عن معرفات الكائنات الداخلية (IDs) للعملاء ثم يستخدم تلك المعرفات لأداء العمليات دون التحقق من أن الطالب مسموح له بالتصرف على الكائن المستهدف. مع IDOR، يقوم المهاجم بالتلاعب بمعرف (على سبيل المثال، user_id، post_id، order_id) للوصول إلى بيانات مستخدم آخر أو تعديلها.

في مكونات ووردبريس، يظهر IDOR عادةً عندما يقبل الكود معرف مستخدم أو معرف منشور من معلمات الطلب ويقوم بعمليات القراءة أو الكتابة دون:

• التحقق من أن المستخدم الحالي مصدق عليه، و
• التحقق من أن المستخدم الحالي لديه إذن للوصول إلى هذا المورد المحدد أو تعديله.

نظرًا لأن ثغرة 6إيجارات التخزين قابلة للاستغلال دون مصادقة، فهي خطيرة بشكل خاص: يمكن لأي شخص على الإنترنت تقديم طلبات HTTP مصممة لاسترجاع أو تغيير سجلات المستخدمين.

---

ماذا حدث: ثغرة 6إيجارات التخزين، لمحة سريعة

• المكون المتأثر: 6إيجارات التخزين (مكون ووردبريس)
• الإصدارات المتأثرة: <= 2.22.0
• فئة الثغرة: مرجع الكائن المباشر غير الآمن (IDOR) — كسر التحكم في الوصول
• CVE: CVE‑2026‑9185
• CVSS (المبلغ عنه): 7.5 (مرتفع)
• الامتياز المطلوب: غير مصادق عليه (لا يتطلب تسجيل دخول)
• التأثير: كشف معلومات المستخدم العشوائية، تعديل بيانات المستخدم (اعتمادًا على نقاط نهاية المكون)، تصعيد محتمل للامتيازات والاستيلاء على الحساب.

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

---

لماذا هذا عاجل

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

بسبب هذه المخاطر، اتخذ إجراءات فورية حتى قبل توفر تصحيح رسمي للمكون الإضافي.

---

كيف يمكن للمهاجمين استغلال ذلك (ملخص عالي المستوى، غير تقني)

• اكتشاف المكون الإضافي على موقع (تحديد بصمة الويب الشائعة أو الاكتشاف المستهدف).
• تحديد نقاط نهاية المكون الإضافي (ajax الواجهة الأمامية، مسارات REST، أو إجراءات admin-ajax.php) التي تقبل معلمة ID (تسمى عادة user_id، id، uid، customer_id، إلخ).
• إرسال طلبات HTTP مصممة تتبادل قيمة ID مع معرفات أخرى (مثل 1، 2، 3…) لمراقبة الاستجابات. إذا لم تكن هناك فحوصات تفويض، سيتلقى المهاجم بيانات أو يحصل على حق الوصول للكتابة إلى سجلات مستخدمين آخرين.
• استخدام سكريبتات آلية لتعداد العديد من معرفات المستخدمين وجمع بيانات حساسة.
• إذا كان التعديل مسموحًا، قم بتغيير عناوين البريد الإلكتروني، تفاصيل الاتصال، أو البيانات الوصفية للمستخدم لتسهيل استيلاء الحساب (تفعيل تدفقات إعادة تعيين كلمة المرور، أو إضافة محتوى ضار).

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

---

مؤشرات الاختراق (IoC) - ما الذي يجب البحث عنه الآن

تحقق من سجلات الوصول والتطبيق الخاصة بك عن العلامات التالية:

• طلبات POST أو GET غير عادية تستهدف نقاط نهاية المكون الإضافي، admin-ajax.php، أو مسارات /wp-json/ التي تتضمن معلمات مثل user_id، id، uid، أو معرفات رقمية أخرى.
• طلبات تفتقر إلى ملفات تعريف الارتباط الخاصة بالمصادقة أو الرموز الصالحة ولكن لا تزال تتلقى بيانات مستخدم ذات مغزى في الاستجابة.
• تغييرات مفاجئة في البيانات الوصفية للمستخدم (تغييرات في عنوان البريد الإلكتروني، تحديثات اسم العرض، قدرات إضافية مخزنة في usermeta).
• إرسال رسائل إعادة تعيين كلمة المرور بشكل غير متوقع، أو تقارير من المستخدمين بأنهم لا يستطيعون الوصول إلى الحسابات.
• إنشاء مستخدمين جدد بامتيازات عالية، أو تعديل حسابات موجودة لمنح قدرات أعلى.
• ارتفاعات غير عادية في حركة المرور إلى مسارات المكون الإضافي أو أنماط تعداد المستخدمين المشبوهة (طلبات لمعرفات المستخدم 1..n).
• تنبيهات من ماسح البرامج الضارة الخاص بك أو مدقق سلامة الملفات.

إذا وجدت دليلًا، عزل الموقع (انظر خطوات استجابة الحوادث).

---

خطوات التخفيف الفورية لمالكي المواقع والمديرين

الأولوية (ماذا تفعل الآن):

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

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

---

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

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

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

1. حظر الطلبات غير المصرح بها التي تستهدف مسارات REST أو JSON للإضافة
   • النمط: حظر الطلبات إلى أي مسار مع شريحة الإضافة التي تكون غير مصرح بها.
   • مثال (قاعدة كود زائفة):

   إذا (REQUEST_URI يتطابق مع "/wp-json/.*/6storage.*" أو REQUEST_URI يتطابق مع "/.*6storage.*")
       

2. حظر إجراءات admin-ajax.php المشبوهة التي تشير إلى الإضافة
   • النمط: حظر طلبات admin-ajax.php حيث فعل تشير المعلمة إلى أسماء المكونات الإضافية أو أسماء الإجراءات المعروفة الضعيفة (إذا كانت متاحة).
   • مثال (كود زائف):

   إذا كانت (REQUEST_URI تحتوي على "admin-ajax.php")
       

3. حظر الطلبات التي تحتوي على معرف المستخدم المعلمة للطلبات غير المصرح بها

   إذا كانت (الطلب يحتوي على المعلمة "user_id" أو "uid" أو "id")
       

4. تحديد معدل وتحدي أنماط التعداد المشبوهة
   • إذا كان عنوان IP يولد عددًا كبيرًا من الطلبات إلى نقاط نهاية المكونات الإضافية أو يطلب معرفات عددية متسلسلة، قم بتقليل السرعة أو تقديم تحدٍ (CAPTCHA).
5. حظر POSTs المشبوهة التي تحاول تعديل بيانات تعريف المستخدم
   • النمط: حظر الطلبات إلى نقاط نهاية المكونات الإضافية التي تتضمن معلمات تُستخدم عادةً لتعديل الملف الشخصي (البريد الإلكتروني، كلمة المرور، مفاتيح البيانات الوصفية) عند عدم المصادقة.

   إذا كانت (REQUEST_BODY تحتوي على "user_email" أو "user_pass" أو "meta_key")
       

ملاحظات وتحذيرات:

• اختبار القواعد على نسخة تجريبية قبل الإنتاج لمنع انقطاع سير العمل الإداري الشرعي.
• لا تطبق القواعد التي تحظر جميع الطلبات ذات المعلمات العددية عالميًا - حدد نطاقها على URIs المكونات الإضافية أو أسماء الإجراءات.
• بالنسبة للمضيفين الذين ليس لديهم WAF، يمكنك تنفيذ حظر على مستوى الخادم على المدى القصير عبر تكوين خادم الويب (Apache mod_rewrite أو قواعد Nginx) لرفض الوصول إلى مسارات المكونات الإضافية المعروفة.

مثال على مقتطف Nginx (توضيحي - قم بتغييره ليتناسب مع بيئتك):

# حظر الوصول غير المصرح به إلى نقطة نهاية REST للمكونات الإضافية

مثال على .htaccess Apache (توضيحي):

# حظر GET/POST إلى إجراءات AJAX للمكونات الإضافية إذا لم يتم تسجيل الدخول

RewriteEngine On

إذا كنت تستخدم وحدة تحكم أمان مستضافة، قم بإنشاء قواعد مكافئة تتطابق مع بناء جملة مزودك.

---

توصيات الترميز الآمن لمطوري الإضافات

إذا كنت مطور مكونات إضافية تعمل على 6Storage Rentals أو أي مكون إضافي لـ WordPress، فإن الحل الصحيح على المدى الطويل هو إضافة التحكم المناسب في الوصول والتحقق من صحة المدخلات. ممارسات الترميز الآمنة المقترحة:

1. فرض فحوصات القدرة
   • استخدم وظائف مثل يمكن للمستخدم الحالي لضمان أن المستخدم الذي يطلب لديه القدرات المناسبة للوصول إلى الكائن المطلوب أو تعديله.
   • مثال: السماح بتعديل بيانات المستخدم فقط عندما يكون المستخدم الحالي يقوم بتحرير ملفه الشخصي أو لديه تحرير_المستخدمين القدرة.
2. يتطلب ويحقق من الرموز غير المتكررة للعمليات التي تغير الحالة
   • بالنسبة لطلبات AJAX وتقديم النماذج، استخدم check_ajax_referer( 'your_action_nonce', 'security' ) أو wp_verify_nonce() للتحقق من النية ومنع CSRF.
3. تحقق من نقاط نهاية REST
   • في وحدات تحكم REST، استخدم ردود الاتصال الخاصة بالأذونات التي تعيد صحيح فقط للمستخدمين المصرح لهم: 'permission_callback' => function() { return current_user_can( 'some_capability' ); }.
4. فحوصات الملكية
   • إذا كانت العمليات مسموح بها لمالكي الموارد، تحقق صراحة من أن المستخدم المصدق هو مالك المورد المستهدف: if ( $target_user_id !== get_current_user_id() ) { wp_die( 'غير مصرح', 403 ); }
5. تحقق من المدخلات وتنظيفها
   • تحويل المعرفات الرقمية إلى أعداد صحيحة: $user_id = intval( $_REQUEST['user_id'] ?? 0 );
   • يستخدم تطهير حقل النص, esc_sql(), ، وبيانات معدة حيثما كان ذلك مناسبًا.
6. مبدأ الحد الأدنى من الامتياز
   • صمم نقاط النهاية بأدنى امتياز ضروري ولا تفترض أبدًا أن المعامل المقدم من العميل آمن.
7. التسجيل والمراقبة
   • أضف تسجيلًا لفشل الأذونات ومحاولات الوصول المشبوهة للمساعدة في الكشف والتحقيق.
8. مراجعة الأمان والاختبارات الآلية
   • أضف اختبارات أمان آلية وفحوصات تحليل ثابتة للتحقق من عدم وجود رموز غير متكررة / فحوصات القدرة وغيرها من مشكلات الأمان الشائعة.

---

قائمة التحقق من الاستجابة للحوادث (إذا كنت تشك في وجود اختراق)

1. عزل
   قم بتعطيل المكون الإضافي المعرض للخطر مؤقتًا أو ضع الموقع في وضع الصيانة. إذا كان ذلك ممكنًا، قيد الوصول إلى مناطق الإدارة حسب IP حتى تؤكد الأمان.
2. الحفاظ على الأدلة
   قم بتصدير وحفظ سجلات خادم الويب، سجلات التطبيق، ونسخة احتياطية من قاعدة البيانات. احفظ النسخ في موقع آمن غير متصل.
3. قم بعمل نسخة احتياطية
   قم بعمل نسخة احتياطية كاملة (ملفات + قاعدة بيانات) على الفور قبل إجراء التغييرات.
4. فحص
   قم بتشغيل ماسح ضوئي موثوق للبرامج الضارة / مدقق سلامة الملفات للبحث عن الأبواب الخلفية أو الملفات الأساسية المعدلة أو قذائف الويب.
5. قم بتدقيق المستخدمين
   راجع جميع حسابات المستخدمين بحثًا عن مستخدمين إداريين جدد أو معدلين. انتبه بشكل خاص للحسابات التي تحتوي على مدير أو قدرات مرتفعة.
6. تدوير أوراق الاعتماد
   إعادة تعيين كلمات المرور لجميع المستخدمين الإداريين وأي حسابات FTP/SFTP/لوحة استضافة قد تتأثر. قم بتدوير بيانات اعتماد قاعدة البيانات إذا وجدت دليلًا على الاختراق.
7. إلغاء الجلسات
   إلغاء جميع الجلسات النشطة وإجبار تسجيل الخروج لجميع المستخدمين (يدعم WordPress ذلك عبر بيانات تعريف المستخدم أو المكونات الإضافية).
8. افحص المهام المجدولة
   تحقق خيارات wp وإدخالات cron للأحداث المجدولة الضارة.
9. تطبيق الإصلاحات
   تحديث المكون الإضافي المعرض للخطر إلى إصدار ثابت (إذا كان متاحًا) أو إزالته نهائيًا إذا لم يكن مطلوبًا. تطبيق قواعد الخادم / WAF كما هو موضح أعلاه.
10. استعادة من نسخة احتياطية نظيفة إذا لزم الأمر
    إذا كان الاختراق عميقًا ولا يمكنك ضمان حالة نظيفة، استعد من نسخة احتياطية معروفة بأنها نظيفة وقم بتحديث كل شيء قبل إعادة الاتصال.
11. شاشة
    بعد الاسترداد، راقب السجلات والتنبيهات عن كثب لمدة عدة أسابيع على الأقل لاكتشاف أي محاولات إعادة دخول.
12. إعلام
    إذا تم تأكيد تعرض بيانات المستخدم، قم بإخطار المستخدمين المتأثرين والامتثال للالتزامات التنظيمية.

---

كيفية اختبار ما إذا كنت معرضًا للخطر (بأمان)

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

---

تقوية ومنع طويل الأمد

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

---

لماذا تعتبر التصحيحات الافتراضية مهمة أثناء انتظار إصلاح رسمي

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

---

إذا كان موقعك يستخدم بالفعل WAF أو جدار ناري

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

(نحن نحافظ على قواعد التخفيف التي تحظر أنماط حركة المرور الضارة لمشاكل IDOR المماثلة ونوصي بتمكين قواعد مماثلة لهذا المكون الإضافي حتى يتم تصحيحه.)

---

لماذا يجب عليك التصرف الآن

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

---

دعوة خاصة: احمِ موقع WordPress الخاص بك باستخدام WP‑Firewall (الخطة المجانية)

قم بتأمين موقعك اليوم مع الحمايات الأساسية من WP‑Firewall. تمنحك خطتنا المجانية الأساسية حماية جدار ناري مُدارة، WAF بمستوى صناعي، فحص منتظم للبرامج الضارة، عرض نطاق غير محدود، وتخفيف لمخاطر OWASP Top 10 - كل ما تحتاجه لوقف التهديدات مثل استغلال IDOR غير الموثق بينما تقوم بتطبيق الإصلاحات.

لماذا يبدأ الآلاف من مالكي WordPress بحمايتنا المجانية

• الأساسي (مجاني): جدار ناري مُدار، عرض نطاق غير محدود، WAF، فاحص البرامج الضارة، تخفيف ضد مخاطر OWASP Top 10.
• قياسي: يضيف إزالة تلقائية للبرامج الضارة وقوائم سوداء/بيضاء لعناوين IP.
• محترف: يتضمن تصحيحًا افتراضيًا تلقائيًا، تقارير أمان شهرية، وإضافات متميزة مثل مدير حساب مخصص وخدمة أمان مُدارة.

قم بتأمين موقعك الآن واحصل على تخفيف WAF الفوري للثغرات التي تم الكشف عنها حديثًا مثل CVE‑2026‑9185:
https://my.wp-firewall.com/buy/wp-firewall-free-plan/

---

ملاحظات ختامية وإفصاح مسؤول

إذا كنت مطور مكون إضافي أو مسؤول عن 6Storage Rentals، يرجى إعطاء الأولوية لإصدار تصحيح رسمي يقوم بـ:

• إضافة فحوصات إذن صارمة على كل نقطة نهاية تتعامل مع معرفات المستخدم،,
• ينفذ التحقق من nonce لطلبات تغيير الحالة، و
• يتجنب كشف أو قبول معرفات المستخدمين دون التحقق من الملكية/القدرة.

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

فريق WP‑Firewall متاح لمساعدة مالكي المواقع في تطبيق قواعد التصحيح الافتراضي وإجراء عمليات المسح لتحديد التعرض. إذا كنت بحاجة إلى مساعدة، اتبع الخطوات في أقسام التخفيف والاستجابة للحوادث أعلاه واعتبر البدء بخطة الحماية المجانية المرتبطة سابقًا.

ابق آمنًا - اعتبر IDORs غير الموثقة أولوية فورية.