« Pas d’exploitation connue » ne veut pas dire « pas urgent ». Adobe est explicite : appliquez ce correctif dès que possible, faute de quoi votre boutique reste vulnérable et Adobe aura des moyens limités pour vous aider à corriger ensuite. Cet article explique ce que contient ce patch, et surtout comment l’appliquer correctement — car en septembre 2026, ce n’est pas une simple case à cocher.

Ce que corrige APSB26-138

Le bulletin corrige des vulnérabilités dont l’exploitation réussie pourrait mener à de l’exécution de code arbitraire, de l’élévation de privilèges et du contournement de fonctionnalités de sécurité. Adobe classe cette mise à jour en priorité standard (pas de faille en cours d’exploitation), mais insiste sur une application rapide. Sont concernées toutes les lignes de version supportées, chacune « et antérieures » :

Pourquoi ce n’est pas un simple « clic pour installer »

Depuis qu’Adobe a adopté un rythme de correctifs mensuels sous forme de patches isolés, l’application demande de la méthode. Trois règles structurent tout le reste, et une erreur sur l’une d’elles fait échouer l’installation ou laisse la boutique vulnérable sans que rien ne l’indique.

L’ordre d’application, concrètement

Prenons l’exemple d’une boutique en Community Edition 2.4.6-p15, le cas le plus fréquent. Adobe détaille la séquence exacte : les patches de chaque mois s’appliquent l’un après l’autre, et si vous avez plusieurs composants (CE, Enterprise, B2B), chacun a son propre fichier à appliquer dans le bon ordre.

Comment vérifier que la boutique est bien protégée

Comme un correctif mensuel peut contenir plusieurs fichiers non cumulatifs, il faut vérifier l’état réel après application. Adobe fournit désormais un outil dédié, le Commerce Version Tool (CVT), qui indique quels patches sont installés, lesquels manquent, et surtout le statut de protection par CVE (PROTECTED / VULNERABLE / UNKNOWN).

Deux pièges à connaître : sur une boutique Adobe Commerce on Cloud, ne pas appliquer le patch isolé si le correctif a déjà été posé par le mécanisme cloud-patches — cela provoque un échec d’installation. Et Adobe recommande fortement, dans le cadre de la remédiation liée à StyleSmuggler, de faire tourner vos clés de chiffrement et les identifiants associés — un point qu’on ne pense pas toujours à traiter et qui va au-delà du simple patch.

Vous n’êtes pas sûr de savoir le faire ? C’est exactement notre métier

Soyons directs : cette procédure — être au bon niveau de patch, empiler les correctifs dans le bon ordre par composant, ne pas oublier le hotfix StyleSmuggler en amont, vérifier le résultat, faire tourner les clés — n’a rien d’évident quand ce n’est pas votre quotidien. Une erreur d’ordre, un patch oublié, et vous croyez votre boutique protégée alors qu’elle ne l’est pas. C’est précisément le genre d’opération qu’on réalise régulièrement sur les boutiques Magento que nous accompagnons : en environnement de test d’abord, puis en production, sans interruption de service inutile, avec vérification finale à l’appui.

FAQ

Si aucune faille n’est exploitée, pourquoi se presser ?

Parce que la fenêtre se referme vite. L’expérience des mois précédents — dont StyleSmuggler, exploitée moins de 24 h après sa divulgation — montre que les attaquants analysent les correctifs dès leur publication pour en déduire les failles. « Aucune exploitation connue aujourd’hui » peut devenir « exploitation active » en quelques jours. Adobe précise d’ailleurs qu’au-delà d’un certain délai, ses moyens pour vous aider à corriger deviennent limités.

Le patch mensuel suffit-il, ou dois-je aussi appliquer le hotfix StyleSmuggler ?

Les deux sont nécessaires. Le hotfix APSB26-146 pour CVE-2026-75650 n’est pas inclus dans le patch mensuel de septembre. Il doit être appliqué séparément et en premier, car cette faille-là est activement exploitée. Le mensuel APSB26-138 vient ensuite.

