Adobe indique qu’aucun exploit actif n’est connu à ce jour. C’est une bonne nouvelle, mais une fenêtre qui se referme vite : dès qu’un bulletin de ce type est publié, les scanners automatisés commencent à sonder les boutiques non patchées en quelques jours.

Les deux failles à traiter en priorité absolue

La CVE-2026-48356 est la plus préoccupante des deux, car elle ne nécessite aucune authentification — n’importe quel visiteur non identifié peut potentiellement l’exploiter. La CVE-2026-48358, bien que plus haute historiquement dans certaines discussions communautaires (attention, plusieurs sources tierces circulant en ligne annoncent à tort un score de 10.0 pour cette faille — le tableau officiel Adobe indique 9.1), nécessite des privilèges administrateur pour être déclenchée, ce qui réduit sa surface d’exploitation directe, sans la rendre négligeable.

Le tableau complet des 13 vulnérabilités

Un changement de rythme à noter : le calendrier passe au bimensuel

Ce bulletin marque une évolution du calendrier de sécurité d’Adobe. Depuis janvier 2026, les correctifs isolés étaient publiés mensuellement ; certaines analyses indiquent qu’APSB26-73 s’inscrit dans un rythme désormais bimensuel, avec des publications les deuxième et quatrième mardis de chaque mois. Pour la maintenance de votre boutique, ça signifie un suivi plus fréquent à mettre en place — la fenêtre entre deux bulletins se resserre, et le nombre d’occasions de rester à jour augmente.

Comment appliquer le correctif

Adobe a publié un patch isolé pour chaque ligne de version supportée, permettant d’appliquer le correctif sans passer par une montée de version complète.

Ce qu’il faut faire, dans l’ordre

FAQ

Dois-je faire une mise à niveau complète ou juste appliquer le patch isolé ?

Le patch isolé suffit pour corriger les vulnérabilités de ce bulletin sans passer par une montée de version complète — c’est justement l’intérêt de ce format, pensé pour limiter les risques de régression liés à un upgrade complet. Une montée de version reste pertinente séparément si votre ligne actuelle approche de sa fin de support (2.4.6, par exemple, dont le support s’arrête le 11 août 2026).

Ma boutique est-elle vulnérable si je n’ai pas de module B2B ?

Les deux failles critiques les plus préoccupantes (upload de fichier et webhooks) touchent le cœur d’Adobe Commerce et Magento Open Source, indépendamment du module B2B. Seules deux vulnérabilités du lot sont spécifiquement liées au B2B. Toute boutique reste concernée par la majorité des correctifs.

Que se passe-t-il si je ne patche pas immédiatement ?

Adobe confirme qu’aucun exploit actif n’est connu à la date de publication du bulletin. Mais l’expérience de bulletins précédents (CosmicSting, SessionReaper) montre que la fenêtre entre la publication du correctif et le début des tentatives d’exploitation automatisée se compte généralement en jours, pas en semaines. Le risque augmente chaque jour de retard.

L’article APSB26-73 : 13 failles corrigées sur Magento, dont deux critiques — ce qu’il faut faire est apparu en premier sur eBusiness360.

Voici ce que cette clé fait réellement, comment Magento l’utilise, et comment la gérer sans mettre votre boutique en péril.

Ce que la clé de chiffrement protège concrètement

Cette clé sert à chiffrer et déchiffrer les données sensibles que Magento a besoin de relire en clair par la suite — contrairement aux mots de passe, qui eux sont hachés à sens unique et jamais déchiffrés. La documentation officielle Adobe est claire sur ce point : un algorithme ChaCha20-Poly1305 avec une clé de 256 bits est utilisé pour chiffrer toutes les données nécessitant un déchiffrement, tandis qu’un algorithme SHA-256 sert à hacher les données qui n’en ont pas besoin (source : Adobe Experience League, documentation « Encryption key »).

Cette distinction est importante et souvent confondue : la crypt-key n’a strictement rien à voir avec le stockage des mots de passe. Elle sert uniquement au chiffrement réversible — ce que l’application doit pouvoir relire plus tard pour renvoyer un token à un prestataire de paiement, ou réutiliser une clé API tierce.

Où elle vit, et pourquoi ce fichier ne doit jamais être versionné

