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. En langage Adobe : patchez sous 30 jours, rien d’urgent. Six semaines plus tard, 250 boutiques Magento étaient compromises en 48 heures.

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

Ce que fait SessionReaper

Contrairement à PolyShell, où l’upload seul suffisait à compromettre le serveur, SessionReaper demande deux étapes. C’est ce qui l’a rendu difficile à détecter au début.

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

La faille se trouve dans la classe Magento\Framework\Webapi\ServiceInputProcessor, méthode getConstructorData(). Cette méthode désérialise récursivement les objets JSON imbriqués reçus via l’API REST, sans vérifier que les types cibles sont bien 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 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, ce qui est la configuration Magento par défaut. Si votre boutique utilise Redis pour les sessions, le fichier uploadé ne peut pas être exécuté par 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 : le 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 vers Redis se justifie de toute façon, indépendamment de cette faille : elle améliore les performances et la résilience des sessions sur les architectures multi-serveurs.

Option C : bloquer 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 de supprimer.
3. Supprimer les backdoors. Cherchez et supprimez tous les fichiers PHP inconnus dans pub/.
4. Supprimer les comptes admin non reconnus. Reprenez la liste des administrateurs un par un.
5. Forcer le reset des mots de passe clients. Un détournement de session a pu exposer des comptes.
6. Appliquer le patch, avant toute remise en ligne.
7. Surveiller les logs de paiement. Cherchez des transactions frauduleuses sur la période de compromission.

Six semaines d’avance, perdues

SessionReaper révèle surtout un problème de calendrier : 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.

En pratique, les boutiques épargnées sont celles qui appliquent les patchs sur leur propre calendrier, sans attendre qu’Adobe requalifie la priorité.

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