2026-10-22 · 6 min de lecture

Sécurité Magento 2 : corriger, détecter et bloquer ClickFix, PolyShell et CosmicSting

Les boutiques Magento 2 et Adobe Commerce sont une cible permanente des campagnes d'exploitation automatisées. Chaque nouvelle version 2.4.x embarque une série de correctifs de sécurité, et les attaquants analysent ces correctifs en quelques jours pour construire des exploits fonctionnels contre les boutiques qui n'ont pas encore été mises à jour. Cet article décrit les menaces les plus marquantes observées ces derniers mois, la manière de reconnaître les traces qu'elles laissent sur un serveur et les étapes concrètes pour les éliminer et prévenir la prochaine intrusion.

Pourquoi les installations 2.4.x non corrigées sont la cible principale

Adobe publie à intervalle régulier des bulletins de sécurité pour Magento Open Source et Adobe Commerce, et chaque bulletin énumère les vulnérabilités corrigées dans la version concernée. Le délai entre la publication d'un correctif et l'apparition d'une preuve de concept publique se compte désormais en heures et non en semaines. Une boutique qui reste sur un niveau de correctif ancien exécute de fait des vulnérabilités déjà publiées et armées. La première contre-mesure est donc toujours la même : mettre le cœur à jour vers la dernière version sécurisée et appliquer tous les correctifs et correctifs urgents publiés pour votre branche.

ClickFix : la fausse case de vérification humaine

ClickFix est une technique d'ingénierie sociale qui n'exploite pas Magento directement, mais abuse de la confiance que les visiteurs accordent à une interface familière. Sur une boutique compromise, la page de commande ou la page d'atterrissage est modifiée pour afficher un faux widget Cloudflare « vérifiez que vous êtes humain ». Le visiteur coche la case exactement comme sur une page de vérification légitime, et un script est copié silencieusement dans le presse-papiers. Rien de dangereux ne se produit à cet instant, et la page peut même sembler continuer normalement.

Le danger survient à la deuxième étape. La fausse page demande au visiteur d'ouvrir une fenêtre de terminal sous macOS ou Windows et d'y coller le contenu copié pour terminer la vérification. S'il obtempère, la commande collée télécharge et exécute une charge de second niveau sur la machine du client. La règle pour les utilisateurs est simple et absolue : ne jamais coller dans un terminal une commande provenant d'une page web. La règle pour les administrateurs est de trouver le script injecté, de le supprimer et de fermer le point d'entrée qui a permis la modification.

Compromission côté serveur : PolyShell, CosmicSting et env.php

Plusieurs familles de vulnérabilités dominent les rapports d'incident Magento 2. PolyShell exploite les téléversements de fichiers sans restriction via l'API REST pour déposer des fichiers polyglottes qui sont à la fois des images valides et du PHP valide. CosmicSting vise le moteur de templates et peut conduire à une exécution de code à distance sans authentification. StyleSmuggler et BlockStrap suivent des schémas similaires d'injection dans les templates et de contournement de filtres. Dans les cas les plus graves, l'attaquant lit env.php, en extrait les clés cryptographiques et forge des jetons d'administrateur valides, ce qui lui assure un accès persistant au back-office même après la fermeture du chemin vulnérable.

Principales familles de menaces Magento 2 et leur impact
VulnérabilitéVecteur d'attaqueImpact
PolyShellTéléversement sans restriction via l'API RESTFichier PHP polyglotte stocké dans pub/media
CosmicStingInjection dans le moteur de templatesExécution de code à distance sans authentification
StyleSmugglerContournement de templates et de filtresInjection de code et fuite de données
BlockStrapDéfaut de validation des entréesAccès au back-office et vol de clés
ClickFixScript injecté côté frontendLogiciel malveillant exécuté sur les machines des visiteurs
← Faites défiler vers la droite pour en voir plus →

Rechercher du code obfusqué dans app, vendor et cache