Pourquoi ces patches ne sont-ils pas livrés en paquets Composer ?

C’est un choix délibéré d’Adobe. Les correctifs de ce type sont fournis uniquement sous forme de fichiers de patch isolés, sans paquet Composer, pour offrir une application rapide et légère des correctifs critiques sans passer par un cycle de mise à jour Composer complet — plus long et susceptible d’entraîner des résolutions de dépendances supplémentaires.

L’article APSB26-138 : le patch de sécurité Magento de septembre, à appliquer sans délai est apparu en premier sur eBusiness360.

Faille critique en cours d’exploitation — à traiter immédiatement

Cette faille est activement exploitée depuis le 4 septembre 2026. Contrairement aux bulletins précédents, les correctifs de juillet et août ne protègent pas : des boutiques entièrement à jour ont été compromises. Si vous gérez une boutique Magento, appliquez le hotfix Adobe et vérifiez l’absence de porte dérobée sans attendre.

Le 7 septembre 2026, Adobe a publié en urgence, hors de son cycle mensuel habituel, le bulletin APSB26-146 pour corriger une faille classée au niveau de gravité maximal : CVE-2026-75650, score CVSS de 10.0, surnommée StyleSmuggler par la société de sécurité néerlandaise Sansec qui l’a découverte (sources : Adobe Security Bulletin APSB26-146 ; Sansec, « StyleSmuggler 0-day »). C’est le pire scénario possible pour une boutique en ligne : exécution de code à distance, sans aucune authentification, déjà exploitée en conditions réelles avant même que le correctif n’existe.

Pourquoi cette faille est différente des précédentes

Les bulletins de juillet (APSB26-73) et août (APSB26-92) que nous avons couverts ici étaient déjà sérieux. StyleSmuggler est d’une autre nature, pour une raison qui doit retenir l’attention de tout marchand Magento : être à jour de tous les patches ne suffit pas à s’en protéger.

La première victime confirmée tournait sur Magento 2.4.6-p15 avec les correctifs de juillet et août 2026 entièrement appliqués — sa propre commande security:patch-status indiquait un état sain au moment de la compromission (source : Sansec). Autrement dit, une boutique qui avait fait tout ce qu’Adobe recommandait jusqu’alors a quand même été piratée. Sansec a reproduit la chaîne d’attaque complète, sans authentification, sur des installations propres de Magento Open Source 2.4.7, 2.4.8 et 2.4.9 — la faille n’est donc pas liée à une version obsolète particulière.

Comment fonctionne l’attaque

StyleSmuggler détourne le système de templates de Magento lui-même. D’après l’analyse technique de Sansec, l’attaque se déroule en deux temps.

Point important signalé par Sansec : déplacer les sessions vers Redis ou la base de données ne bloque pas l’attaque. Un marchand a rapporté une première tentative échouée contre le stockage de session, suivie huit secondes plus tard d’une seconde tentative réussie via un fichier uploadé par les options personnalisées de Magento — le même opérateur passant simplement d’une méthode à l’autre.

Une porte dérobée qui survit au correctif

C’est l’autre raison de ne pas se contenter d’appliquer le patch. Les attaquants déposent une porte dérobée persistante — plusieurs sources rapportent un backdoor écrit en Rust, auto-actualisé, capable de se déguiser en processus système Linux et d’échapper aux scanners commerciaux (sources : The Hacker News, techtimes.com). Cette porte dérobée survit à l’application du correctif : patcher referme la porte d’entrée, mais ne supprime pas ce qui a déjà été installé si la boutique était déjà compromise.

Un détail illustre la vitesse des attaquants : selon la société néerlandaise Disrex, un serveur Magento a été compromis 50 minutes seulement après la première exploitation confirmée de StyleSmuggler, le 4 septembre à 22h20 UTC.

Quelles versions sont concernées

Toutes. Le bulletin Adobe liste l’ensemble des lignes supportées, chacune « et antérieures », jusqu’au niveau de patch d’août 2026 inclus.

