
| اسم البرنامج الإضافي | الحقول المخصصة المتقدمة |
|---|---|
| نوع الضعف | ثغرة في التحكم بالوصول |
| رقم CVE | CVE-2026-8382 |
| الاستعجال | قليل |
| تاريخ نشر CVE | 2026-06-01 |
| رابط المصدر | CVE-2026-8382 |
ACF (<= 6.8.1) التحكم في الوصول المكسور - ماذا يجب على مالكي مواقع ووردبريس فعله الآن
مؤلف: فريق أمان WP‑Firewall
تاريخ: 2026-06-02
العلامات: ووردبريس، الثغرة، ACF، WAF، الأمان
ملخص: تم الكشف عن ثغرة في التحكم في الوصول المكسور (CVE‑2026‑8382) تؤثر على إصدارات مكون ACF حتى 6.8.1. تتيح هذه المشكلة للجهات غير المصرح لها تعديل المشاركات تحت ظروف معينة. يشرح هذا المنشور ما تعنيه الثغرة، وكيفية تقييم المخاطر، والخطوات الفورية التي يجب عليك اتخاذها، والتخفيف العملي بما في ذلك قواعد التصحيح الافتراضية التي يمكنك استخدامها في جدار حماية ووردبريس، ونصائح تعزيز الأمان على المدى الطويل لتقليل مخاطر الحوادث المستقبلية.
جدول المحتويات
- ما حدث (باختصار)
- ماذا تعني “التحكم في الوصول المكسور” لمواقع ووردبريس
- الإصدارات المتأثرة وCVE
- لماذا هذا خطير (التأثير في العالم الحقيقي)
- كيف يمكن للمهاجمين استغلال هذه الثغرة
- قائمة فحص سريعة للكشف (استعلامات السجل، المؤشرات)
- الخطوات الفورية التي يجب عليك اتخاذها الآن
- قواعد التصحيح الافتراضي الموصى بها / قواعد WAF (أمثلة وأسباب)
- قائمة مراجعة كاملة لاستجابة الحوادث والاسترداد
- تعزيز الأمان على المدى الطويل لمواقع ووردبريس
- كيف يساعد WP‑Firewall (الميزات والقيمة)
- احمِ موقعك الآن - ابدأ بخطة WP‑Firewall المجانية
- ملاحظات نهائية ومراجع
ما حدث (باختصار)
أصدرت Advanced Custom Fields (ACF) تصحيح أمان في الإصدار 6.8.2 لمعالجة مشكلة التحكم في الوصول المكسور التي تم تتبعها كـ CVE‑2026‑8382. قبل التصحيح، كان يمكن استدعاء نقاط نهاية أو إجراءات معينة من ACF بواسطة طلبات غير مصرح بها مما سمح بتعديل محتوى المشاركات أو بياناتها الوصفية في بعض الإعدادات. على الرغم من أن البائع صنف شدة المشكلة على أنها منخفضة/متوسطة حسب البيئة، فإن أي تغيير غير مصرح به في محتوى المشاركة يعرض لخطر تسميم SEO، والعدوى السريعة، والتشويه، أو الأبواب الخلفية المستمرة - لذا يُوصى بالإصلاح الفوري.
ماذا تعني “التحكم في الوصول المكسور” لمواقع ووردبريس
“التحكم في الوصول المكسور” هو نوع من الثغرات حيث تفشل وظيفة أو نقطة نهاية في التحقق من أن المتصل مخول لأداء الإجراء المطلوب. في بيئات ووردبريس، يعني ذلك عادةً:
- فحص القدرات المفقودة أو غير الصحيحة (مثل، عدم التحقق من edit_post / manage_options).
- فحص nonce المفقود في ووردبريس على نقاط نهاية AJAX أو REST الإدارية.
- نقاط نهاية REST أو AJAX تقبل وتتصرف بناءً على مدخلات غير مصرح بها.
بالنسبة لـ ACF، تجلت المشكلة كنقطة نهاية سمحت بتحديث كائن المشاركة (أو حقولها ذات الصلة) دون التحقق المناسب من المصادقة والتفويض، مما يعني أن طلب HTTP غير مصرح به يمكن أن يتسبب في تعديل لمشاركة تحت ظروف معينة.
مهم: لا يمكن استغلال التحكم في الوصول المكسور دائمًا مباشرة لإنشاء حساب إداري أو تحميل ملفات PHP - ولكنه غالبًا ما يتم دمجه مع تقنيات أخرى لتصعيد التأثير (على سبيل المثال، حقن المحتوى باستخدام JavaScript ضار، إضافة روابط إلى صفحات تصيد، أو إنشاء مشاركات تتضمن رموز قصيرة تستدعي مكونات إضافية ضعيفة).
الإصدارات المتأثرة وCVE
- المتأثر: إصدارات ملحق Advanced Custom Fields <= 6.8.1
- تم تصحيحه في: 6.8.2
- CVE: CVE‑2026‑8382
إذا كنت تستخدم ACF على موقعك، تحقق من إصدار الملحق على الفور وخطط للتحديث إلى 6.8.2 أو أحدث.
لماذا هذا خطير (التأثير في العالم الحقيقي)
حتى عندما يتم تصنيف الثغرة على أنها “منخفضة” أو “متوسطة” من قبل CVSS، يمكن أن يكون التأثير العملي على موقع الويب قيد التشغيل كبيرًا:
- تسمم المحتوى/SEO: يقوم المهاجمون بتعديل الصفحات أو المنشورات لحقن محتوى وروابط غير مرغوب فيها. هذا يضر بترتيب البحث وسمعة العلامة التجارية.
- قناة توزيع للبرامج الضارة: قد يحتوي المحتوى المحقون على iframes أو JavaScript أو إعادة توجيه إلى صفحات هبوط خبيثة.
- موطئ قدم دائم: يمكن للمهاجمين استخدام محتوى المنشور وحقول التعريف لإخفاء الأبواب الخلفية (على سبيل المثال، عن طريق إدراج رموز قصيرة أو سلاسل base64 التي يعالجها ملحق آخر).
- التصيد / ضرر السمعة: يمكن تعديل المحتوى العام ليحمل معلومات مضللة أو لاستضافة نماذج تصيد بيانات الاعتماد.
نظرًا لأن المنشورات غالبًا ما تكون مرئية للجمهور، يمكن أن ينتشر الضرر بسرعة ويتم فهرسته بواسطة محركات البحث قبل أن تكتشف التغيير.
كيف يمكن للمهاجمين استغلال هذه الثغرة
بينما لن ننشر هنا رمز استغلال إثبات المفهوم (الذي سيساعد المهاجمين)، فإن السلسلة النموذجية تبدو كالتالي:
- يكتشف المهاجم نقطة النهاية الضعيفة (مسار REST، إجراء admin-ajax، أو معالج ACF آخر) على موقع يستخدم ACF <= 6.8.1.
- يرسلون طلبات POST مصممة مع المعلمات التي تقبلها نقطة النهاية (معرف المنشور، حقول المحتوى، حالة المنشور).
- نظرًا لأن نقطة النهاية تفتقر إلى فحوصات القدرة أو nonce المناسبة، يقوم الملحق بتطبيق التغييرات - تحديث محتوى المنشور، التعريف، أو الحالة.
- يتحقق المهاجم من أن التغييرات حية (تم تحديث المحتوى العام).
- قد يكرر المهاجم ذلك على نطاق واسع عبر العديد من المواقع.
ملحوظة: يمكن أن يكون الاستغلال غير مصدق بالكامل، مما يعني أن المهاجمين لا يحتاجون إلى اختراق حساب مستخدم أو تجاوز تسجيل الدخول - مما يجعل عمليات المسح الجماعي الآلي وحملات الاستغلال فعالة ضد المواقع غير المصححة.
قائمة التحقق السريعة للكشف (السجلات والمؤشرات)
إذا كنت تدير مواقع باستخدام ACF، تحقق من هذه العناصر على الفور:
- تأكيد إصدار البرنامج الإضافي
- تسجيل الدخول، لوحة التحكم → الملحقات → Advanced Custom Fields - تحقق من الإصدار.
- أو من الخادم:
wp plugin list | grep -i advanced-custom-fields
- ابحث في سجلات الوصول عن طلبات POST مشبوهة إلى نقاط النهاية الشائعة:
- طلبات POST لـ admin‑ajax.php بأسماء إجراءات متعلقة بـ ACF
- طلبات REST API التي تتعلق بمسارات ACF مثل /wp-json/acf/ أو /wp-json/acf/v
- طلبات POST العامة التي تحمل معلمات مثل post_content و post_title و post_status أو مفاتيح الميتا المستخدمة بواسطة ACF
أوامر grep مثال (استبدل مسار سجل النطاق بمسارك):
- سجلات Apache/nginx المجمعة:
grep "POST" /var/log/nginx/access.log | grep -E "admin-ajax.php|wp-json"grep "acf" /var/log/nginx/access.log
- ابحث عن تغييرات في المشاركات في فترة زمنية قصيرة:
grep "POST" /var/log/nginx/access.log | grep "post_content\|post_title\|post_status"
- سجلات تدقيق WordPress (إذا كانت مفعلة)
- ابحث عن تعديلات غير متوقعة على المشاركات بدون اسم مستخدم مصدق مرتبط.
- تحديد الطوابع الزمنية عندما تغيرت المشاركات: قارن بين post_modified في قاعدة البيانات ونسخك الاحتياطية.
- فحص نظام الملفات وقاعدة البيانات
- امسح الجذر الويب للملفات المعدلة مؤخرًا.
- استعلام قاعدة البيانات عن المشاركات المعدلة مؤخرًا:
SELECT ID, post_title, post_modified, post_author FROM wp_posts ORDER BY post_modified DESC LIMIT 50;
- مؤشرات شائعة للاختراق في المشاركات:
- iframes مخفية، JavaScript مشوش، رموز قصيرة غير مألوفة، كتل base64 في المحتوى أو حقول الميتا.
- منشورات جديدة بمحتوى منخفض الجودة / محتوى مزعج.
إذا رأيت تعديلات غير مفسرة وأنت على ACF <= 6.8.1، اعتبر ذلك أولوية عالية.
الخطوات الفورية التي يجب عليك اتخاذها الآن
إذا كنت تدير مواقع WordPress التي تستخدم ACF، اتبع هذه القائمة ذات الأولويات:
- قم بتحديث ACF إلى 6.8.2 أو أحدث (موصى به)
- أصدرت الشركة الموردة تصحيحًا - التحديث هو الحل الأبسط والأكثر أمانًا.
- اختبر التحديث على بيئة الاختبار إذا كان لديك تخصيصات معقدة، ثم ادفع إلى الإنتاج.
- إذا لم تتمكن من التحديث على الفور، ضع تدابير تخفيف مؤقتة:
- قم بحظر النقاط الضعيفة بشكل صارم باستخدام WAF الخاص بك (أمثلة أدناه).
- قيد الوصول إلى نقاط نهاية AJAX و REST الإدارية من الإنترنت العام حيثما كان ذلك ممكنًا.
- قم بتعطيل مكون ACF الإضافي مؤقتًا إذا كان موقعك يمكنه تحمل التوقف أو الميزات المعطلة.
- احمِ الموقع بقاعدة WAF تمنع محاولات الكتابة غير المصرح بها:
- أنشئ قواعد تمنع POSTs إلى نقاط نهاية REST/AJAX التي تحاول تعديل المحتوى ما لم تحمل رمز مصادقة صالح أو ملف تعريف ارتباط.
- تدقيق واسترجاع:
- قارن المنشورات والصفحات بالنسخ الاحتياطية أو مصدر الحقيقة.
- استرجع التغييرات الخبيثة واستبدل الملفات الخبيثة من النسخ الاحتياطية النظيفة.
- إذا اكتشفت اختراقًا، اعتبر إجراء فحص كامل للموقع وإصلاح احترافي.
- تدوير بيانات الاعتماد:
- أعد تعيين كلمات المرور لمستخدمي الإدارة، وقم بتحديث مفاتيح API والأسرار، وأعد توليد الأملاح إذا لزم الأمر.
- شاشة:
- زد من تسجيل الدخول والمراقبة خلال الـ 48-72 ساعة القادمة.
- أضف تحديد معدل على نقاط النهاية لإبطاء محاولات الفحص الجماعي.
قواعد التصحيح الافتراضية / قواعد WAF الموصى بها (أمثلة وأسباب)
أدناه أمثلة على القواعد والقياسات التي يمكنك إضافتها إلى جدار حماية تطبيق ويب WordPress لحظر محاولات الاستغلال. هذه أمثلة دفاعية - قم بتكييفها مع بيئتك واختبرها على بيئة الاختبار قبل تطبيقها في الإنتاج.
مهم: تم تصميم هذه القواعد لمنع إجراءات الكتابة غير المصرح بها فقط. يجب أن تسمح بإجراءات المسؤول المصرح بها الشرعية (المستخدمون الذين لديهم جلسة WordPress مسجلة الدخول أو nonce صالح).
1) حظر POSTs غير المصرح بها إلى مسارات ACF REST
المنطق: يكشف ACF عن مسارات REST التي يجب أن تفرض المصادقة. حظر POST/PUT/PATCH/DELETE إلى أي نقاط نهاية /wp-json/ مرتبطة بـ ACF من العملاء الذين لا يقدمون مؤشر مصادقة WP صالح.
# رفض POSTs غير المصرح بها إلى نقاط نهاية ACF REST"
الشرح: يرفض الطلب إذا كانت طريقة الكتابة إلى مسار REST الخاص بـ ACF ولا يوجد ملف تعريف ارتباط WordPress مسجل الدخول أو X-WP-Nonce.
2) حظر POSTs المجهولة إلى إجراءات admin-ajax التي تتعلق بمحتوى المنشور
المنطق: العديد من الاستغلالات تستدعي admin-ajax.php مع معلمات الإجراء التي تقوم بتحديث المنشورات أو post_meta. رفض مثل هذه الطلبات عندما لا تكون هناك مصادقة.
SecRule REQUEST_METHOD "POST" "phase:2,chain,deny,status:403,id:1001002,msg:'Block unauth ACF admin-ajax post modification'"
نصيحة: قم بضبط تعبير الإجراء بعد مراجعة استخدام admin-ajax الشرعي لموقعك.
3) حظر أجسام POST المشبوهة التي تحاول تعيين post_content أو post_status
المنطق: الطلبات التي تتضمن معلمات مثل post_content أو post_status من مصادر غير مصدقة تعتبر مشبوهة.
SecRule REQUEST_METHOD "POST" "phase:2,deny,status:403,id:1001003,msg:'Block unauth POST attempts to set post fields'"
4) تحديد معدل & سمعة IP
- تطبيق تحديد معدل لكل IP على طلبات POST إلى نقاط النهاية الإدارية.
- حظر أو تحدي عناوين IP التي تحاول محاولات متكررة عبر مواقع متعددة.
5) قواعد التسجيل والمراقبة
- إضافة إدخال سجل تدقيق مخصص لأي طلبات متعلقة بـ ACF تم حظرها حتى يكون لديك بيانات جنائية (طوابع زمنية، عناوين IP، وكيل المستخدم، جسم الطلب).
ملاحظات وتحذيرات:
- لا تحظر بشكل صارم جميع طرق الكتابة admin-ajax أو REST - هذه مطلوبة من واجهة المستخدم الإدارية. القواعد أعلاه ترفض فقط الطلبات غير المصرح بها التي تفتقر إلى ملفات تعريف ارتباط WP أو رؤوس nonce.
- اختبار القواعد على بيئة الاختبار أو استخدام إجراء “تحدي” (مثل CAPTCHA/403 إلى صندوق الرمل) قبل الرفض الكامل.
قائمة التحقق من استجابة الحوادث والتعافي
إذا كنت تحدد أن موقعًا ما تم استغلاله عبر هذه الثغرة، فاتبع سير عمل استجابة الحوادث:
- احتواء
- ضع الموقع في وضع الصيانة.
- طبق حواجز WAF على الفور (رفض حركة المرور الواردة التي أثارت أنماط الاستغلال).
- إذا لزم الأمر، قم بإيقاف الموقع لمنع انتشار المزيد.
- الحفاظ على الأدلة
- التقط صورة للخادم (القرص، قاعدة البيانات).
- قم بتصدير السجلات (سجلات وصول خادم الويب، سجلات PHP، سجلات WAF) وتخزينها خارج الخط.
- القضاء
- ألغِ مسارات وصول المهاجم: أزل المشاركات الضارة، نظف JavaScript المدخلة، أزل المستخدمين الإداريين غير المعروفين والإضافات/الثيمات المشبوهة.
- استبدل ملفات النواة/الإضافات المعدلة بنسخ نظيفة من المصادر الرسمية.
- افحص وجود webshells والمهام المجدولة/وظائف cron التي أضافها المهاجمون.
- استعادة
- استعد من نسخة احتياطية نظيفة تم أخذها قبل الاختراق إذا كان ذلك ممكنًا.
- قم بتحديث ACF إلى 6.8.2+ وجميع الإضافات والثيمات والنواة الأخرى.
- قم بتدوير كلمات المرور ومفاتيح API لجميع الحسابات.
- أعِد بناء الثقة والتواصل بعد الحادث.
- أبلغ المعنيين إذا كان الموقع يتعامل مع بيانات مستخدمين حساسة.
- انشر ملخص الحادث إذا كان مطلوبًا بموجب السياسة أو اللوائح.
- تحليل ما بعد الحادث وتقوية الأمان
- راجع السبب الجذري وحسّن الضوابط (تقوية، مراقبة، قواعد WAF).
- طبق أقل امتياز على مستخدمي WordPress وقلل عدد الحسابات ذات القدرة الإدارية.
تعزيز الأمان على المدى الطويل لمواقع ووردبريس
بخلاف تصحيح هذه المشكلة المحددة، قم بتمرين تقوية أوسع لتقليل المخاطر:
- حافظ على تحديث نواة WordPress والثيمات والإضافات - قم بأتمتة التحديثات حيثما كان ذلك آمنًا.
- قم بتشغيل جدار حماية تطبيقات الويب المدارة وفعّل التصحيح الافتراضي لنوافذ يوم الصفر.
- فرض مصادقة إدارية قوية: مصادقة ثنائية العامل (2FA) لجميع المسؤولين.
- مبدأ أقل الامتيازات: تحديد حسابات المسؤول وتعيين أدوار دقيقة.
- نسخ احتياطية منتظمة مع احتفاظ غير قابل للتغيير - تخزين النسخ في موقع خارجي والتحقق من النسخ الاحتياطية بشكل دوري.
- مراقبة سلامة الملفات: اكتشاف التعديلات غير المتوقعة على ملفات PHP والسمات.
- تعطيل الإضافات والسمات غير المستخدمة، وإزالتها من القرص.
- مراقبة وتنبيه على التعديلات غير العادية على المشاركات ونشاط حسابات المستخدمين.
- تحديد الوصول إلى نقاط نهاية المسؤول حسب عنوان IP حيثما كان ذلك ممكنًا (على سبيل المثال، تقييد /wp-admin إلى عناوين IP المكتبية).
- استخدام ممارسات الترميز الآمن عند تطوير الإضافات أو السمات - تحقق دائمًا من القدرة وnonce في معالجات AJAX/REST.
كيف يساعد WP‑Firewall
كفريق خلف WP‑Firewall، نساعد مالكي مواقع WordPress على سد الفجوة بين الكشف عن الثغرات والتصحيح الآمن.
ما نقدمه (على مستوى عالٍ):
- قواعد WAF المدارة: تشمل مجموعات قواعدنا تصحيحات افتراضية لثغرات الإضافات الشائعة في WordPress. عندما تظهر ثغرة جديدة مثل التحكم في الوصول المكسور في ACF، نقوم بسرعة بتطوير وتوزيع قواعد تمنع أنماط الكتابة غير المصرح بها الموضحة أعلاه.
- فحص البرمجيات الضارة والتخفيف: فحص مستمر لملفات الموقع وقاعدة البيانات بحثًا عن السكربتات المدخلة، أو محتوى البريد العشوائي، أو الأبواب الخلفية.
- تنبيهات قابلة للتنفيذ: تنبيهات واضحة وذات أولوية (وردود مقترحة) عند تفعيل قاعدة أو عندما تكون إصدارات الإضافات قديمة.
- اقتراحات تعزيز التحكم في الوصول: توصيات محددة لموقعك لتقليل سطح الهجوم.
- السجلات والطب الشرعي: الاحتفاظ وتقديم السجلات الرئيسية التي تحتاجها للتحقيق في محاولات الاستغلال المحتملة.
لماذا هذا مهم: حتى إذا قمت بتطبيق التحديثات بسرعة، فإن الفحص الآلي والاستغلال غالبًا ما يحدث في نفس نافذة الوقت. توفر WAF المدارة مع التصحيح الافتراضي الوقت حتى يمكن تطبيق التصحيح على كل موقع، وتساعد في إيقاف حملات الاستغلال الجماعي من النجاح.
(نحن نقدم خيارات حماية متعددة المستويات لتناسب ملفات تعريف المخاطر المختلفة - انظر تفاصيل الخطة أدناه.)
احمِ موقعك الآن - ابدأ بخطة WP‑Firewall المجانية
إذا لم تكن تدير حاليًا جدار حماية WordPress مدارة، فإن الوقت قد حان لإضافة واحدة - خاصة بينما يرتفع عدد الماسحات الآلية التي تبحث عن ACF <= 6.8.1.
لماذا تبدأ بخطتنا المجانية؟
- حماية أساسية: تتضمن الخطة الأساسية المجانية جدار حماية مدارة وقواعد WAF تمنع الهجمات الشائعة غير المصرح بها مثل نمط التحكم في الوصول المكسور في ACF.
- عرض نطاق غير محدود: نحن نحمي حركة المرور دون تقييد أو تكاليف مفاجئة.
- ماسح البرامج الضارة: يقوم بفحص موقعك بحثًا عن السكربتات المدخلة والتغييرات المشبوهة.
- التخفيف من مخاطر OWASP Top 10: دفاعات أساسية ضد ثغرات تطبيقات الويب الشائعة.
ابدأ في حماية موقع WordPress الخاص بك اليوم مع WP‑Firewall Basic (مجاني): https://my.wp-firewall.com/buy/wp-firewall-free-plan/
إذا كنت بحاجة إلى تنظيف تلقائي، قوائم السماح/الرفض لعناوين IP، وتقارير شهرية، فإن مستوياتنا المدفوعة (Standard و Pro) تضيف تلك الميزات وتكون أسعارها متاحة للوكالات ومالكي المواقع الذين يرغبون في تغطية أقوى وخيارات استرداد أسرع.
نصائح عملية لمالكي المواقع الذين لديهم العديد من التثبيتات (وكالات / مضيفون)
إذا كنت تدير العديد من المواقع:
- تحقق من إصدارات المكونات الإضافية بكميات كبيرة عبر WP‑CLI وتحديثات السكربتات.
- مثال:
قائمة مكونات wp --format=csv | grep advanced-custom-fields
- مثال:
- استخدم وحدة تحكم إدارة WAF مركزية حتى تتمكن من طرح تصحيحات افتراضية لجميع مواقعك على الفور.
- استخدم بيئة الاختبار للتحقق من تصحيح البائع أولاً إذا كانت هناك تكاملات ACF مخصصة.
- أعطِ الأولوية للمواقع ذات الحركة العالية ومواقع التجارة الإلكترونية للتصحيح والمراقبة الفورية.
- حافظ على دليل حوادث يتضمن من يجب إخطاره، مواقع النسخ الاحتياطي، ومهام الاسترداد.
الملاحظات النهائية
- تحديث المكون الإضافي: الإجراء الأكثر فعالية هو تحديث Advanced Custom Fields إلى 6.8.2 أو أحدث.
- إذا لم تتمكن من التحديث على الفور، نفذ قواعد WAF المستهدفة التي تمنع محاولات الكتابة غير المصرح بها إلى نقاط نهاية REST و AJAX وأضف المراقبة لاكتشاف التغييرات المشبوهة في المشاركات.
- إذا كنت تشك في وجود استغلال، تعامل معه كحادثة: احتوِ، احفظ الأدلة، اقضِ، استعد، وقوِّ.
نحن نقدر أن الأمان هو عملي، وليس مجرد نظري. إذا كنت بحاجة إلى مساعدة في تنفيذ قواعد WAF المذكورة أعلاه، أو اختبارها، أو إجراء مراجعة جنائية بعد نشاط مشبوه، يمكن لفريق WP‑Firewall المساعدة. يوفر خطتنا المجانية Basic جدار حماية مُدار وفحص للبرامج الضارة حتى تتمكن من حظر الفحوصات الجماعية والتقاط التعديلات المشبوهة بسرعة — سجل هنا: https://my.wp-firewall.com/buy/wp-firewall-free-plan/
المراجع والقراءات الإضافية
- CVE‑2026‑8382 (قائمة CVE الرسمية)
- ملاحظات إصدار Advanced Custom Fields / سجل التغييرات (ابحث عن 6.8.2)
- وثائق مطوري WordPress: Nonces وفحوصات القدرات (أفضل الممارسات لمؤلفي المكونات الإضافية)
(إذا كنت بحاجة إلى مساعدة في تصنيف التنبيهات، أو إنشاء أو اختبار قواعد WAF لبيئتك المحددة، أو التحقق من أن موقعك نظيف بعد استغلال مشبوه، فإن مهندسي الدعم لدينا متاحون للمساعدة.)
