دليل عملي

ثغرة PolyShell ‏CVE-2026-48356: فحص متاجر ماجنتو وإصلاحها

الأمان والمراقبة12 دقيقةً للقراءةعدد الخطوات: 17

أُدرجت الثغرة CVE-2026-48356، المعروفة باسم PolyShell، في فهرس KEV التابع لـCISA في 27 أكتوبر 2026: استغلال متاجر Adobe Commerce وMagento Open Source أمر ثابت. بالنسبة لوكالة، لا يقتصر السؤال على «هل يجب التحديث؟»، بل «أيّ المتاجر تفتقد التصحيح APSB26-73، وأيّها يحمل بالفعل ملف webshell؟». التصحيح يزيل الثغرة، لكنه لا يزيل الملفات المزروعة ولا شيفرات JavaScript المحقونة. إليك الجرد، والتحديث، وأربعة فحوص للاختراق، وتدوير صلاحيات الوصول، مع تقرير مؤرَّخ يُسلَّم للعميل.

المحتويات· PolyShell: ما هو ثابت، وأين تختلف المصادر1/14
  1. 01PolyShell: ما هو ثابت، وأين تختلف المصادر
  2. 02ما تقوله المصادر، وما تستخلصه منها
  3. 03لماذا لا يُغلق التصحيح الملف
  4. 04ما يتركه هذا الإجراء بين يديك
  5. 05الإصدارات المتأثرة والمصحَّحة بحسب APSB26-73
  6. 06جرد إصدار كل متجر
  7. 07جمّد الحالة قبل أي تعديل: إنها دليل أيضًا
  8. 08تطبيق التصحيح دون انقطاع طويل
  9. 09البحث عن آثار الاختراق
  10. 10تقوية: لا مكان لـPHP تحت pub/media
  11. 11استكشاف الأعطال: العوائق الشائعة أثناء الإجراء
  12. 12بعد التنظيف: ما يجب تدويره
  13. 13التقرير المؤرَّخ الذي يُسلَّم لكل عميل
  14. 14ما تحتفظ به، والمصادر التي تُستشهد بها

PolyShell: ما هو ثابت، وأين تختلف المصادر

تمسّ الثغرة CVE-2026-48356، المعروفة باسم PolyShell، منصتَي Adobe Commerce وMagento Open Source. تصنّفها بطاقة NVD، المنشورة في 14 يوليو 2026 استنادًا إلى تصريح Adobe، ضمن CWE-434 (رفع ملف من نوع خطِر)، بدرجة CVSS 3.1 تبلغ 9.3 ومتّجه AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N. التصحيح هو نشرة Adobe ذات المرجع APSB26-73. وفي 27 أكتوبر 2026 أضافتها CISA إلى فهرس الثغرات المستغَلة (KEV)، مع مهلة تنتهي في 10 نوفمبر 2026 للوكالات الفدرالية الأمريكية: لم يعد الاستغلال فرضية.

لا تصف المصادر الثغرة بالطريقة نفسها. تتحدث NVD عن تنفيذ شيفرة عشوائية «في سياق المستخدم الحالي» يتطلب تفاعلًا: على الضحية أن يزور رابطًا مفخَّخًا أو صفحة مخترَقة، ويتجاوز الأثر المكوّن المعرَّض للثغرة. أما Sansec والصحافة المتخصصة فتصفان عمليات رفع ملفات تنتهي بزرع ملفات webshell على الخادم. لا نحسم بين القراءتين. والسلوك الحذر لوكالة هو معاملة كل متجر بقي بلا تصحيح على أنه متجر قد يحمل بالفعل ملف webshell.

ما تقوله المصادر، وما تستخلصه منها

مرّر الجدول أفقيًا

المصدرما يؤكدهما تستخلصه
NVDCWE-434، درجة CVSS 3.1 تبلغ 9.3، تفاعل مطلوب، تنفيذ في سياق المستخدم الحاليالمعرّفات التي تُدوَّن في ملف العميل
CISA، فهرس KEVاستغلال ثابت، إضافة في 27 أكتوبر 2026، مهلة فدرالية حتى 10 نوفمبر 2026أفق للعمل، لا موعد للاطمئنان
Adobe، النشرة APSB26-73الإصدارات ذات اللاحقة 2026-jul غير متأثرةالإصدار المستهدف لكل فرع
Sansec، 30 مارس 2026موجة هجوم واسعة: 471 متجرًا مخترقًا في ساعة واحدة، ملف webshell بلغة PHP ثم أبواب خلفية `accesson.php`الملفات التي يُبحث عنها على القرص
Sansec، 24 أكتوبر 2026محمّل JavaScript في `cms_block`، حملة متابَعة منذ يوليو 2025 على 953 متجرًا؛ 102 من أصل 169 تثبيتًا غير مصحَّح كانت تحمل ملفات مرفوعةالاستعلامات التي تُنفَّذ على قاعدة البيانات
الصحافة المتخصصةرفع ملفات يؤدي إلى ملفات webshellقراءة يجب التحقق منها بمصادر أخرى، لا مصدر أولي

لماذا لا يُغلق التصحيح الملف

تطبيق APSB26-73 يزيل الثغرة، لكنه لا يزيل شيئًا مما دخل بالفعل. ملف webshell زُرع قبل التحديث يبقى على القرص، وباب خلفي accesson.php يظل يستجيب، وشيفرة محقونة في cms_block تظل تُقدَّم لكل زائر، وحساب مسؤول أنشأه المهاجم يبقى صالحًا. وتلخّص Sansec الأمر هكذا: إزالة الشيفرات لا تُزيل وصول المهاجم.

تُبيّن الدراسة الثانية لـSansec لماذا يُطرح السؤال على مستوى مجموعة المتاجر كاملة. فمن أصل 169 تثبيتًا لـMagento 2 غير مصحَّح جرى فحصها، كان 102 يحمل ملفات مرفوعة عبر PolyShell أو SessionReaper ‏(CVE-2025-54236، المصحَّحة بالنشرة APSB25-88)، أي 60 %. لذلك فترتيب العمل ثابت: الجرد، ثم تجميد الحالة، ثم التحديث، ثم البحث عن الآثار، ثم تدوير صلاحيات الوصول، وأخيرًا تقرير مؤرَّخ يُسلَّم للعميل. تجاوُز التدوير لكسب ساعة يعني ترك المفاتيح للمهاجم الذي ربما نسخها بالفعل.

ما يتركه هذا الإجراء بين يديك

  • جرد لكل متجر — الإصدار (Commerce أو Open Source)، ورقم النسخة بدقة، ووجود التصحيح 2026-jul أو غيابه.
  • إصدار مستهدف لكل فرع — يُقرأ في النشرة APSB26-73، دون تخمين للترقيم.
  • حالة مجمَّدة قبل أي تدخل — لقطة (snapshot) وتصدير لقاعدة البيانات يُحفظان دليلًا، قبل أي تنظيف.
  • أربعة فحوص قابلة للتكرار — الملفات تحت pub/media، والأبواب الخلفية accesson.php، وشيفرات JavaScript في cms_block وفي cms_page.
  • تدوير كامل لصلاحيات الوصول — حسابات الإدارة، ومفاتيح API والتكامل، وقاعدة البيانات، ومفتاح التشفير، وSSH وSFTP.
  • تقرير مؤرَّخ لكل عميل — ما جرى فحصه، وما وُجد، وما صُحّح، وما لم يُفحص.

الإصدارات المتأثرة والمصحَّحة بحسب APSB26-73

مرّر الجدول أفقيًا

المنتج والفرعمتأثر حتىالإصدار المصحَّح
Adobe Commerce 2.4.92.4.92.4.9-2026-jul
Adobe Commerce 2.4.82.4.8-p52.4.8-2026-jul
Adobe Commerce 2.4.72.4.7-p102.4.7-2026-jul
Adobe Commerce 2.4.62.4.6-p152.4.6-2026-jul
Adobe Commerce 2.4.52.4.5-p172.4.5-2026-jul
Adobe Commerce 2.4.42.4.4-p182.4.4-2026-jul
Magento Open Source 2.4.92.4.92.4.9-2026-jul
Magento Open Source 2.4.82.4.8-p52.4.8-2026-jul
Magento Open Source 2.4.72.4.7-p102.4.7-2026-jul
Magento Open Source 2.4.62.4.6-p152.4.6-2026-jul
Adobe Commerce B2B1.5.3، 1.5.2-p5، 1.4.2-p10، 1.3.4-p17، 1.3.3-p181.5.3-2026-jul، 1.5.2-2026-jul، 1.4.2-2026-jul، 1.3.4-2026-jul، 1.3.3-2026-jul
Adobe Commerce Events1.20.0 وما قبلها1.21.0
Magento Open Source 2.4.5 و2.4.4غائبتان عن قائمة NVDلا استنتاج: اقرأ نشرة Adobe

جرد إصدار كل متجر

  1. قراءة الإصدار المعلَن

    cd /var/www/client-store
    bin/magento --version
    يعرض الأمر نوع الإصدار ورقمه. المسار مثال: عدّله بحسب كل استضافة. شغّله بمستخدم النظام المالك للملفات، لا بحساب root، حتى لا تُغيّر صلاحيات ذاكرة التخزين المؤقت.

  2. التحقق المتقاطع عبر Composer

    composer show magento/product-community-edition
    لـMagento Open Source، أو
    composer show magento/product-enterprise-edition
    لـAdobe Commerce. يقرأ Composer ما هو مثبَّت فعلًا. إذا اختلفت القراءتان، فالمرجع هو Composer، ويُدوَّن الفرق.

  3. مسح خادم كامل

    find /var/www /home -name composer.lock -not -path '*/vendor/*' -exec grep -H -A1 '"name": "magento/product-' {} +
    كل ملف يظهر ينتمي إلى تثبيت Magento، ويلي سطرُ version اسمَ الحزمة. بيئة ما قبل الإنتاج المكشوفة أو نسخة قديمة مفكوكة الضغط تُحسب متجرًا: فهي معرَّضة بالطريقة نفسها إذا كانت تُخدَّم.

  4. التصنيف بجدول الإصدارات

    قارن الرقم الذي قرأته بالجدول أعلاه. قاعدة القراءة: كل إصدار لا يحمل اللاحقة 2026-jul الخاصة بفرعه يجب معالجته. بالنسبة لـMagento Open Source 2.4.5 و2.4.4، الغائبتين عن قائمة NVD، لا تكتب «غير متأثر»: أحِل إلى نشرة Adobe وعامِل المتجر على أنه معرَّض ما لم تقرأ خلاف ذلك.

  5. تدوين سطر لكل متجر

    العميل، والخادم، والمسار، ونوع الإصدار، والإصدار المقروء، وتاريخ القراءة وساعتها. أضف من الآن الأعمدة التي ستحتاجها لاحقًا: التصحيح مطبَّق، ونتيجة الفحوص الأربعة، والصلاحيات المدوَّرة. يصبح هذا الجدول الوثيقة المحورية في الملف المسلَّم للعميل.

جمّد الحالة قبل أي تعديل: إنها دليل أيضًا

قبل أي تعديل، جمّد المتجر كما وجدته. على خادم VPS، تلتقط اللقطة (snapshot) للخادم، إن وفّرها مضيفك، القرص كاملًا؛ أضف تصديرًا لقاعدة البيانات وأرشيفًا للشيفرة على وسيط لا يمسّه التحديث. الفرق بين الأداتين مفصّل في مقارنتنا بين اللقطة والنسخة الاحتياطية.

تخدم هذه الحالة مرتين. فهي تتيح التراجع إذا كسر التحديث مسار الشراء. وهي قبل كل شيء تحفظ الدليل: إذا دخل المهاجم، فالملفات المزروعة وتواريخها وكتل CMS المعدَّلة موجودة في هذه النسخة، ولا مكان آخر لها بعد التنظيف. كما تُحيل CISA إلى متطلباتها للفرز الجنائي الرقمي بالنسبة للأنظمة المعنية. لا تحذف هذه الحالة ولا تستبدلها ما دام الملف لم يُغلق.

الترقية بين الفروع، من 2.4.6 إلى 2.4.9 مثلًا، مشروع آخر: إجراؤها عبر Composer وجدول دعمها موجودان في دليل الترقية لدينا. هنا يبقى كل متجر في فرعه ويتلقى التصحيح فقط.