Ce qu’il faut faire, dans l’ordre

Ne pas confondre avec le bulletin mensuel du 8 septembre

Attention à une source de confusion : Adobe a publié deux choses coup sur coup. Le hotfix d’urgence APSB26-146 (7 septembre) pour StyleSmuggler, décrit ici, et le bulletin mensuel régulier APSB26-138 (8 septembre), qui corrige d’autres vulnérabilités sans lien et pour lesquelles Adobe indique n’avoir aucune preuve d’exploitation. Les deux sont à appliquer, mais c’est bien APSB26-146 qui relève de l’urgence absolue.

FAQ

Ma boutique était à jour de juillet et août. Suis-je protégé ?

Non. C’est la particularité de cette faille : la première victime confirmée était entièrement à jour, avec un état de patch sain. Le hotfix APSB26-146 est nécessaire en plus des correctifs précédents. Et si votre boutique a pu être exposée entre le 4 et le 7 septembre, il faut vérifier qu’elle n’a pas déjà été compromise.

Appliquer le patch supprime-t-il une éventuelle infection ?

Non. Le patch referme la faille mais ne retire pas une porte dérobée déjà installée. Si votre boutique a été compromise avant l’application du correctif, le code malveillant peut persister. Un audit de compromission est indispensable en complément du patch, pas en option.

Un pare-feu applicatif suffit-il en attendant ?

Un WAF spécialisé peut bloquer les variantes connues de l’attaque, et Sansec indique que son pare-feu Shield bloque celles observées à ce jour. Mais la surface d’attaque est large et les opérateurs changent leurs charges plusieurs fois par jour — un WAF est une mesure de mitigation utile, pas un substitut au correctif officiel, qui reste indispensable.

L’article StyleSmuggler (CVE-2026-75650) : la faille Magento 10.0 qui frappe même les boutiques à jour est apparu en premier sur eBusiness360.

Mise à jour du 25 août 2026 — la faille est désormais activement exploitée

Contrairement à ce qui était indiqué au moment de la publication de ce bulletin, la faille CVE-2026-71362 est attaquée en conditions réelles depuis le 12 août, soit un jour après la sortie du correctif. La société de sécurité Sansec bloque activement des tentatives d’exploitation via son pare-feu, et l’hébergeur Hypernode a déployé des blocages d’urgence sur l’ensemble de ses serveurs Magento (sources : Sansec, BleepingComputer, SecurityWeek). Point critique : le seuil de vulnérabilité est le niveau de patch de juillet — avoir appliqué APSB26-73 le mois dernier ne protège donc pas. Malgré la classification priorité 2 d’Adobe (patch sous 30 jours), l’exploitation active justifie d’appliquer le correctif sous 72 heures.

Le 11 août 2026, Adobe a publié APSB26-92, le patch de sécurité mensuel qui succède à celui de juillet traité ici même. Sept vulnérabilités sont corrigées, dont cinq classées critiques (source : Adobe Security Bulletin APSB26-92). Ce bulletin tombe le même jour qu’un événement de calendrier important : la fin officielle du support de Magento 2.4.6.

Au moment de la publication de ce bulletin, Adobe indiquait n’avoir aucune preuve d’exploitation en environnement réel. Cette situation a changé en moins de 24 heures (voir l’encadré de mise à jour ci-dessus) — un rappel brutal de la vitesse à laquelle cette fenêtre se referme une fois un bulletin rendu public.

La faille qui mérite le plus d’attention

Un développeur britannique spécialisé Magento, qui a analysé le contenu technique du patch, décrit la correction la plus notable de ce lot comme un problème de prise de contrôle de compte client : le contrôleur de modification de compte peuplait l’objet client à partir des données de formulaire de session sans liste blanche de champs autorisés (source : analyse technique de Sam James, développeur Magento UK, blog personnel). Cette description correspond au profil de la faille la plus critique du bulletin officiel — autorisation incorrecte, sans authentification requise. Je note que cette attribution précise au fichier concerné vient de cette analyse indépendante et n’est pas confirmée mot pour mot dans le texte du bulletin Adobe lui-même, qui reste plus général dans sa description publique.

