---
title: "إضافة aBlocks: مساهم بيصير محرر بثغرة تصعيد صلاحيات 8.8"
description: "النسخ لحد 2.17.0 من إضافة aBlocks فيها ثغرة بتقييم 8.8 بتخلي حساب مساهم يطلع بجلسة محرر كاملة. حدّث لآخر نسخة، 2.18.0، وراجع حسابات المحررين بموقعك."
url: https://ihsanalapsi.dev/articles/ablocks-contributor-editor-escalation
lang: ar
date: 2026-10-25
updated: 2026-10-25
tags: ["تحديثات أمنية", "أمن التطبيقات", "WordPress"]
author: Ihsan Alapsi (إحسان العبسي)
---
# إضافة aBlocks: مساهم بيصير محرر بثغرة تصعيد صلاحيات 8.8

إذا موقعك ووردبريس وفيه إضافة aBlocks، وعندك مساهمين بيكتبوا مسودات، في ثغرة جديدة لازم تنتبه إلها. [سجل CVE](https://www.cve.org/CVERecord?id=CVE-2026-110018) بتاريخ 24 تشرين الأول 2026 وثّق ثغرة تصعيد صلاحيات بالإضافة بتقييم CVSS 8.8 من 10: مساهم بيقدر يصير محرر بجلسة موثّقة كاملة، بدون ما يسرق كلمة سر حدا وبدون ما يكون مدير. والنسخ المتأثرة هي كل النسخ لحد 2.17.0.

## شو هي الثغرة؟

الـ CVE-2026-110018 ثغرة تصعيد صلاحيات بإضافة aBlocks: حساب مساهم بياخد دور أعلى من دوره عن طريق نقطة تسجيل المستخدمين تبع نماذج الإضافة.

aBlocks إضافة كتل Gutenberg فيها منشئ لوحات مستخدمين ونوافذ منبثقة ونماذج. نقطة الضعف هي نقطة REST تبع تسجيل النماذج: `/ablocks/v1/form-builder/registration`.

النقطة مسجّلة بدون فحص صلاحيات، يعني `permission_callback` بترجّع «صح» دايماً. ودالة التسجيل بتقرا حقل `roleSlug` مباشرة من خصائص الكتلة يلي بيتحكم فيها المهاجم بمحتوى المنشور، وما بتتأكد إنو نوع النموذج هو «تسجيل». فحص النوع هاد موجود، بس بيشتغل وقت الحفظ وما بيتكرر وقت التنفيذ.

## كيف بيصير المساهم محرر؟

المساهم بيخبّي دور من اختياره جوّا نموذج محفوظ، وبعدين بيخلي نقطة التسجيل تطبّقه. الخطوات حسب وصف السجل:

1. المساهم بيحفظ كتلة نموذج بنوع «تسجيل دخول» بدل «تسجيل»، وهيك بيضل حقل `roleSlug` بالقيمة يلي اختارها، لأن فحص وقت الحفظ ما بينطبق على نوع «تسجيل الدخول».
2. بعدين بيستدعي نقطة التسجيل برمز `wp_rest` صحيح، وبيمرق من فحص ملكية المنشور لأنه صاحب المسودة، فدالة التسجيل بتقرا `roleSlug` المحفوظ.
3. الدالة بتعمل حساب جديد من بيانات النموذج، وبتعطيه الدور المحفوظ بـ `WP_User::set_role()`، وبتسجّل دخوله بـ `wp_set_auth_cookie()`. فالمهاجم بيطلع بجلسة موثّقة كاملة بالدور الجديد.

وحسب [كود الإضافة نفسه](https://plugins.svn.wordpress.org/ablocks/tags/2.16.0/includes/api/form-builder-controller.php)، دالة التسجيل بترفض الطلب قبل ما تعمل أي حساب إذا التسجيل مسكّر بإعدادات ووردبريس (خيار Anyone can register)، فالخطر على المواقع يلي فاتحة التسجيل.

التصعيد بيوقف قبل دور المدير: الفحص الداخلي `is_safe_registration_role()` بيرفض أي دور فيه صلاحيات متل `manage_options` و`edit_users` و`delete_users` و`create_users` و`promote_users` و`edit_theme_options`. لهيك على تثبيت ووردبريس عادي، أعلى دور بيوصله المهاجم هو المحرر.

و[المحرر بووردبريس](https://wordpress.org/documentation/article/roles-and-capabilities/) بينشر ويعدّل منشورات غيره وصفحات الموقع، وبيرفع ملفات. يعني مهاجم كان يحفظ مسودات بس، صار بيقدر ينشر باسم موقعك ويغيّر شغل غيره.

## شو وضع الإصلاح؟

السجل بيعدّ النسخ لحد 2.17.0 متأثرة، وآخر نسخة من aBlocks هي 2.18.0، فالإجراء الصح هو التحديث لـ 2.18.0.

[صفحة الإضافة على WordPress.org](https://wordpress.org/plugins/ablocks/) بتقول إنو 2.18.0 نزلت بـ 20 تشرين الأول 2026، وسجل تغييراتها فيه بند واحد: «إصلاح مشاكل أمان بالمحتوى الديناميكي».

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

نفس القصة شفناها مع [مفاتيح UpdraftCentral المسروقة](/articles/updraftcentral-key-compromise-backdoors): إضافة وحدة بصلاحيات واسعة بتكفي لتفتح موقع كامل. وهون إضافة كتل عندها أكتر من 2,000 تثبيت نشط صارت باب لترقية الأدوار، لأن فحص واحد انحط بمكان غلط.

## شو تعمل هلق؟

حدّث aBlocks لـ 2.18.0، بعدين راجع حسابات المحررين وسجلات الطلبات وسياسة التسجيل بموقعك.

1. افتح صفحة الإضافات بلوحة التحكم وشوف نسخة aBlocks. إذا 2.17.0 أو أقدم، حدّث فوراً لآخر نسخة، 2.18.0.
2. راجع قائمة المستخدمين: أي حساب محرر ما بتعرفه، أو مساهم صار محرر بدون طلب منك، نزّل دوره لـ «مشترك» وحقّق بالموضوع قبل ما ترجّعله أي صلاحية.
3. راجع سجلات الطلبات على نقطة `/ablocks/v1/form-builder/registration`، وخصوصاً الطلبات من حسابات مساهمين.
4. إذا التسجيل مفتوح بموقعك أو بتقبل مساهمين من برّا، راجع هالسياسة: كل مساهم جديد بيقدر يستغل هالثغرة لحد ما تتأكد إنو نسختك محدّثة.

ووردبريس نفسه عم يرتّب طريقة حفظ الأسرار: [ووردبريس 7.2 بيتا جاب مكان رسمي لمفاتيح الـ API](/articles/wordpress-7-2-beta-secrets-api). بس هالشي ما بيسكّر ثغرة بإضافة قديمة، فتحديث الإضافات بيضل شغلك إنت.

## إمتى آخر مرة راجعت أدوار المستخدمين بموقعك؟

إذا ما بتتذكر، هلق وقتها، وبالذات إذا عندك aBlocks ومساهمين. كل يلي احتاجته هالثغرة حساب مساهم عادي على موقع فاتح التسجيل، ونقطة تسجيل بتثق بالمحتوى المحفوظ متل ما هو.

وإذا بتكتب إضافات: أي حقل بيأثر على الصلاحيات لازم ينفحص وقت ما بينستعمل، حتى لو انفحص وقت ما انحفظ، لأن المهاجم بيتحكم بالمحتوى المخزّن. بـ aBlocks النموذج انحفظ «تسجيل دخول» ومرق من الفحص، وبعدين نقطة التسجيل استعملت الدور يلي جوّاه.

وبعد ما تحدّث، اسأل حالك: كم إضافة عندك بتقبل مدخلات من أدوار منخفضة وبتثق فيها وقت التنفيذ؟

إذا بدك حدا يلاقي الثغرات بموقعك قبل ما يلاقيها غيرك، [مُحَصَّن بيفحص منصتك وبيسلّمك خطة إصلاح واضحة](/muhassan).

## FAQ

**هل المهاجم بيقدر يصير مدير موقع؟**

لأ، على تثبيت ووردبريس عادي. الفحص الداخلي بيرفض الأدوار يلي فيها صلاحيات إدارة متل manage_options وedit_users، فأعلى دور بيوصله المهاجم هو المحرر.

**أنا على نسخة 2.18.0، هل أنا بأمان من هالثغرة؟**

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

**هل الثغرة بتحتاج حساب مسجّل؟**

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

**كيف بعرف إذا حدا استغلها عندي؟**

راجع قائمة المستخدمين على أي حساب محرر ما بتعرفه، لأن نقطة التسجيل بتعمل حساب جديد بالدور المحفوظ. وراجع سجلات الطلبات على ablocks/v1/form-builder/registration، وخصوصاً من حسابات مساهمين.