La clé est générée aléatoirement à l’installation et stockée dans app/etc/env.php, sous la structure 'crypt' => ['key' => '...']. Ce même fichier contient aussi les identifiants de connexion à votre base de données, le nom de domaine de votre back-office et la configuration des cookies de session. Autrement dit : c’est probablement le fichier le plus sensible de toute votre installation Magento.

La règle absolue : ce fichier ne doit jamais être commité dans un dépôt Git. Il est exclu par défaut via .gitignore sur une installation Magento standard — mais des réécritures de .gitignore personnalisées finissent parfois par l’oublier, et un simple git add app/etc suffit à exposer l’intégralité de vos secrets dans l’historique du dépôt, de façon quasiment irréversible même après une suppression ultérieure.

Pourquoi cette clé est une cible de choix pour un attaquant

Ce n’est pas un risque théorique. La vulnérabilité CosmicSting (CVE-2024-34102, CVSS 9.8), l’une des failles Magento les plus exploitées de ces dernières années, illustrait précisément ce danger : une faille d’injection XML permettait à un attaquant non authentifié de lire des fichiers arbitraires sur le serveur — dont app/etc/env.php. Une fois la clé de chiffrement en main, l’attaquant pouvait forger des jetons d’authentification valides et obtenir un accès administrateur complet, sans jamais connaître le moindre mot de passe. Cette vulnérabilité a conduit à plus de 4 275 boutiques compromises.

C’est la raison pour laquelle, sur une boutique qui a pu être exposée à une faille de ce type, changer les mots de passe ne suffit jamais : il faut aussi faire tourner (rotation) la clé de chiffrement elle-même, sans quoi l’ancienne clé reste valide pour forger de nouveaux accès.

Changer la clé : ce qui a changé en 2.4.8

Point d’actualité important si vous gérez plusieurs boutiques Magento : la fonctionnalité de changement de clé de chiffrement depuis l’interface d’administration est désormais dépréciée et a été retirée en Magento 2.4.8. La documentation officielle Adobe est explicite sur ce point : depuis cette version, il faut obligatoirement utiliser la commande en ligne de commande pour changer la clé après une mise à niveau vers 2.4.8 (source : Adobe Experience League, documentation « Encryption key »).

Attention à une conséquence directe et souvent ignorée : la rotation de la clé de chiffrement invalide immédiatement toutes les sessions clients et administrateurs actives (à l’exception des utilisateurs d’intégration), qui devront se reconnecter (source : Adobe Experience League). Ce n’est pas un bug — c’est le comportement attendu, à anticiper en communiquant si besoin, ou en programmant l’opération à un horaire de faible trafic.

Le piège classique : restaurer une base sans la bonne clé

Une erreur fréquente, notamment lors d’un travail en environnement local ou de staging : copier une base de données de production sur une nouvelle installation Magento sans transférer aussi le fichier env.php d’origine. Résultat : les données chiffrées avec l’ancienne clé (tokens de paiement enregistrés, identifiants d’intégrations tierces, certains champs de configuration) deviennent totalement illisibles sur la nouvelle installation, puisque celle-ci a généré sa propre clé aléatoire à l’installation.

La règle à retenir : la clé de chiffrement doit toujours accompagner un export de base de données, exactement comme vous transféreriez un trousseau de clés avec la maison qu’il ouvre. Sans elle, les données chiffrées sont perdues — pas corrompues, perdues, puisque le chiffrement fort n’a par définition aucune porte dérobée.

FAQ

Puis-je simplement remplacer la valeur dans env.php à la main ?

Non, ce n’est pas la bonne méthode. Remplacer directement la valeur sans passer par la procédure officielle de changement de clé laisse toutes les données déjà chiffrées avec l’ancienne clé irrécupérables, puisque Magento tentera de les déchiffrer avec la nouvelle valeur. La procédure documentée par Adobe rechiffre les données existantes avec la nouvelle clé avant de finaliser le changement — c’est cette étape de rechiffrement qui rend l’opération sûre.

Que se passe-t-il si je perds définitivement la clé de chiffrement ?