Les 7 vulnérabilités corrigées

Fait notable : contrairement à juillet, ce bulletin ne touche pas Adobe Commerce Events — seulement Adobe Commerce, Adobe Commerce B2B et Magento Open Source.

Un changement de méthode chez Adobe à surveiller

Le bulletin introduit une précision de méthode qui aura un impact sur la lecture des futurs bulletins : depuis le 11 août 2026, Adobe peut désormais regrouper sous un seul identifiant CVE plusieurs vulnérabilités découvertes en interne, si elles partagent la même sévérité et la même catégorie CWE, lorsque le correctif est systémique (source : note officielle du bulletin APSB26-92). Concrètement : le nombre de CVE affiché dans un bulletin ne représente plus nécessairement le nombre exact de failles distinctes corrigées — certains bulletins futurs pourraient sembler plus légers qu’ils ne le sont réellement.

Attention si vous avez appliqué le patch de juillet via composer-patches

Point technique à vérifier avant d’appliquer ce nouveau patch : selon l’analyse de Sam James, le patch d’août corrige aussi un bug du composant vaimo/composer-patches qui pouvait annuler silencieusement des patches déjà appliqués, ainsi qu’un souci de configuration nginx.conf.sample qui avait disparu du patch de juillet. Si votre process de patch mensuel repose sur ce composant, vérifiez que le correctif de juillet (APSB26-73) est toujours réellement actif avant d’empiler celui d’août par-dessus — un patch silencieusement annulé laisserait votre boutique exposée sans que rien ne le signale.

La fin de support de Magento 2.4.6

Ce bulletin tombe le jour même de la fin officielle de support de Magento 2.4.6, annoncée depuis plusieurs mois. Fait à vérifier avant de tirer une conclusion hâtive : la table des versions concernées par APSB26-92 inclut encore des correctifs 2.4.6-2026-aug pour Magento Open Source. Il est possible que ce soit le tout dernier patch de sécurité que recevra cette ligne de version — mais je n’ai pas de confirmation explicite d’Adobe sur ce point précis, donc à vérifier directement sur la page officielle de fin de vie avant de considérer 2.4.6 comme définitivement sans filet de sécurité.

Ce qui est certain : toute boutique encore sur cette ligne de version doit désormais traiter la montée vers 2.4.7 ou 2.4.8 comme une priorité, pas comme un chantier à planifier « un de ces jours ».

Ce qu’il faut faire

FAQ

Combien de failles corrige réellement ce bulletin ?

Le bulletin officiel Adobe liste 7 CVE distincts. Attention toutefois à la nouvelle politique de regroupement introduite ce même jour : certaines vulnérabilités internes de même sévérité et catégorie peuvent désormais être fusionnées sous un identifiant unique, ce qui peut minimiser le nombre affiché par rapport au nombre réel de problèmes corrigés dans le code.

Dois-je m’inquiéter si mon site est encore en 2.4.6 ?

Oui, dans le sens où le support officiel de cette ligne s’est arrêté le 11 août 2026. Ce bulletin d’août semble encore la couvrir, mais rien ne garantit que les prochains le feront. La priorité doit désormais être la migration vers 2.4.7 ou 2.4.8, pas uniquement l’application du dernier patch disponible.

Le patch de juillet et celui d’août sont-ils cumulatifs ?

Oui, les patches isolés mensuels s’appliquent en s’accumulant sur la dernière version patchée de votre ligne. Il faut toutefois être à jour du patch précédent avant d’appliquer le suivant — Adobe précise explicitement que les correctifs isolés d’un mois sont testés en supposant que tous les patches mensuels antérieurs de l’année ont déjà été appliqués.

L’article APSB26-92 : le patch d’août sur Magento, et la fin de 2.4.6 le même jour est apparu en premier sur eBusiness360.

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.