خمس ثغرات منفصلة في ووردبريس أُعلنت خلال الأسبوعين الأخيرين من أغسطس 2026 تشترك في صفة واحدة مقلقة: لا واحدة منها تشترط أن يسجّل المهاجم دخوله أولاً. أربع منها بدرجة خطورة 9.8، وواحدة بدرجة 10.0 كاملة — وهي أقصى ما يبلغه المقياس. وهي تطال مجتمعةً قالباً بيعت منه أكثر من مليون نسخة، وإضافاتٍ تعمل على ما يزيد على نصف مليون موقع. في هذا التنبيه نشرح ما تفعله كل ثغرة فعلاً، وأي المواقع مهدَّدة حقاً، وكيف تفحص موقعك أنت في خمس دقائق، وما الذي تفعله إن تبيّن أنك مكشوف.
الخلاصة السريعة
حدِّث فوراً إن كان موقعك يشغّل أياً مما يلي: WPMU DEV Dashboard (أُصلحت في 5.0.2)، أو قالب Avada مع Fusion Builder (7.16.1 و3.16.1)، أو TranslatePress (3.3.2)، أو Pods (3.3.9.1 أو ترقيع فرع إصدارك)، أو GiveWP (4.16.7.2). الخمس جميعاً تتيح لمهاجم غير مسجَّل الدخول أن يستولي على حساب مدير أو ينفّذ شيفرة على الخادم. وإن تعذّر عليك الترقيع خلال ساعة، فعطّل المكوّن وأزله — تعطيل ميزة أرخص من إعادة بناء موقع.
الثغرات الخمس في لمحة
لماذا تستحق هذه الدفعة انتباهاً أكبر من تنبيه اعتيادي
أغلب ثغرات ووردبريس المنشورة تشترط على المهاجم شيئاً أولاً: حساب مشترك، أو مديراً ينقر رابطاً مُعدّاً، أو إعداداً غير اعتيادي بعينه. وهذه الشروط تمنح المدافع وقتاً، لأن الاستغلال معها لا يتوسّع.
والخمس هنا مختلفة. كل واحدة منها قابلة للاستغلال من زائر مجهول بلا حساب وبلا أي تفاعل من أحد في فريقك. وهذا بالضبط النمط الذي يُحوَّل إلى مسح آلي واسع، والفجوة بين نشر التنبيه وبدء المسح صارت تُقاس بالساعات لا بالأسابيع. بل إن الإصلاح المنشور نفسه هو الخريطة: يقرأ المهاجمون فرق الشيفرة بين الإصدارين ليعرفوا موضع الخلل.
وثمة سبب ثانٍ للجدّية. ثلاثة من المكوّنات الخمسة من النوع الذي يثبّته صاحب الموقع مرة واحدة ثم ينساه — طبقة ترجمة، وإطار حقول محتوى، ولوحة إدارة. لا أحد يعدّها سطح هجوم، فلا أحد يفحص إصدارها.
١. ثغرة GiveWP — CVE-2026-82222 (خطورة 10.0)
أخطر ما في المجموعة، والوحيدة بدرجة 10.0 كاملة. وGiveWP منصّة تبرّعات تستعملها الجمعيات والمؤسسات غير الربحية، على أكثر من 100 ألف تثبيت.
الخلل حقن كائنات PHP ينتهي إلى تنفيذ شيفرة عن بُعد. وبلغة مباشرة: في الإضافة دالة مساعدة يُفترض أن تجعل البيانات المسلسلة الواردة آمنة، لكنها لا تجرّد الكائنات كما تدّعي. فتمرّ بيانات يتحكم بها المهاجم عبر مسار التبرّع، وتُخزَّن في قاعدة البيانات، ثم تُقرأ لاحقاً وتُفكَّك سَلسَلتها كأنها موثوقة. ولأن الإضافة تشحن معها شيفرة مكتبات توفّر سلسلة أدوات صالحة للاستغلال، يتحوّل فكّ السَلسَلة ذاك إلى أوامر نظام تشغيل اعتباطية على خادم الاستضافة.
والأسوأ أن الإضافة تكشف إجراء تسجيل يتجاهل إعداد ووردبريس نفسه الخاص بالسماح بالتسجيل، فيستطيع المهاجم إنشاء الحساب الذي يحتاجه حتى على موقع أُغلق فيه التسجيل العام.
المهدَّد: أي موقع GiveWP حتى الإصدار 4.16.7.1 فيه نموذج تبرّع منشور واحد وبوابة دفع فعّالة واحدة — أي عملياً كل تثبيت حيّ. أُصلحت في 4.16.7.2.
٢. ثغرة WPMU DEV Dashboard — CVE-2026-76581 (خطورة 9.8)
تجاوز مصادقة في مسار الدخول الموحّد (Hub SSO) الخاص بالإضافة. فالإضافة تبني توقيعات HMAC-SHA-256 وتتحقق منها بطريقتين غير متسقتين، والمرحلة الأولى غير المصادَقة من العملية يمكن استغلالها كآلة توقيع: تُنتج توقيعاً صحيحاً يعيد المهاجم استعماله في سياق منطقي آخر، حيث يُقبل دليلاً على دخول مدير.
المهدَّد: المواقع حتى الإصدار 5.0.1 المرتبطة بـWPMU DEV مع تفعيل Hub SSO وربطه بحساب مدير. أما المواقع التي تشغّل الإضافة بلا SSO فليست مكشوفة عبر هذا المسار تحديداً — ومع ذلك عليها التحديث، لأن «غير مكشوف اليوم» يفصله عن نقيضه إعدادٌ واحد. أُصلحت في 5.0.2.
٣. ثغرة قالب Avada مع Fusion Builder — CVE-2026-18431 (خطورة 9.8)
Avada من أكثر قوالب ووردبريس التجارية مبيعاً على الإطلاق، بأكثر من مليون نسخة مباعة، وFusion Builder هو منشئ الصفحات المرفق معه.
الثغرة كتابة ملفات اعتباطية مركّبة من ست نقاط ضعف منفصلة موزّعة على المكوّنين — ثغرات تخويل، وإخفاقات تحقّق من المدخلات، والتباس في حدود الثقة، ومعالجة ملفات غير آمنة. لا واحدة منها كارثية بمفردها، لكنها مجموعة بالتسلسل تتيح لمهاجم غير مصادَق أن يكتب ملفات من اختياره على الخادم، وينشئ ملف PHP، وينفّذه. وهذا اختراق كامل للموقع: وصول إلى قاعدة البيانات، وحقن برمجيات خبيثة، وحسابات مديرين وهمية، وتحويل الزوّار.
المهدَّد: Avada حتى 7.16 عند تثبيت Fusion Builder حتى 3.16 وتفعيله، ووجود محتوى معيّن من إنشاء المدير على الموقع. أُصلحت في Avada 7.16.1 وFusion Builder 3.16.1 — ويجب تحديث الاثنين معاً. فتحديث القالب وحده يُبقي السلسلة قائمة.
٤. ثغرة TranslatePress — CVE-2026-19632 (خطورة 9.8)
كشف معلومات حسّاسة يطال إضافة مثبَّتة على نحو 400 ألف موقع متعدد اللغات. والآلية تكاد تكون أنيقة في مدى اعتياديتها.
فحين يكون الحفظ التلقائي للنصوص مفعّلاً، تجمع TranslatePress كل نصّ تصادفه ليُترجَم لاحقاً — ورسالة إعادة تعيين كلمة مرور ووردبريس، من وجهة نظر الإضافة، مجرّد نصّ آخر. فإن كانت لغة ملف المدير المستهدف مضبوطة على لغة ثانوية منشورة، يُكتب رابط إعادة التعيين الخام، بما فيه مفتاح التعيين بنصّه الصريح ومعاملات الدخول، داخل مخزن الترجمة حيث يستطيع زائر غير مصادَق قراءته. ثم يستعمل المهاجم الرابط ببساطة.
المهدَّد: الإصدارات حتى 3.3.1، وفقط حيث يكون الحفظ التلقائي للنصوص مفعّلاً ولغة ملف أحد المديرين مضبوطة على لغة ثانوية منشورة. وهذا الاجتماع شائع تحديداً في مواقع الأعمال ثنائية اللغة — وهي أصلاً من يحتاج إضافة ترجمة. أُصلحت في 3.3.2.
٥. ثغرة Pods — CVE-2026-19598 (خطورة 9.8)
Pods إطار لأنواع المحتوى والحقول المخصّصة يُستعمل على نحو 100 ألف موقع، ويثبّته عادةً مطوّر أثناء البناء ثم لا يُمسّ بعدها.
الخلل تصعيد صلاحيات عبر تجاوز التخويل. فموجّه AJAX الإداري في الإضافة يمرّر فحوصه الأمنية كلها — قائمة الدوال المسموحة، والتحقق من nonce، وفرض تسجيل الدخول، وبوابات الصلاحيات — عبر دالة خطأ واحدة. وفي أحد مسارات التوافق تكتفي تلك الدالة بتسجيل الإخفاق وإرجاع false بدل إنهاء الطلب. فيمضي التنفيذ كأن كل فحص قد نجح. وبذلك يستطيع مهاجم غير مصادَق تنفيذ إجراءات إدارية مباشرة: أن يرفع نفسه إلى مدير، أو يستبدل كلمة مرور أي حساب على الموقع بما فيه حساب المالك.
المهدَّد: كل الإصدارات حتى 3.3.9. أُصلحت في 3.3.9.1، مع ترقيعات منقولة إلى الفروع الأقدم (2.8.23.4 و2.9.19.4 و3.0.10.4 و3.1.4.2 و3.2.8.3) لتستطيع المواقع المثبَّتة على إصدار رئيسي أقدم أن تُرقَّع دون ترحيل.
كيف تفحص موقعك في خمس دقائق
لا تعتمد على شارة التحديث في لوحتك. فالموقع الذي عُطّلت فيه التحديثات التلقائية، أو انتهت رخصته، لن يُظهر أي إشعار إطلاقاً بينما يشغّل إصداراً مصاباً.
من لوحة ووردبريس: افتح الإضافات ← الإضافات المثبَّتة واقرأ رقم الإصدار المطبوع تحت اسم كل إضافة، ثم المظهر ← القوالب للقالب المفعَّل. قارن بعمود «أُصلحت في» أعلاه. وافحص الإصدار الذي تشغّله فعلاً، لا الذي تتذكّر أنك ثبّته.
من سطر الأوامر إن كان لديك وصول SSH:
wp plugin list --fields=name,status,version
wp theme list --fields=name,status,versionمن cPanel بلا SSH: مدير الملفات ← public_html/wp-content/plugins/، افتح ملف PHP الرئيسي للإضافة، واقرأ سطر Version: في تعليق الترويسة. والأمر نفسه ينطبق على wp-content/themes/.
وتحذير واحد يقع فيه كثيرون: الإضافة المعطَّلة ثغرة أيضاً. فملفاتها تبقى على القرص وتبقى قابلة للوصول عبر HTTP، وأصناف عدّة من ثغرات ووردبريس تُنفَّذ دون أن تكون الإضافة مفعّلة أصلاً. التعطيل ليس إزالة. وما لا تستعمله، احذفه.
إن كنت تشغّل إصداراً مصاباً
اعمل بهذا الترتيب. والتسلسل مهم، لأن الترقيع بعد الاختراق يُغلق الباب والدخيل في الداخل.
أولاً، رقّع أو عطّل. حدِّث إلى الإصدار المُصلَح الآن. وإن كان التحديث سيكسر الموقع وتحتاج نافذة صيانة، فعطّل المكوّن وأزله في هذه الأثناء.
ثانياً، افترض الأسوأ وافحص. الترقيع لا يطرد مهاجماً دخل الأسبوع الماضي. راجع قائمة المستخدمين بحثاً عن حسابات مديرين لا تعرفها، وافحص تواريخ إنشاء التي تعرفها. وابحث عن ملفات عُدِّلت خلال الثلاثين يوماً الماضية، وانتبه خاصةً لأي ملف .php داخل wp-content/uploads — فهذا المجلد للوسائط لا لغيرها. وافحص المهام المجدولة (wp cron event list) بحثاً عن مدخلات لم تنشئها، واقرأ .htaccess بحثاً عن قواعد تحويل محقونة.
ثالثاً، بدّل بيانات الاعتماد. أعد تعيين كل كلمات مرور المديرين، وكلمة مرور قاعدة البيانات، وأي مفاتيح API يحتفظ بها الموقع. وفي حالة ثغرة TranslatePress تحديداً، عامِل أي رابط إعادة تعيين صدر أثناء إصابة الموقع بوصفه معلومة عامة.
رابعاً، أبطل الجلسات. ملفّ ارتباط دخول مسروق ينجو من تغيير كلمة المرور ما لم تُدمَّر الجلسات صراحةً. افرض تسجيل خروج على كل المستخدمين.
خامساً، تحقّق من نسخك الاحتياطية قبل أن تحتاجها. تأكّد أن لديك نقطة استعادة أقدم من تاريخ الإعلان، وتأكّد أنها تُستعاد فعلاً. فالنسخة غير المختبَرة أمنية لا خطة. ودليلنا عن علامات اختراق موقعك يغطّي التأكّد والتنظيف بالتفصيل إن أظهر أي من هذه الفحوص شيئاً.
لماذا لا يكفي الترقيع وحده
كل موقع يعنيه هذا التنبيه كان يشغّل برمجيات مدعومة وشرعية وواسعة الثقة. لا شيء منها مقرصن ولا شيء منها مهجور. أصحاب هذه المواقع لم يخطئوا، وكانوا مكشوفين رغم ذلك — لأن الثغرة وصلت في تحديث اعتيادي لشيفرة كان لديهم كل سبب للوثوق بها.
وهذه هي حجّة الدفاع المتعدد الطبقات. الترقيع طبقة أولى لا وحيدة. فجدار حماية تطبيقات الويب أمام الموقع يصدّ محاولة الاستغلال قبل أن تبلغ الشيفرة المصابة، وهذا يشتري لك الأيام الفاصلة بين الإعلان وموعد صيانتك. وعزل الحسابات على الخادم يمنع موقعاً مخترقاً من أن يصير خادماً مخترقاً. والنسخ الاحتياطي اليومي خارج الخادم يحوّل الكارثة إلى بعد ظهيرة. والتحقق بخطوتين يجعل كلمة المرور المسروقة غير كافية بذاتها. وجردٌ لإضافاتك تراجعه فعلاً — وتحذف منه ما لم تعد تستعمله — يقلّص سطح الهجوم دائماً وبكلفة صفر.
وقائمة متطلبات أمن المواقع في الإمارات عندنا تعرض خط الأساس الكامل الذي نوصي به للشركات العاملة هنا.
كيف نحمي المواقع التي نستضيفها
تدعم بيغ بانغ لحلول تقنية المعلومات شركات الإمارات منذ 2003، وأمن المواقع عندنا ليس إضافة تُباع منفصلة عن الاستضافة — بل هو الطريقة التي بُنيت بها منصّتنا.
كل موقع على خوادمنا يقف خلف جدار حماية تطبيقات ويب بمجموعة قواعد محدَّثة باستمرار، تصدّ أنماط الاستغلال وراء ثغرات كهذه قبل بلوغها شيفرتك. والحسابات معزولة بعضها عن بعض على مستوى نظام الملفات، فلا يبلغ اختراقُ موقعٍ موقعاً آخر. وفحص البرمجيات الخبيثة يعمل باستمرار لا عند الطلب. والنسخ الاحتياطي يجري يومياً إلى تخزين خارج الخادم ويُختبر بالاستعادة الفعلية لا بالاكتفاء بأن المهمة اكتملت. ونتابع إعلانات الثغرات للبرمجيات التي يشغّلها عملاؤنا فعلاً — ولهذا وُجد هذا التنبيه.
وللعملاء على استضافة ووردبريس المُدارة لدينا، تطبيق ترقيعات كهذه مسؤوليتنا لا مسؤوليتهم.
الأسئلة الشائعة
موقعي صغير وزياراته قليلة جداً. هل أنا هدف فعلاً؟
نعم، والمنطق الكامن خلف السؤال هو الخطر بعينه. فهذه الهجمات ليست موجَّهة إلى شركتك؛ إنها عمليات مسح آلي تجوب الإنترنت كله بحثاً عن سطر إصدار. والموقع الصغير ليس متجاوَزاً عنه، بل يُعثر عليه بكلفة أقل. بل إن المواقع الصغيرة المخترقة ثمينة تحديداً لأن أحداً لا يراقبها: فتصير مرحّلات سبام، ومستضيفات برمجيات خبيثة، وروابط في مخطّط أرشفة لطرف آخر، ولشهور غالباً.
التحديثات التلقائية مفعّلة عندي. هل أنا مغطّى؟
جزئياً. فالتحديثات التلقائية تغطّي إضافات مستودع ووردبريس المهيّأة لذلك، لكنها تُغفل عادةً القوالب والإضافات التجارية المرخَّصة من المطوّر مباشرةً — وAvada وWPMU DEV Dashboard كلاهما من هذا الصنف، وكلاهما يحتاج رخصة سارية لتصله التحديثات أصلاً. تحقّق من أرقام الإصدارات بيدك بدل الثقة بأن الأتمتة اشتغلت.
الإضافة معطَّلة. هل هذا يجعلني بمأمن؟
ليس بذاته. فالملفات تبقى على الخادم وتبقى قابلة للوصول، وأصناف عدّة من ثغرات ووردبريس تُنفَّذ على الملفات مباشرةً دون أن تكون الإضافة مفعّلة. احذف كل ما لا تستعمله.
كم يستغرق المهاجمون فعلاً حتى يستغلوا هذه الثغرات؟
في الثغرات غير المصادَقة وعديمة التفاعل كهذه، يبدأ المسح عادةً خلال ساعات من الإعلان العام، لأن الترقيع المنشور يدلّ المهاجمين على موضع الخلل بدقة. عامِل تاريخ الإعلان — لا تاريخ ظهور الاستغلال في البرّية — بوصفه بداية نافذة انكشافك.
كيف أعرف إن كان موقعي قد اختُرق قبل أن أرقّع؟
ابحث عن حسابات مديرين لم تنشئها، وملفات PHP داخل مجلد الرفع، وملفات نواة عُدِّلت حديثاً، ومهام مجدولة غير مألوفة، وقواعد محقونة في .htaccess. وإن بدا شيء خاطئاً فاحفظ السجلات قبل التنظيف — فهي السجل الوحيد لكيفية الدخول، والتنظيف يمحوها.
تحتاج مساعدة في فحص موقعك؟
إن كنت تشغّل أياً من البرمجيات المتأثرة ولست متأكداً إن كان قد وُصل إليك، يستطيع فريقنا تدقيق التثبيت وترقيعه والتأكّد ممّا إن كان قد بقي أثر. تغطّي خدمة إصلاح المواقع المخترقة لدينا المراجعة الجنائية الرقمية وإزالة البرمجيات الخبيثة والتحصين ورفع الحجب من القوائم السوداء، بينما تضع خدمات أمن المواقع الطبقات الوقائية في مكانها.
تحدّث إلى فريقنا في دبي للحصول على تقييم لوضعك الحالي.
