Magento SessionReaper + PolyShell : playbook 48h Tunisie

D'après Sansec, 56,7 % des boutiques Magento exposées à la campagne PolyShell de mars 2026 étaient déjà compromises au moment du scan — moins de 48 heures après la divulgation publique. Si vous opérez un Magento Open Source 2.4.x en Tunisie, le compteur tourne depuis des semaines.

Cet article n'est pas un article d'analyse. C'est un playbook 48 heures — quoi faire dans les quatre premières heures (contenir), entre la quatrième et la vingt-quatrième heure (investiguer), puis entre la vingt-quatrième et la quarante-huitième (remédier et durcir). À la fin, vous saurez exactement ce que Noqta livre dans une mission d'urgence 48 h et comment l'enclencher.

Si votre boutique tourne sous Magento Open Source 2.4.6, 2.4.7 ou 2.4.8 non patchée, lisez d'abord la section "Êtes-vous concerné ?" puis revenez en haut.

1. SessionReaper et PolyShell : ce qui se passe vraiment

Deux vulnérabilités distinctes, exploitées en chaîne contre la même surface — l'API REST de Magento.

SessionReaper — CVE-2025-54236 (CVSS 9,1). Vulnérabilité critique de bypass d'authentification dans l'API REST de Magento Open Source et Adobe Commerce. Adobe a publié le correctif via le bulletin de sécurité APSB25-88 en septembre 2025. La faille permet à un attaquant non authentifié de prendre le contrôle de sessions admin et, par chaînage, d'installer un backend persistant. Les branches Magento 2.4.4 à 2.4.7 sont vulnérables sans patch ; la 2.4.8 doit être en version -p2 ou supérieure.

PolyShell — campagne mars 2026. Documentée par The Hacker News et confirmée par Sansec, cette campagne weaponise SessionReaper en chaînant le bypass d'authentification avec un upload de webshell polyglotte. Le fichier déposé se présente comme une image légitime mais s'exécute comme du PHP côté serveur dès qu'il est appelé. Sansec a observé que plus de 200 boutiques ont été compromises dans les 24 premières heures, et que la moitié des installations vulnérables scannées portaient déjà la signature PolyShell à 48 h. Pour le contexte plus large, voir notre article sur la chaîne d'attaque 25 minutes contre Magento 2.2 — les TTPs sont similaires, l'API REST en plus.

Les indicateurs de compromission publics convergent vers trois artefacts :

Fichiers PHP suspects sous /pub/media/ ou /pub/static/, datés après la mi-mars 2026.
Comptes admin nouvellement créés (table admin_user) sans trace dans les logs métier.
Trafic sortant inhabituel vers des domaines de skimming JavaScript chargés dans les pages de checkout.

2. Êtes-vous concerné ? Auto-diagnostic en cinq points

À faire maintenant, sans accès serveur. Cinq minutes au total.

Version Magento exposée. Tapez https://votre-boutique.tld/magento_version dans un navigateur. Si la réponse contient 2.4.4, 2.4.5, 2.4.6, 2.4.7, ou 2.4.8-p0 / 2.4.8-p1, vous êtes potentiellement vulnérable à SessionReaper. Une 404 ne signifie pas que vous êtes safe — votre prestataire a peut-être juste désactivé l'endpoint.
API REST publique. Tapez https://votre-boutique.tld/rest/V1/store/storeViews. Si vous obtenez du JSON, l'API REST est accessible — surface d'attaque exposée.
Chemin admin par défaut. Tapez https://votre-boutique.tld/admin. Si la page de connexion s'affiche, c'est que le backend frontname n'a pas été randomisé — facteur aggravant.
Activité de support et hosting. Demandez à votre intégrateur ou hébergeur : "À quelle date avez-vous appliqué le patch APSB25-88 ?" S'il hésite, prend plus de 24 h à répondre, ou répond "on est protégés par le WAF", vous avez votre réponse.
Date du dernier composer update. Si elle remonte à avant septembre 2025, le patch SessionReaper n'a pas pu être appliqué.

