اسم البرنامج الإضافي	حدود الحد الأدنى/الحد الأقصى للطلبات لـ WooCommerce
نوع الضعف	البرمجة النصية عبر المواقع (XSS)
رقم CVE	CVE-2025-47504
الاستعجال	قليل
تاريخ نشر CVE	2026-04-22
رابط المصدر	CVE-2025-47504

عاجل: XSS في ‘حدود الحد الأدنى/الحد الأقصى للطلبات لـ WooCommerce’ (<= 4.6.4) — ماذا يعني ذلك وكيف تحمي موقعك

تحليل تقني وإرشادات التخفيف من خبراء أمان WP‑Firewall لـ CVE‑2025‑47504 (XSS في مكون "حدود الحد الأدنى/الحد الأقصى للطلبات لـ WooCommerce"). خطوات التخفيف، قواعد WAF، استعلامات الكشف، وتقوية وقائية.

نُشرت: 2026-04-22
مؤلف: فريق أمان WP‑Firewall

العلامات: ووردبريس، WooCommerce، XSS، ثغرة المكون، WAF، WP-Firewall

ملاحظة: يشرح هذا المنشور ثغرة برمجية عبر المواقع (XSS) تم الإبلاغ عنها كـ CVE‑2025‑47504 في مكون ووردبريس “حدود الحد الأدنى/الحد الأقصى للطلبات لـ WooCommerce” التي تؤثر على الإصدارات <= 4.6.4 وتم تصحيحها في 4.6.5. إذا كنت تستخدم WooCommerce مع هذا المكون، فاتبع الإرشادات أدناه على الفور.

TL;DR (ملخص سريع)

• الثغرة: برمجة عبر المواقع (XSS) — CVE‑2025‑47504.
• المكون المتأثر: حدود الحد الأدنى/الحد الأقصى للطلبات لـ WooCommerce (الإصدارات <= 4.6.4).
• تم تصحيحه في: 4.6.5 — قم بتحديث المكون على الفور.
• متطلبات الاستغلال: يحتاج المهاجم إلى التفاعل عبر حساب متميز (مساهم) وتفعيل حمولة مصممة (تفاعل المستخدم مطلوب).
• المخاطر: حقن JavaScript يمكن أن يعمل في سياق موقعك — سرقة محتملة للإدارة/الجلسة، تشويه المحتوى، إعادة توجيه، أو استغلال إضافي.
• الإجراءات الفورية: التحديث إلى 4.6.5، تمكين قواعد جدار الحماية لحظر أنماط الاستغلال، تدقيق الموقع بحثًا عن الاختراق.
• توصية WP‑Firewall: تصحيح + تصحيح افتراضي (WAF) إذا لم يكن التحديث الفوري ممكنًا.

---

الخلفية: ما هي هذه الثغرة؟

تحدث برمجة عبر المواقع (XSS) عندما يتضمن التطبيق مدخلات غير موثوقة في صفحة دون التحقق أو الهروب المناسب، مما يسمح للمهاجم بحقن نصوص تعمل في متصفحات المستخدمين الآخرين. في هذه الحالة، احتوى المكون “حدود الحد الأدنى/الحد الأقصى للطلبات لـ WooCommerce” على تنظيف غير كافٍ للإخراج في مسار واحد على الأقل مما سمح بإظهار المدخلات المصممة وتنفيذها في سياق الموقع.

يتم تتبع الثغرة كـ CVE‑2025‑47504 وتم الإبلاغ عنها علنًا. أطلق مطور المكون الإصدار 4.6.5 مع الإصلاحات. وفقًا للتقرير الأصلي، يمكن لمستخدم لديه امتيازات مساهم حقن محتوى مصمم يتم بعد ذلك عرضه وتنفيذه؛ يتطلب الاستغلال الناجح وجود مستخدم متميز لأداء إجراء (على سبيل المثال، النقر على رابط مصمم أو زيارة صفحة مصممة خصيصًا).

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

---

لماذا هذا مهم (تحليل التأثير)

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

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

---

سيناريوهات الاستغلال (أمثلة واقعية)

1. XSS المخزنة في بيانات المنتج/الطلب:
   • يقوم مساهم بتقديم ملاحظات المنتج أو بيانات الطلب مع حمولة مصممة تحتوي على HTML/JS. يقوم المكون الإضافي بعرض تلك البيانات الوصفية على صفحات الدفع أو الإدارة دون الهروب. يقوم المسؤول الذي يزور الصفحة بتنفيذ السكربت.
2. XSS المنعكس عبر إعدادات المكون الإضافي أو نقاط نهاية AJAX:
   • يتم إرسال عنوان URL خبيث مصمم مع سكربت في معلمات الاستعلام إلى محرر أو موافق محتوى. عندما ينقرون عليه، يتم عكس الحمولة مرة أخرى إلى الصفحة بواسطة منطق المكون الإضافي.
3. سلسلة الهندسة الاجتماعية:
   • يستخدم المهاجم حساب مساهم مخترق لنشر محتوى أو تغيير أوصاف المنتجات مع سكربت يتم تفعيله عندما يفتح مدير المتجر محرر المنتج.

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