تطبيق التصحيح دون انقطاع طويل

  1. التجربة على بيئة ما قبل الإنتاج

    استعِد الحالة المجمَّدة على بيئة ما قبل الإنتاج، أو استنسخ المتجر، ونفّذ التحديث هناك أولًا. قِس مدة كل أمر: هذه المدة هي التي تحدد نافذة الصيانة التي تُعلنها للعميل.

  2. تثبيت الإصدار المصحَّح

    composer require magento/product-community-edition=<fixed-version> --no-update
    استبدل الحزمة بـmagento/product-enterprise-edition لـAdobe Commerce، و<fixed-version> بالإصدار ذي اللاحقة 2026-jul الخاص بفرعك، كما تكتبه النشرة.

  3. حلّ التبعيات واعتماد ملف القفل

    composer update magento/product-community-edition --with-all-dependencies
    راجِع قائمة الحزم المعدَّلة. ملف composer.lock الناتج والمختبَر هو الذي ستنشره: بيئة الإنتاج لا تحلّ شيئًا بعد ذلك، بل تثبّت فقط.

  4. فتح نافذة الصيانة في الإنتاج

    bin/magento maintenance:enable
    bin/magento maintenance:allow-ips <your-ip>
    كل ما سبق جرى دون إيقاف البيع. الأمر الثاني يتيح لك اختبار المتجر قبل إعادة فتحه.

  5. التثبيت والتطبيق

    composer install --no-dev
    bin/magento setup:upgrade
    bin/magento setup:di:compile
    bin/magento setup:static-content:deploy
    مع ملف قفل معتمَد مسبقًا، يقتصر الانقطاع على هذه الأوامر الأربعة.

  6. إعادة الفتح والتحقق

    bin/magento maintenance:disable
    composer show magento/product-community-edition
    يجب أن يكون الإصدار المثبَّت هو الإصدار المصحَّح لفرعك. نفّذ طلبًا عبر بوابة الدفع في وضع الاختبار، ثم دوّن الإصدار والساعة في الجدول.

البحث عن آثار الاختراق

  1. سرد الملفات المزروعة تحت pub/media

    find pub/media/custom_options/ pub/media/customer_address/ -type f ! -name '.htaccess'
    أمر نشرته Sansec، يُشغَّل من جذر المتجر. كل ملف يظهر يجب فحصه، ولا سيما شيفرة PHP. انسخه خارج الشجرة العامة مع تاريخ تعديله قبل حذفه.

  2. البحث عن الأبواب الخلفية accesson.php

    find . -name 'accesson.php' -type f
    تشير Sansec إلى هذا الملف «في عدة مجلدات»: شغّل البحث من الجذر، لا تحت pub/ فقط. النتيجة الفارغة تُثبت غياب هذا الملف تحديدًا، لا غياب أي باب خلفي.

  3. الاستعلام في الجدول cms_block

    SELECT block_id, identifier, update_time FROM cms_block WHERE content LIKE '%fpCode%' OR content LIKE '%se_referrer%' OR content LIKE '%localStorage.getItem%';
    استعلام نشرته Sansec. أضف بادئة الجداول الخاصة بالتثبيت إن وُجدت. يساعد العمود update_time على تأريخ الحقن.

  4. الاستعلام في الجدول cms_page

    SELECT page_id, identifier, update_time FROM cms_page WHERE content LIKE '%fpCode%' OR content LIKE '%se_referrer%' OR content LIKE '%localStorage.getItem%';
    الفحص نفسه على صفحات CMS. النتيجة ليست بالضرورة خبيثة: قد يظهر localStorage.getItem في شيفرة مشروعة. اقرأ المحتوى قبل أن تحكم.

  5. المطابقة مع المؤشرات المنشورة

    بالنسبة لموجة مارس 2026، نشرت Sansec نطاق محمّل هو lanhd6549tdhse.top، ومفتاح localStorage هو 136c1e07507f4a97، ووسم باب خلفي هو 8194460. ابحث عنها في النتائج السابقة وفي الملفات التي عثرت عليها، مثلًا بالأمر grep -rl 'lanhd6549tdhse' pub/ app/. هذه القائمة ليست شاملة: غيابها لا يبرّئ المتجر.

  6. فحص حسابات المسؤولين

    SELECT user_id, username, email, created, logdate, is_active FROM admin_user ORDER BY created DESC;
    الحساب الذي لا يعرفه أحد، أو الذي أُنشئ في تاريخ قريب من تاريخ ملف مشبوه، يُعطَّل ثم يُوثَّق. الفحص الشهري لهذه النقاط على كل VPS للعملاء موصوف في قائمة التدقيق لدينا.

تقوية: لا مكان لـPHP تحت pub/media

بمعزل عن PolyShell، لا ينبغي لمجلد يستقبل ملفات يرسلها الزوار أن ينفّذ PHP أبدًا. تحقّق من أن إعدادات nginx أو Apache لديك ترفض تنفيذ الشيفرات تحت pub/media، واختبر ذلك على بيئة ما قبل الإنتاج بملف غير مؤذٍ. هذا ليس إجراء تخفيف نشرته Adobe لهذه الثغرة، ولا يحلّ محل التصحيح: إنه تقوية عامة تقلّل أثر أي عملية رفع ناجحة في المستقبل.

استكشاف الأعطال: العوائق الشائعة أثناء الإجراء

«Your requirements could not be resolved to an installable set of packages.» يرفض Composer الإصدار المطلوب: وحدة من طرف ثالث تثبّت تبعية ما، أو قيد الاستقرار في composer.json يستبعد الإصدار المستهدف. الأمر composer why-not magento/product-community-edition <fixed-version> يسمّي الحزمة التي تعرقل. عالِج ذلك على بيئة ما قبل الإنتاج، لا في الإنتاج أبدًا.

«Please upgrade your database: Run "bin/magento setup:upgrade" from the Magento root directory.» يعرض المتجر هذه الرسالة بعد تحديث الشيفرة: لم تُنفَّذ خطوة setup:upgrade، أو فشلت. أعِد تشغيلها، ثم التجميع.

«Table '…cms_block' doesn't exist» عند تنفيذ استعلام Sansec: يستخدم التثبيت بادئة للجداول. اقرأ البادئة في إعدادات المتجر وأضفها إلى اسم الجدول.

«No such file or directory» مع أمر find الخاص بـpub/media: المجلد custom_options أو customer_address غير موجود في هذا المتجر. دوّن ذلك في الجدول؛ فهو ليس فشلًا ولا دليلًا على النظافة.

متجر يبقى في وضع الصيانة: تحقّق من عدم بقاء علامة صيانة وأعِد تشغيل bin/magento maintenance:disable بالمستخدم المالك للملفات.

بعد التنظيف: ما يجب تدويره

  • كلمات مرور المسؤولين — كل الحسابات في admin_user، بما فيها تلك التي تراها سليمة.
  • مفاتيح API والتكاملات — رموز التكاملات المعلَنة في لوحة الإدارة، ومفاتيح الخدمات الخارجية (الدفع، الشحن، ERP) المخزَّنة في الإعدادات.
  • بيانات اعتماد قاعدة البيانات — كلمة مرور جديدة، تُنقل إلى إعدادات المتجر.
  • مفتاح التشفير — يُغيَّر باتباع وثائق Adobe، بعد تقدير الأثر على البيانات المشفَّرة مسبقًا.
  • وصول SSH وSFTP — كلمات المرور، ومفاتيح SSH المصرّح بها، وحسابات النظام المجهولة.
  • وصول الاستضافة — لوحة التحكم والنسخ الاحتياطية، فهي أيضًا تتيح الوصول إلى الملفات.

التقرير المؤرَّخ الذي يُسلَّم لكل عميل

مرّر الجدول أفقيًا

العمودما تكتبه فيهالسبب
الإصدار قبل وبعدالأرقام التي قرأها Composer، مع التاريخ والساعةيُظهر أن التصحيح APSB26-73 مطبَّق
الحالة المجمَّدةمرجع اللقطة وتصدير قاعدة البياناتيتيح التراجع والفحص الجنائي الرقمي
الملفات تحت pub/mediaمسارات الملفات التي وُجدت وتواريخها، أو «لا شيء»فحص نشرته Sansec
accesson.phpالمسارات التي وُجدت، أو «لا شيء»باب خلفي أشارت إليه Sansec
cms_block وcms_pageالمعرّفات التي ظهرت والحكم بعد القراءةJavaScript محقون يُقدَّم للزوار
حسابات الإدارةالحسابات المجهولة المعطَّلة، أو «لا شيء»وصول تركه المهاجم
الصلاحيات المدوَّرةالأسرار التي غُيّرت وتاريخ تغييرهايغلق ما قد يكون المهاجم نسخه
ما لم يُفحصما لم تتمكن من فحصه، ولماذاتقرير صادق خير من «كل شيء على ما يرام»

ما تحتفظ به، والمصادر التي تُستشهد بها