Toutes les données chiffrées avec cette clé deviennent définitivement inaccessibles — un chiffrement fort par définition ne permet aucun contournement sans la clé. En pratique, cela signifie généralement que les clients devront ressaisir leurs informations de paiement, et que les intégrations avec des systèmes tiers devront être reconfigurées depuis l’interface d’administration. C’est une raison suffisante pour sauvegarder cette clé séparément, dans un gestionnaire de mots de passe sécurisé, en plus de vos sauvegardes habituelles.

À quelle fréquence faut-il changer cette clé ?

Adobe recommande de changer la clé de chiffrement régulièrement pour renforcer la sécurité, ainsi qu’à chaque fois qu’un risque de compromission est identifié (source : Adobe Experience League). En pratique : après un changement de personnel technique ayant eu accès au serveur, après toute suspicion de fuite du fichier env.php, et systématiquement après un incident de sécurité avéré sur la boutique.

L’article La clé de chiffrement Magento : ce qu’elle protège et comment la gérer est apparu en premier sur eBusiness360.

Voici le déroulement de cette intervention, de la détection à la remédiation complète, en moins de 4 heures.

Le contexte de l’intrusion

La boutique concernée tournait sur Magento 2.4.6 avec des mises à jour de sécurité partielles — le dernier patch de sécurité n’avait pas été appliqué depuis plusieurs mois. Le vecteur d’intrusion identifié a posteriori : la faille PolyShell, exploitée via l’upload de fichiers malveillants dans le dossier des options de commande personnalisées (pub/media/custom_options/quote/). Cette faille permettait à un attaquant de déposer un fichier PHP déguisé en fichier image et de l’exécuter directement via son URL.

Heure par heure — les 4 heures d’intervention

Le vecteur d’attaque — comprendre PolyShell

La faille exploitée ici est connue sous le nom de PolyShell. Elle tire son origine d’une validation insuffisante des fichiers uploadés via les options de commande personnalisées de type « File » dans Magento. Un attaquant pouvait déposer un fichier PHP dont l’extension était masquée ou dont le type MIME était falsifié. Magento stockait ce fichier dans un répertoire accessible publiquement sur le web, et l’attaquant pouvait ensuite l’exécuter directement via son URL — lui donnant un accès shell complet au serveur.

Cette vulnérabilité existait depuis les premières versions de Magento 2 et n’a reçu un correctif natif officiel qu’avec le bulletin APSB26-05 intégré dans les patches de sécurité de début 2026. Pendant toute cette période, les boutiques exposées pouvaient être compromises sans qu’aucune erreur visible ne se manifeste côté utilisateur.

Les trois indicateurs qui auraient permis une détection plus précoce

Ce qui a été mis en place pour éviter la récidive

Au-delà de la remédiation immédiate, plusieurs mesures structurelles ont été déployées pour réduire durablement la surface d’attaque :

Ce que ce cas illustre sur la sécurité Magento

Plusieurs enseignements ressortent de cette intervention, qu’on retrouve dans la quasi-totalité des cas de compromission Magento que nous traitons :

La compromission précède toujours le signalement de plusieurs semaines. Dans ce cas, le skimmer était actif depuis environ trois semaines avant que les premiers clients se manifestent. Pendant ce temps, des centaines de transactions avaient eu lieu avec le code malveillant actif.

Les patches de sécurité en retard sont le vecteur numéro un. La faille exploitée était connue, documentée, et un patch existait. Le délai d’application — plusieurs mois — a suffi aux attaquants pour exploiter la fenêtre d’exposition.

La remédiation ne se limite pas à supprimer les fichiers malveillants. Supprimer les webshells sans colmater la brèche d’origine ne sert à rien — l’attaquant peut re-déposer ses fichiers en quelques minutes. La séquence correcte est : isoler → analyser → corriger la vulnérabilité → nettoyer → surveiller.

FAQ

Comment savoir si ma boutique a été compromise de la même façon ?

La commande suivante permet de détecter la présence de fichiers PHP dans les répertoires publics de Magento :

find pub/media/ pub/static/ -name "*.php" -type f 2>/dev/null

Si cette commande retourne des résultats, c’est un signal d’alerte fort. Vérifiez également la liste des comptes administrateurs et l’ensemble des blocs CMS de votre page checkout pour détecter la présence de code JavaScript inattendu.