---

قائمة التحقق من الإصلاح الفوري

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

---

إرشادات الكشف - ماذا تبحث عنه

ابحث في قاعدة البيانات عن علامات شائعة لحمولات XSS وJavaScript المدخلة:

استعلامات قاعدة البيانات (عبر wp‑cli أو phpMyAdmin):

# ابحث في محتوى المنشور"

ابحث في نظام الملفات عن التعديلات الأخيرة أو ملفات PHP المشبوهة:

# ابحث عن ملفات php المعدلة مؤخرًا .

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

---

التصحيح الافتراضي وقواعد WAF (توصيات WP‑Firewall)

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

مهم: تطبيق القواعد المحددة للنقاط النهائية المرتبطة بالمكون الإضافي (صفحات المسؤول، نقاط نهاية AJAX، slug محدد للمكون الإضافي) لتقليل الإيجابيات الكاذبة.

1. حظر الطلبات التي تحتوي على علامات سكربت واضحة في المعلمات

   SecRule REQUEST_URI|ARGS|ARGS_NAMES|REQUEST_HEADERS "@rx ]" \"
       

   هذا يتحقق من وجود “ <script”، “<img”، إلخ. حرفيًا في أي معلمة أو رأس. سيلتقط العديد من محاولات الاستغلال الخام. نطاق إلى نقاط نهاية المسؤول:
   
   أضف شرطًا: REQUEST_URI يحتوي على “/wp-admin/” أو مسار المكون الإضافي.

2. حظر سمات أحداث JavaScript الشائعة وبروتوكول javascript: الزائف

   SecRule ARGS|ARGS_NAMES "@rx on(click|error|load|mouseover|mouseenter|focus)\s*=" \"
       

3. حماية نقاط نهاية AJAX المحددة

   العديد من استغلالات المكونات الإضافية تستغل admin-ajax.php أو نقاط نهاية محددة للمكونات الإضافية. مثال:

   SecRule REQUEST_URI "@beginsWith /wp-admin/admin-ajax.php" \" 
       

4. تطهير الاستجابات (إذا كان WAF يدعم فحص جسم الاستجابة)

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

5. تحديد معدل الوصول وسمعة IP

   حصر المحاولات المتكررة للوصول إلى صفحات إعدادات المكونات الإضافية من IPs غير معروفة. أضف CAPTCHA للزوار المشبوهين.

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

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

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

---

مثال على كود تعزيز الأمان قصير الأجل (نهج WordPress)

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

إنشاء ملف wp-content/mu-plugins/owasp-xss-mitigation.php:

<?php
/*
Plugin Name: OWASP XSS Mitigation (mu)
Description: Short-term sanitization for known plugin output fields.
Author: WP-Firewall
*/

// Sanitize product excerpt and content before output — adjust filters based on plugin behavior.
add_filter( 'the_content', 'wf_sanitize_suspect_content', 2 );
add_filter( 'the_excerpt', 'wf_sanitize_suspect_content', 2 );

function wf_sanitize_suspect_content( $content ) {
    // If content contains suspicious script tags, sanitize the value.
    if ( stripos( $content, '<script' ) !== false || stripos( $content, 'onerror=' ) !== false ) {
        // Remove script tags
        $content = preg_replace( '#<script(.*?)>(.*?)</script>#is', '', $content );
        // Remove javascript: pseudo-protocol
        $content = preg_replace( '#javascript\s*:#is', '', $content );
        // Remove event attributes
        $content = preg_replace_callback( '#<([a-z0-9]+)([^>]*)>#i', function( $m ) {
            $tag = $m[1];
            $attrs = $m[2];
            // remove on* attributes
            $clean = preg_replace( '#\s+on[a-z]+\s*=\s*(["\']).*?\1#is', '', $attrs );
            return '<' . $tag . $clean . '>';
        }, $content );
    }
    return $content;
}

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

---

نظافة الكود: كيف كان يجب على المطور إصلاحه

من منظور البرمجة الآمنة، الإصلاحات المناسبة هي:

• الهروب السياقي عند المخرجات:
  • يستخدم esc_html(), esc_attr(), esc_js() و wp_kses_post() اعتمادًا على سياق الإخراج.
• تحقق من صحة المدخلات وتنظيفها عند الدخول:
  • يستخدم تطهير حقل النص, floatval(), intval(), ، أو المدققين المخصصين للمبالغ الرقمية والإعدادات.
• فحوصات القدرة:
  • تحقق يمكن للمستخدم الحالي على أي إجراءات تغير إعدادات المكون الإضافي أو تعرض واجهة المستخدم الحساسة.
• رموز غير متكررة على تقديم النماذج:
  • استخدم دائما حقل wp_nonce() وتحقق من check_admin_referer() للتقديمات التي تغير التكوين أو المحتوى.

مثال: الهروب الصحيح عند طباعة تسمية أو إعداد:

// بدلاً من echo $user_input;

ولـ HTML المسموح به:

$allowed = array(;

---

قائمة التحقق الجنائية بعد الحادث (إذا كنت تشك في أنك تعرضت للاستغلال)

1. عزل الموقع (وضعه خلف صيانة أو قاعدة WAF).
2. أخذ نسخة احتياطية كاملة من الملفات وقاعدة البيانات (لحفظ الأدلة).
3. تحقق من حسابات المستخدمين:
   • wp_users للمديرين غير المتوقعين أو التغييرات.
   • usermeta للقدرات المشبوهة.
4. فحص التعديلات الأخيرة على المشاركات/المنتجات والخيارات لعلامات السكربت المدخلة.
5. تحقق من دليل التحميلات للملفات PHP التي تم تحميلها حديثًا وأنواع الملفات غير المتوقعة.
6. مراجعة سجلات الخادم للطلبات المشبوهة، خاصةً لصفحات الإدارة مع معلمات الاستعلام.
7. البحث عن المهام المجدولة المستمرة (مدخلات wp_cron التي أضافها المهاجم).
8. تدوير جميع الأملاح والمفاتيح الخاصة بـ WordPress في wp-config.php بعد التنظيف.
9. إعادة إصدار كلمات المرور للموظفين وتطبيق التحقق الثنائي.
10. إذا كنت في شك، استعد نسخة احتياطية معروفة جيدة وطبق التحديثات قبل جعل الموقع عامًا.

---

توصيات تعزيز وقائي (على المدى الطويل)

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

---

أوامر WP-CLI وإدارية عملية (ورقة غش)

• تحديث المكون الإضافي:

  wp plugin update order-minimum-amount-for-woocommerce --version=4.6.5
      

• تعطيل المكون الإضافي:

  wp plugin deactivate order-minimum-amount-for-woocommerce
      

• ابحث في قاعدة البيانات عن السكربتات:

  wp search-replace '<script' '' --skip-columns=guid --dry-run
      

  (استخدم بحذر — جرب أولاً؛ البحث والاستبدال يمكن أن يكون مدمرًا.)

• قائمة المستخدمين ذوي القدرات المرتفعة:

  wp user list --role=administrator --fields=ID,user_login,user_email,role
      

• نسخ احتياطي لقاعدة البيانات (مثال):

  wp db تصدير backup-$(date +%F).sql
      

---

التعليمات

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

س: هل سيقوم WAF بحظر جميع المحاولات؟
أ: تقدم WAFs حماية قوية لكنها ليست بديلاً عن التصحيح. يقلل التصحيح الافتراضي من سطح الهجوم ويمكن أن يحظر أنماط الاستغلال الشائعة، لكن الحمولات المتطورة يمكن أن تتجنب القواعد الساذجة.

س: هل يمكنني فقط إزالة HTML من أوصاف المنتجات؟
أ: يمكنك تطهير المحتوى كإجراء تخفيف، لكن الإصلاح الصحيح هو تحديث الإضافة. قد يؤثر إزالة HTML على المحتوى الشرعي.

---

الجدول الزمني وملاحظات الكشف

تم الإبلاغ عن الثغرة وتم تعيين CVE‑2025‑47504. أطلق مؤلف الإضافة الإصدار 4.6.5 لمعالجة المشكلة. في الفترة بين الكشف العام وتطبيق التصحيح، قد يقوم المهاجمون بفحص المواقع الضعيفة - لذا فإن التحديث في الوقت المناسب و/أو التصحيح الافتراضي لـ WAF أمر ضروري.

---

كيف يساعد WP‑Firewall

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

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

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

---

احمِ موقعك اليوم - ابدأ بخطة WP‑Firewall المجانية

إذا كنت ترغب في حماية فورية ومتعددة الطبقات أثناء تحديث الإضافات وإجراء التدقيقات، اشترك في خطة WP‑Firewall Basic (مجانية). تتضمن الحمايات الأساسية: جدار ناري مُدار، عرض نطاق غير محدود، جدار تطبيق ويب (WAF)، ماسح للبرامج الضارة، وتخفيف ضد مخاطر OWASP Top 10. يساعد هذا المستوى من الحماية في حظر قنوات الاستغلال الشائعة ويمنحك مجالًا لتطبيق التصحيحات وإجراء التحقيقات.

استكشف الخطة واشترك هنا: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

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

---

التوصيات النهائية (بالترتيب)

1. قم بتحديث الإضافة إلى 4.6.5 أو أحدث الآن.
2. إذا لم يكن التحديث ممكنًا على الفور، قم بإلغاء تنشيط الإضافة وتطبيق قواعد WAF الموضحة أعلاه.
3. قم بتدقيق موقعك بحثًا عن علامات الاختراق باستخدام إرشادات الكشف وقائمة التحقق أعلاه.
4. قلل من الصلاحيات وقم بتمكين المصادقة الثنائية لجميع المستخدمين.
5. استخدم WP‑Firewall (الخطة المجانية أو أعلى) للحصول على تصحيح افتراضي مُدار وحماية مستمرة.
6. بعد التصحيح والتنظيف، قم بإجراء تدقيق أمني كامل وضبط ضوابط التقوية لسد الثغرات المستقبلية المماثلة.

---

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