حين يُكتشف أن متجرًا مخترَق، فالوكالة هي من يتصل بها العميل. حافظ على هذا الدور: أنت تمسك العلاقة والتشخيص والتقرير المؤرَّخ؛ والمنصة تمسك البنية التحتية، ووصول root إلى خادم VPS الذي يتيح تشغيل هذه الفحوص، واللقطة قبل التدخل. نحن لا نعدّل شيفرة متجر نيابةً عنك: تحديث Magento يبقى من مهام الوكالة. احتفظ أيضًا بنموذج الجدول: الثغرة القادمة التي تمسّ متجرًا ستتبع التسلسل نفسه، مع سطر إضافي في الجرد.

المصادر الأولية:
بطاقة NVD للثغرة CVE-2026-48356
نشرة Adobe ذات المرجع APSB26-73
تنبيه CISA بتاريخ 27 أكتوبر 2026
Sansec، موجة الهجوم الواسعة PolyShell
Sansec، محمّل JavaScript في cms_block

مجموعة متاجر، وجرد واحد

في مجموعة من متاجر العملاء، التكلفة الحقيقية هي غياب الجرد. في صفحة الوكالات، اطّلع على كيفية جمع محفظة العملاء والبنى التحتية وحالتها في مكان واحد: أنت تحتفظ بالعلاقة مع العميل، ونحن نتولى البنية التحتية.

مقالات ذات صلة

ماجنتو 2.4.6 بلا دعم: الترقية إلى 2.4.9 بانقطاع محدود
الأمان والمراقبة9 دقائق للقراءة

ماجنتو 2.4.6 بلا دعم: الترقية إلى 2.4.9 بانقطاع محدود

انتهى الدعم القياسي لماجنتو 2.4.6. مواعيد أدوبي، ومتطلبات خادم 2.4.9، وإجراء ترقية بواسطة Composer يُجرَّب أولًا في بيئة ما قبل الإنتاج.

قراءة المقال ←
كيفية تثبيت Magento على VPS
الاستضافة الذاتية3 دقائق للقراءة

كيفية تثبيت Magento على VPS

ثبّت Magento على VPS من ServOrbit: كتالوج معقّد، حزمة Docker، HTTPS ورابط إلى الوثائق الرسمية لـ Adobe Commerce.

قراءة المقال ←
اللقطة مقابل النسخ الاحتياطي للـVPS: الفرق والاستعادة
الأمان والمراقبة9 دقائق للقراءة

اللقطة مقابل النسخ الاحتياطي للـVPS: الفرق والاستعادة

لقطة أم نسخة احتياطية للـVPS: ما تحميه كل منهما وما لا تحميه، وكيف تتم الاستعادة، وقاعدة قرار تطبقها على الخوادم الافتراضية لعملائك.

قراءة المقال ←
تدقيق أمان VPS شهري للعميل: قائمة في 45 دقيقة
الأمان والمراقبة10 دقائق للقراءة

تدقيق أمان VPS شهري للعميل: قائمة في 45 دقيقة

سبعة فحوصات شهرية لخادم VPS العميل: التحديثات والنواة وحسابات SSH والمنافذ والشهادات والنسخ الاحتياطية والسجلات، مع تقرير مؤرخ.

قراءة المقال ←
Bricksforge CVE-2026-85097: التحديث وتدقيق مواقع العملاء
الأمان والمراقبة10 دقائق للقراءة

Bricksforge CVE-2026-85097: التحديث وتدقيق مواقع العملاء

الإصدار 3.1.8.10 من Bricksforge يصلح CVE-2026-85097، رفع ملفات بلا مصادقة مستغَل فعليًا. جرد wp-cli، ملفات PHP المزروعة، السجلات، الأسرار الواجب تغييرها.

قراءة المقال ←
Drupal Commerce CVE-2026-118539: التحديث وتدقيق الطلبات
الأمان والمراقبة10 دقائق للقراءة

Drupal Commerce CVE-2026-118539: التحديث وتدقيق الطلبات

ثغرة في Commerce Core مستغَلة، نشرة SA-CONTRIB-2026-254: حدّد الإصدارات المتأثرة، انتقل إلى 3.3.13 أو 8.x-2.41، ثم دقّق الطلبات.

قراءة المقال ←

بحاجة إلى مساعدة؟

تصفّح مركز المساعدة والأسئلة الشائعة، أو تواصل مع فريقنا — معاودة اتصال أو WhatsApp أو بريد إلكتروني. الدعم بـالعربية والفرنسية والإنجليزية.

راسلنا على WhatsAppيُفتح في علامة تبويب جديدة