Mes clients dont les données ont été volées doivent-ils être prévenus ?

Oui — et c’est une obligation légale en France. Le RGPD impose de notifier la CNIL dans les 72 heures suivant la découverte d’une violation de données à caractère personnel, et d’informer les personnes concernées si la violation est susceptible d’engendrer un risque élevé pour leurs droits et libertés. Une compromission de données bancaires entre dans ce cadre. Consultez un professionnel juridique pour vous accompagner dans cette démarche.

Puis-je gérer ce type d’incident seul ?

La partie technique de la remédiation — suppression des webshells, nettoyage des blocs CMS, correction de la vulnérabilité — est faisable avec de bonnes compétences Magento et Linux. Ce qui est plus difficile à gérer seul : s’assurer qu’aucune backdoor ne subsiste, identifier avec certitude toute la durée d’exposition, et mettre en place les mesures structurelles pour éviter la récidive. Une deuxième paire d’yeux spécialisée sur un incident de ce type vaut toujours l’investissement.

L’article Intrusion sur une boutique Magento : retour d’expérience d’une remédiation en 4h est apparu en premier sur eBusiness360.

Ce n’est pas anodin. Ces faux comptes polluent votre base de données, faussent vos statistiques clients, consomment des ressources serveur — et dans certains cas, ouvrent la porte à des attaques bien plus sérieuses.

Pourquoi les bots créent-ils des faux comptes ?

La réponse dépend du type de bot en face. Il en existe plusieurs catégories, avec des intentions très différentes :

Les signes qui doivent vous alerter

Le spam de comptes ne se remarque pas toujours immédiatement. Voici les indicateurs concrets à surveiller dans votre admin Magento :

• Une vague soudaine de nouveaux comptes créés en quelques heures, souvent la nuit ou le week-end
• Des adresses email au format aléatoire : suites de lettres et chiffres sans logique, domaines jetables (mailinator.com, guerrillamail.com, etc.)
• Plusieurs inscriptions depuis la même adresse IP en très peu de temps
• Zéro activité après la création : aucune commande, aucune navigation, aucun retour
• Une augmentation des bounces email si vous envoyez des emails de confirmation ou de bienvenue

Les protections natives de Magento

Magento 2 intègre quelques mécanismes de base pour limiter ce type d’abus. Ils ne sont pas activés par défaut pour tous, et leur niveau de protection reste limité face à des bots sophistiqués — mais ils constituent un premier rempart à mettre en place absolument.

Activer le CAPTCHA natif Magento — où ça se passe

Dans votre admin Magento, rendez-vous dans Stores → Configuration → Customers → Customer Configuration → CAPTCHA. Activez-le et cochez au minimum le formulaire Create User. Ce n’est pas la protection la plus robuste, mais c’est la plus rapide à mettre en place sans aucun développement.

La confirmation email — simple et souvent sous-estimée

Obliger la confirmation par email avant d’activer un compte filtre naturellement les adresses jetables : le bot crée le compte, mais l’email de confirmation n’arrive jamais à destination, et le compte reste inactif. C’est dans Stores → Configuration → Customers → Customer Configuration → Require Emails Confirmation → Yes.

Attention toutefois : cette option peut légèrement freiner vos vraies inscriptions si vos clients ne pensent pas à vérifier leur boîte mail. À peser selon votre contexte.

Nettoyer les faux comptes existants

Si vous avez déjà des milliers de faux comptes dans votre base, les supprimer un par un n’est pas envisageable. La bonne approche est une requête SQL ciblée qui identifie les comptes sans aucune commande, créés sur une courte période, avec des emails au format suspect. C’est le type de nettoyage qu’un prestataire technique peut réaliser proprement, avec une sauvegarde préalable et une vérification avant suppression.

L’article Spam de comptes clients Magento 2 : détecter, bloquer, prévenir est apparu en premier sur eBusiness360.

Ce n’est pas une alerte théorique. Des centaines de boutiques françaises ont déjà été compromises via ce vecteur — webshells cachés, skimmers de cartes bancaires, comptes administrateurs créés à l’insu du marchand. Voici ce que vous devez savoir.

C’est quoi exactement, PolyShell ?

