SessionReaper (APSB25-88) : la faille Magento qui détourne vos sessions

Le 9 septembre 2025, Adobe publiait discrètement le bulletin de sécurité APSB25-88, classé en priorité 2 — traduction officielle : “patchez sous 30 jours, pas d’urgence immédiate”. Six semaines plus tard, 250 boutiques Magento étaient compromises en 48 heures.

Au 1er novembre 2025, 81 % de tous les sites Magento avaient été ciblés et entre 16 et 18 % portaient un backdoor actif. La faille, baptisée SessionReaper par Sansec, est l’une des plus sophistiquées observées sur Magento : elle combine un upload de fichier non authentifié avec une vulnérabilité de désérialisation pour détourner le gestionnaire de sessions PHP et obtenir une exécution de code complète.

Ce que fait SessionReaper

Contrairement à PolyShell — où l’upload seul suffisait à compromettre le serveur — SessionReaper nécessite deux étapes. C’est ce qui l’a rendu difficile à détecter initialement.

Phase 1 — Upload du payload malveillant

L’attaquant commence par uploader un fichier via l’endpoint public de gestion des adresses clients :

POST /customer/address_file/upload

Aucune authentification n’est requise. Le fichier uploadé contient un objet PHP sérialisé avec un script malveillant embarqué. Il atterrit dans pub/media/customer_address/.

À ce stade, le fichier est inerte : il est stocké sur le serveur, mais rien ne l’exécute encore.

Phase 2 — Désérialisation et redirection des sessions

C’est ici que réside la véritable sophistication de l’attaque. La faille se trouve dans la classe Magento\Framework\Webapi\ServiceInputProcessor, méthode getConstructorData(). Cette méthode désérialise récursivement des objets JSON imbriqués reçus via l’API REST sans valider que les types cibles sont restreints aux interfaces Magento.

L’attaquant envoie une requête REST avec un payload JSON profondément imbriqué ciblant la classe Magento\Framework\Session\Config. En injectant un paramètre savePath malveillant, il redirige le gestionnaire de sessions PHP vers le répertoire pub/media/customer_address/ — là où son fichier malveillant attend.

Phase 3 — Exécution de code

PHP charge le fichier de session depuis le répertoire redirigé, le désérialise, et déclenche l’exécution du code embarqué.

Condition critique : le RCE complet n’est possible que si les sessions sont stockées en fichiers (configuration par défaut de Magento). Si votre boutique utilise Redis comme gestionnaire de sessions, le fichier uploadé ne peut pas être exécuté via ce vecteur — mais le détournement de session client reste possible.

Les types de payloads observés dans les campagnes actives incluent des scripts d’exécution de commandes à distance, des backdoors protégés par mot de passe hashé, et des payloads obfusqués pour échapper aux scanners basiques. Des connexions sortantes vers des domaines de commande et contrôle ont également été détectées : sagecrafft.com, worcksbot.com.

Versions affectées

Toutes les versions jusqu’aux correctifs suivants sont vulnérables :

Comment savoir si vous avez été attaqué

1. Scanner le répertoire d’upload

Tout fichier non-image dans pub/media/customer_address/ est suspect :

find pub/media/customer_address/ -type f \
  ! -name '*.jpg' ! -name '*.jpeg' \
  ! -name '*.png' ! -name '*.gif'

2. Détecter les backdoors déposés

Cherchez des fichiers PHP aux noms génériques dans pub/ :

find pub/ -name "static.php" \
  -o -name "sysapi.php" \
  -o -name "bootstrap.php" 2>/dev/null

3. Vérifier les connexions vers des domaines C&C connus

grep -r "sagecrafft\.com\|worcksbot\.com" pub/ app/ 2>/dev/null

4. Analyser les logs d’accès

Recherchez des requêtes POST vers l’endpoint d’upload depuis des IP inconnues, suivies de requêtes REST avec un JSON contenant le paramètre savePath :

POST /customer/address_file/upload
POST /rest/V1/...  { "savePath": "pub/media/customer_address/..." }

Une rafale de ces requêtes dans un intervalle court est un indicateur d’exploitation active.

5. Test rapide de vulnérabilité

Envoyez un payload REST malformé avec des objets imbriqués vers votre instance :

• Réponse HTTP 500 → instance non patchée
• Réponse HTTP 400 → instance patchée

Comment patcher

Option A — Hotfix officiel Adobe (priorité absolue)

Adobe a publié le hotfix VULN-32437-2-4-X-patch (remplacez X par votre version mineure). Il est disponible sur Adobe Experience League depuis le bulletin APSB25-88.

Ce patch corrige la validation des types dans ServiceInputProcessor::getConstructorData() en s’assurant que les objets désérialisés sont restreints aux interfaces Magento autorisées.

Note : si le module Custom Attributes Serializable est installé sur votre instance, mettez-le à jour vers la version 0.4.0 minimum avant ou après l’application du patch.

Option B — Migrer les sessions vers Redis

Cette mesure élimine la condition d’exécution du RCE : même si un fichier malveillant est uploadé, le gestionnaire de sessions ne peut plus être redirigé vers un répertoire web.

# app/etc/env.php
'session' => [
    'save' => 'redis',
    'redis' => [
        'host' => '127.0.0.1',
        'port' => '6379',
        'database' => '2',
    ]
],

La migration Redis est recommandée indépendamment de cette faille — elle améliore les performances et la résilience des sessions sur les architectures multi-serveurs.

Option C — Blocage au niveau du serveur web

En attendant l’application du patch, bloquez l’accès au répertoire d’upload.

Nginx :

location ~* ^/pub/media/customer_address/ {
    return 403;
}

Apache / .htaccess :

<Directory /var/www/html/pub/media/customer_address>
    php_flag engine off
    Deny from all
</Directory>

Cette mesure empêche l’exécution des fichiers déjà uploadés et bloque les nouveaux dépôts via le navigateur, mais ne corrige pas la vulnérabilité de désérialisation dans l’API REST.

Si vous êtes compromis : procédure de nettoyage

1. Passer en mode maintenance — isolez la boutique le temps de l’investigation
2. Vider pub/media/customer_address/ — sauvegardez le contenu pour analyse forensique avant suppression
3. Supprimer les backdoors — cherchez et supprimez tous les fichiers PHP inconnus dans pub/
4. Supprimer les comptes admin non reconnus — vérifiez la liste des comptes administrateurs
5. Forcer le reset des mots de passe clients — un détournement de session peut avoir exposé des comptes
6. Appliquer le patch — avant toute remise en ligne
7. Surveiller les logs de paiement — vérifiez l’absence de transactions frauduleuses sur la période de compromission

Pourquoi cette faille change la donne

SessionReaper illustre un problème structurel dans la gestion des patchs Magento : le bulletin APSB25-88 était disponible six semaines avant le début de l’exploitation de masse. La majorité des boutiques compromises auraient pu être protégées.

Classer une faille critique en “priorité 2” parce qu’elle n’est pas encore exploitée publiquement est un pari risqué. Les acteurs malveillants analysent les bulletins Adobe dès leur publication pour reverse-engineer les corrections et construire leurs exploits.

La différence entre une boutique compromise et une boutique protégée se résume souvent à une seule chose : un processus de veille et d’application des patchs qui ne dépend pas du calendrier Adobe.

Vous souhaitez qu’un expert vérifie votre installation et applique le patch APSB25-88 ? Contactez-nous — nous intervenons sous 48h.