Si deux indicateurs ou plus sont positifs, traitez la situation comme un incident probable jusqu'à preuve du contraire. Passez directement à la section 3.

3. Le playbook 48 heures

Heure 0 → Heure 4 — Contenir

L'objectif n'est pas de réparer. C'est de stopper l'hémorragie sans détruire les preuves forensiques. Trois actions, dans cet ordre.

0:00 — Snapshot avant tout. Demandez à votre hébergeur une image disque complète (LVM snapshot, snapshot DigitalOcean / OVH / AWS EBS) et un dump mémoire si possible. Ne redémarrez pas le serveur — la RAM contient des processus malveillants utiles à l'analyse. Sans snapshot préalable, toute analyse forensique ultérieure perd en valeur juridique.

0:30 — Couper la surface exposée. À ce stade, deux options selon votre tolérance au downtime.

Option A (recommandée si vous avez détecté un IOC) : mettre la boutique en mode maintenance côté WAF ou load-balancer, en ne laissant passer que votre IP bureau. Trafic public coupé, le serveur reste vivant pour l'analyse.
Option B (si le revenu interdit le downtime) : bloquer uniquement /rest/V1/, /admin, et /pub/media/*.php au niveau du WAF / nginx, et activer la journalisation verbeuse. La boutique reste accessible, l'attaque active perd ses points d'appui.

# nginx — bloquer l'exécution PHP dans /pub/media
location ~ ^/pub/media/.*\.php$ { deny all; return 403; }
# Bloquer l'API REST publique le temps de l'investigation
location ~ ^/rest/V1/ { allow VOTRE.IP.BUREAU; deny all; }

2:00 — Rotation des secrets critiques. Sans attendre la fin de l'investigation, rotez :

Mots de passe admin Magento (tous les comptes — pas seulement le vôtre).
Clés API REST et Integration tokens (table oauth_token).
Identifiants base de données (app/etc/env.php).
Clés de passerelle de paiement (Stripe, ClicToPay, Paymee, Konnect).
Identifiants SMTP et clés Mailgun / SendGrid.

Si un attaquant a un webshell, il a déjà lu env.php. Considérez tout secret stocké sur le serveur comme exfiltré.

Heure 4 → Heure 24 — Investiguer

Maintenant que l'hémorragie est arrêtée, vous cherchez l'étendue et la profondeur de la compromission.

4:00 — Triage des webshells. Recherche des fichiers PHP modifiés ou créés depuis le 1er mars 2026 dans les répertoires qui ne devraient pas en contenir.

# Webshells dans pub/media (cible favorite de PolyShell)
find /var/www/html/pub/media/ /var/www/html/pub/static/ \
  -name "*.php" -mtime -90 -ls
 
# Signatures de webshell connues
grep -rE "eval\(base64_decode|gzinflate\(base64_decode|str_rot13\(|assert\(\\\$_" \
  /var/www/html/pub/ /var/www/html/var/ 2>/dev/null

8:00 — Audit des comptes admin. Toute création récente non documentée = compromission confirmée.

SELECT user_id, username, email, created, modified, is_active, logdate
FROM admin_user
ORDER BY created DESC;

Croisez avec votre RH / vos prestataires. Un compte créé entre minuit et 6 h, depuis une IP non-tunisienne, sans ticket associé : c'est l'attaquant.

12:00 — Audit du checkout (Magecart). C'est ici que la facture devient lourde. L'attaquant a-t-il injecté un skimmer côté client ? Trois endroits à vérifier :

Table core_config_data, lignes contenant <script ou des URLs externes inhabituelles.
Templates checkout (app/design/frontend/.../checkout/) modifiés récemment.
Extensions tierces ajoutées récemment ou modifiées (vendor/ et app/code/).

Inspectez la page de paiement avec les DevTools : tous les domaines depuis lesquels du JavaScript est chargé doivent être identifiables (votre domaine, votre CDN, votre PSP, votre outil d'analytics). Tout autre domaine = à investiguer.

18:00 — Audit base de données. Au minimum, exportez et figez : customer_entity, sales_order, quote, quote_address, customer_address_entity. Si vous devez notifier l'INPDP (loi tunisienne 2004-63) ou des autorités étrangères (PDPL saoudienne, GDPR pour clients UE), il vous faut connaître précisément ce qui a fuité.

24:00 — Synthèse intermédiaire. À ce point, vous devez pouvoir répondre à : (a) y a-t-il un webshell ? (b) y a-t-il des comptes admin compromis ? (c) y a-t-il un skimmer en production ? (d) la base a-t-elle été dumpée ? Si oui à (a), (b) ou (c), la phase de remédiation passe en mode "rebuild propre", pas en mode "nettoyer en place".

Heure 24 → Heure 48 — Remédier et durcir

24:00 — Patcher SessionReaper. La seule réponse durable est l'application du correctif officiel Adobe APSB25-88 et la mise à jour vers Magento Open Source 2.4.8-p4 (publiée le 10 mars 2026) ou supérieure.

composer require magento/product-community-edition=2.4.8-p4 --no-update
composer update --with-dependencies
bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento setup:static-content:deploy -f
bin/magento cache:flush

À tester sur staging avant production. Compter une demi-journée si la dette de modules est faible, une journée pleine sinon.

30:00 — Si compromission confirmée : rebuild. Un webshell connu peut en cacher d'autres. La doctrine forensique sérieuse est : on ne nettoie pas un serveur compromis, on le reconstruit. Concrètement :

Provisionner un serveur neuf (autre droplet, autre VM).
Réinstaller Magento 2.4.8-p4 from scratch.
Réimporter uniquement les données métier depuis un backup pré-compromission (catalogue, commandes, clients), pas les fichiers du serveur compromis.
Réinstaller les extensions depuis leur source originale (composer.json), pas depuis vendor/ du serveur compromis.
Bascule DNS quand le nouveau serveur est validé.

36:00 — Durcissement. Une fois la production saine, fermer les portes qui ont servi.

Randomiser le backend frontname (bin/magento setup:config:set --backend-frontname=admin_XXXXX).
Activer la 2FA obligatoire sur tous les comptes admin (bin/magento module:enable Magento_TwoFactorAuth).
Restreindre l'API REST à des IPs whitelistées si vous n'avez pas d'usage public.
Bloquer l'exécution PHP dans /pub/media/ au niveau du serveur web (règle nginx ci-dessus).
Installer un WAF avec règles dédiées Magento (ModSecurity OWASP CRS + règles Sansec, ou Cloudflare WAF avec ruleset Magento).
Activer la journalisation centralisée (Wazuh, ELK, Loki) hors du serveur de production.

42:00 — Notifications légales et clients. Si des données personnelles ont fuité :

INPDP (loi 2004-63) : sous 72 h, déclaration de l'incident.
Clients tunisiens : notification par e-mail si les données sensibles ont fuité.
Clients UE / Royaume-Uni / Suisse : notification GDPR sous 72 h.
Clients saoudiens : notification SDAIA sous 72 h (PDPL).
PSP et émetteur de cartes : si des données de carte ont pu transiter par un skimmer, notification immédiate au PSP — eux préviendront les schemes (Visa, Mastercard).

48:00 — Rapport post-incident. Document interne signé : timeline, vecteur initial, étendue, données impactées, mesures prises, plan de prévention. C'est ce document qui protège l'entreprise en cas de plainte ultérieure et qui sert de base au prochain audit annuel.

4. Ce que Noqta livre dans la mission d'urgence 48 h

Pas de fluff. Voici les livrables concrets de notre engagement 48 h :

Heure 0 : ouverture d'un canal Slack / WhatsApp dédié, snapshot serveur supervisé, mise en mode maintenance contrôlée si nécessaire.
Heure 4 : rapport de triage initial (webshells, comptes suspects, IOCs PolyShell trouvés ou non).
Heure 24 : rapport d'investigation (étendue de la compromission, données potentiellement exfiltrées, recommandation "patch en place" vs "rebuild").
Heure 36 : exécution du plan de remédiation choisi — soit application du patch APSB25-88 sur le serveur existant, soit provisioning d'un serveur neuf avec migration de données saines.
Heure 48 : rapport final post-incident, runbook de durcissement appliqué, fichier de notifications légales pré-rédigées pour l'INPDP et les autres autorités concernées.

Tarification indicative : mission forfaitaire 48 h, équipe deux ingénieurs senior, livrée sous 24 h de l'engagement . Nous ne proposons pas de "rétrofit gratuit" sur les boutiques déjà skimmées : la doctrine est rebuild propre.

5. Checklist de prévention post-incident

Une fois le feu éteint, voici la checklist à pousser dans votre contrat de maintenance (existant ou nouveau) pour éviter le prochain incident.

Cette checklist n'est pas une option, c'est le minimum réglementaire implicite pour opérer une plateforme transactionnelle en 2026.

6. FAQ

Combien de boutiques tunisiennes sont concernées ? Les statistiques Sansec ne sont pas géolocalisées publiquement. Mais Magento Open Source domine le mid-market e-commerce tunisien (apparel, électronique, multi-marques), et le taux de patching observé chez nos clients post-audit est très inférieur à la moyenne mondiale. Considérez que la prévalence locale est au moins équivalente aux 56,7 % observés globalement.

Notre boutique est sous Adobe Commerce Cloud — sommes-nous protégés ? Adobe Commerce Cloud applique les patches automatiquement sur les instances managées si vous êtes sur une version supportée. Vérifiez avec Adobe Customer Care que votre instance est en 2.4.8-p4 minimum. Si vous êtes sur une branche EOL, l'auto-patch ne s'applique pas.

Le WAF de notre hébergeur suffit ? Un WAF générique (mod_security par défaut) ne détecte pas un upload PolyShell — le fichier passe pour une image. Il faut un WAF Magento-aware avec règles spécifiques. C'est précisément ce que la statistique Sansec révèle : la majorité des boutiques compromises avaient "un WAF".

On a appliqué le patch en septembre, on est tranquilles ? SessionReaper est patché par APSB25-88, oui. Mais PolyShell exploitait des installations encore vulnérables en mars 2026 — c'est-à-dire potentiellement la vôtre si le patch n'avait pas été appliqué dans la fenêtre Sept-Mars. Vérifiez l'historique des composer update et auditez pub/media/ pour exclure une compromission rétroactive.

Et si nous découvrons un webshell après cet article ? N'éteignez pas le serveur (perte mémoire). Coupez l'accès public, faites une image disque complète, engagez immédiatement un prestataire en réponse à incident, et notifiez l'INPDP dans les 72 h si des données personnelles ont pu fuiter. Notre canal d'urgence est ouvert 24/7 pour les missions 48 h.

Contactez Noqta pour un audit d'urgence 48 h

Si l'auto-diagnostic de la section 2 a fait remonter deux indicateurs ou plus, ou si vous avez le moindre doute sur une compromission active, n'attendez pas le prochain audit annuel.

Notre équipe peut ouvrir une mission d'urgence 48 h dans la journée. Vous repartez avec un serveur propre, un rapport post-incident exploitable juridiquement, et un plan de durcissement qui empêche la récidive.

Contactez Noqta pour un audit d'urgence 48 h

Sources publiques citées : Adobe APSB25-88 (CVE-2025-54236), The Hacker News (Magento PolyShell mars 2026), Sansec Research (statistiques de compromission), NIST NVD. Pour le contexte stack EOL voir aussi notre article migration Magento 2.2 vers 2.4 : coût réel en Tunisie et la chaîne d'attaque 25 minutes.