PolyShell est le nom donné à une vulnérabilité dans la gestion des options de fichiers personnalisées de Magento. Concrètement, Magento permet à vos clients de joindre des fichiers à leurs commandes — une gravure, un logo, un bon de commande. Le problème : le mécanisme qui reçoit ces fichiers ne vérifie pas correctement leur nature réelle.

Un attaquant peut envoyer un fichier qui se fait passer pour une image mais contient en réalité du code PHP malveillant. Une fois ce fichier déposé sur votre serveur, il suffit de l’appeler depuis un navigateur pour exécuter n’importe quelle commande sur votre hébergement. C’est ce qu’on appelle un webshell — une porte dérobée permanente sur votre site.

Comment savoir si votre boutique est touchée ?

C’est là que ça devient inquiétant : dans la majorité des cas, les marchands ne s’aperçoivent de rien. Les fichiers malveillants sont discrets, ne perturbent pas le fonctionnement du site, et peuvent rester actifs pendant des mois — parfois des années. Voici les signes qui doivent vous alerter :

• Des fichiers .php inattendus dans pub/media/ — ce dossier ne devrait contenir que des images et documents, jamais de code PHP
• Un ou plusieurs comptes administrateurs que vous ne reconnaissez pas dans Magento → Système → Tous les utilisateurs
• Des modifications inexpliquées dans vos blocs CMS — notamment les blocs affichés au checkout
• Des alertes Google Search Console signalant du contenu malveillant ou des pages inconnues
• Une consommation serveur anormale sans pic de trafic correspondant

Comment détecter les fichiers malveillants ?

Si vous avez un accès SSH à votre serveur, cette commande permet de repérer tous les fichiers PHP qui n’ont rien à faire dans le dossier media :

find pub/media/ -name "*.php" -type f

Si cette commande retourne des résultats, vous avez très probablement été compromis. Un résultat vide est rassurant — mais pas une garantie absolue, car certains webshells utilisent des extensions différentes (.phtml, .php3, .phar).

find pub/media/ -name "*.phtml" -o -name "*.php3" -o -name "*.phar" | xargs ls -la 2>/dev/null

Quelles versions sont concernées ?

Toutes les versions de Magento 2 jusqu’à la 2.4.8 incluse sont potentiellement exposées selon la configuration du serveur web. Adobe a intégré un correctif dans la version 2.4.9 (actuellement en beta), mais aucun patch isolé n’existe pour les versions en production. La protection passe donc par des mesures de mitigation côté serveur, pas par une simple mise à jour de Magento.

Les mesures de protection à mettre en place

En attendant un correctif officiel pour les versions en production, la parade la plus efficace est de bloquer l’exécution de PHP dans les dossiers publics qui ne devraient jamais contenir de code. Concrètement, cela se fait dans la configuration de votre serveur web (Apache ou Nginx).

Sur Apache, il faut s’assurer que le fichier .htaccess de pub/media/ contient bien des règles qui interdisent l’exécution de scripts PHP. Sur Nginx, c’est une directive location qui fait le travail. Si vous n’êtes pas à l’aise avec ces configurations, c’est exactement le type d’intervention qu’un prestataire Magento peut réaliser en moins d’une heure.

Autres mesures complémentaires recommandées :

• Auditer les comptes administrateurs : supprimez tout compte que vous ne reconnaissez pas
• Vérifier les blocs CMS sensibles : notamment ceux affichés en page de paiement
• Activer la surveillance des fichiers : certains outils comme Sansec alertent en temps réel sur toute modification suspecte
• Restreindre l’accès à l’admin par IP si possible — moins d’exposition, moins de risques

Et si votre boutique a déjà été compromise ?

Ne paniquez pas, mais n’attendez pas non plus. La priorité est de couper le mal à la racine : supprimer les fichiers malveillants, révoquer les accès frauduleux, et identifier la durée d’exposition pour évaluer si des données clients ont pu être volées. Si des données de cartes bancaires sont en jeu, une notification à la CNIL est obligatoire dans les 72 heures.

Une boutique nettoyée sans renforcement des protections sera recompromise en quelques jours. Le nettoyage et la sécurisation doivent aller de pair.

L’article PolyShell : la faille Magento silencieuse — détecter et se protéger est apparu en premier sur eBusiness360.