Le code malveillant est rarement évident. Les attaquants le dissimulent dans des templates .phtml standard, dans les modules du cœur et dans les fichiers générés des répertoires cache et var. Une recherche textuelle des mots-clés habituels ne renvoie souvent rien, car la charge est assemblée à l'exécution à partir de chaînes base64 ou de plusieurs fragments concaténés. Un cas récent concernait un fichier .phtml infecté dans le dossier vendor, modifié très légèrement, avec la chaîne malveillante répartie sur plusieurs variables.

Comparez votre installation à une copie propre de la même version. Utilisez un contrôle d'intégrité des fichiers, examinez les dates de modification et inspectez tout fichier qui diffère du paquet officiel. Lorsque vous trouvez un fichier infecté, ne vous contentez pas de supprimer la charge : restaurez la version d'origine depuis l'archive officielle, puis mettez à jour ou bloquez le chemin vulnérable qui a permis l'écriture.

pub/media ne doit jamais contenir de PHP

Le répertoire media est destiné à stocker des images, des PDF et d'autres ressources statiques. Aucune raison légitime ne justifie la présence d'un fichier .php, .php7, .phtml ou .phar sous pub/media. Les attaquants en déposent pourtant en permanence, et les cachettes favorites sont pub/media/custom_options/ et pub/media/custom_options/quote/, où sont enregistrés les fichiers d'options téléversés. Analysez ces répertoires de manière récursive, supprimez tout fichier exécutable et vérifiez que la configuration des téléversements rejette les extensions inattendues.

Bloquer en amont avec Cloudflare, Nginx et Apache

Nettoyer le serveur ne suffit pas si le point d'entrée reste ouvert. Bloquez les chemins vulnérables avant que la requête n'atteigne Magento. Dans Cloudflare, vous pouvez créer une règle WAF qui refuse les requêtes vers /pub/media/custom_options/ et les répertoires similaires, ou qui soumet à un défi toute requête tentant d'atteindre un fichier PHP dans le chemin media. Sur le serveur d'origine, ajoutez des règles équivalentes dans Nginx ou Apache afin que la protection reste active lorsque le trafic contourne le CDN.

Gardez à l'esprit qu'une règle en amont n'arrête que les requêtes que vous connaissez déjà. Associez-la au correctif, à la surveillance des fichiers et à un audit périodique du code.

Liste de contrôle de remédiation

Ordre des opérations pour une reprise sûre
ÉtapeAction
1Mettre Magento à jour vers la dernière version 2.4.x et appliquer tous les correctifs de sécurité
2Analyser app, vendor, cache et var à la recherche de fichiers obfusqués ou modifiés
3Restaurer les fichiers d'origine depuis le paquet officiel
4Supprimer tout fichier PHP, php7, phtml et phar de pub/media
5Renouveler les clés de chiffrement et invalider les sessions administrateur existantes
6Bloquer les chemins vulnérables dans Cloudflare, Nginx ou Apache
7Supprimer et régénérer tous les caches et le code compilé
← Faites défiler vers la droite pour en voir plus →

Conclusion

La sécurité de Magento est un cycle, pas une tâche unique. Corrigez rapidement, vérifiez l'intégrité de vos fichiers, gardez le code exécutable hors du répertoire media et bloquez les chemins dont vous n'avez pas besoin. Si vous soupçonnez une injection ClickFix, avertissez immédiatement vos clients : le moyen le plus rapide de limiter les dégâts est de veiller à ce que personne ne colle quoi que ce soit dans un terminal.

Travaillons ensemble

Vous avez besoin de plus d'informations, d'aide pour votre projet ou pour développer une idée?

Qu'il s'agisse d'une question simple, d'un doute rapide ou d'une discussion de 5 minutes, envoyez-moi un message—cela ne coûte rien et je suis toujours prêt à vous aider. J'aime comprendre un problème, être créatif dans les solutions et me concentrer sur des idées simples, fiables et faciles à réaliser rapidement.

Me contacter →

Changer de sujet

Choisissez un sujet spécialisé à explorer: