Les logiciels malveillants diffusés via des fichiers SVG inondent les boîtes mail. Voici ce qui permet réellement de les bloquer.

• Les fichiers SVG ne sont pas des données d'image binaires comme les fichiers JPEG ou PNG. Ils sont basés sur le langage XML et peuvent contenir des scripts exécutables que le navigateur exécute immédiatement à leur ouverture.
• Selon le rapport 2026 de Hoxhunt sur les tendances en matière de hameçonnage, le nombre de pièces jointes SVG malveillantes a été multiplié par cinquante en 2025 par rapport à 2024 et ce type de pièce jointe occupe désormais la troisième place parmi les pièces jointes malveillantes les plus courantes au niveau mondial.
• Chaque charge utile SVG est personnalisée en fonction de l'adresse e-mail du destinataire. La destination de la redirection est fractionnée, chiffrée à l'aide de plusieurs variables, et n'est assemblée qu'au moment de l'exécution ; elle apparaît donc comme un charabia incompréhensible pour tout scanner qui analyserait le fichier de manière statique.
• La détection traditionnelle repose sur la reconnaissance de schémas d'attaque connus, que ce soit par le biais de signatures ou d'heuristiques.
• La technologie Deep CDR™ supprime le contenu actif des fichiers image pris en charge avant qu'ils n'atteignent l'utilisateur, que la menace ait déjà été détectée ou non. Aucune signature ni aucune exposition préalable n'est requise.

Le 2 juin 2026, Xavier Mertens, analyste au SANS Internet Storm Center, a publié une analyse d’une nouvelle campagne de hameçonnage qui arrivait dans sa boîte de réception depuis plusieurs jours. Chaque e-mail contenait en pièce jointe un fichier SVG, un type de fichier que la plupart des gens associent généralement à des icônes, des illustrations et des graphiques Web. Rien ne laissait présager une menace.

Un double-clic sur ce fichier ouvrait le navigateur par défaut, le script intégré s'exécutait en arrière-plan, puis le navigateur redirigeait vers une page destinée à récupérer les identifiants, personnalisée en fonction de l'adresse e-mail du destinataire. Rien ne laissait présager qu'il s'était passé quoi que ce soit, jusqu'à ce qu'il soit trop tard.

Cette attaque n'a nécessité aucun logiciel particulier, aucun document contenant des macros, ni aucune autorisation de la part de l'utilisateur, si ce n'est le simple réflexe d'ouvrir une pièce jointe. Tout le mécanisme reposait sur une idée reçue : celle selon laquelle un fichier image présente intrinsèquement peu de risques.

Cette hypothèse est compréhensible. Les fichiers JPEG et PNG sont représentés sous forme de données de pixels, ce qui limite leur surface d'attaque au niveau du fichier.

Le format SVG est différent. Il est écrit en XML (Extensible Markup Language), le même langage de balisage qui sert de base aux pages Web. Cela signifie qu'un fichier SVG peut contenir des balises de script, des éléments d'ancrage et d'autres contenus Web interactifs qu'un navigateur traite de la même manière que n'importe quelle page Web.

C'est cette faille que les pirates exploitent. Les fichiers utilisés dans la campagne analysée par Mertens ne contenaient absolument aucun contenu graphique. Il s'agissait uniquement de code : du JavaScript obfusqué encapsulé dans une coque SVG aussi fine que possible, le conteneur SVG n'ayant qu'une seule raison d'être : atteindre le navigateur de la victime tout en étant classé comme pièce jointe image par la passerelle de messagerie.

Le format SVG en tant que vecteur d'attaque n'est pas nouveau, mais son utilisation à grande échelle s'est accélérée. Des chercheurs ont recensé la présence de pièces jointes SVG malveillantes dans des e-mails depuis environ 2017, ce qui soulève une question évidente : qu'est-ce qui a changé pour que ce problème mérite d'être abordé aujourd'hui ?

Deux choses ont changé, principalement.

Tout d’abord, l’ampleur du phénomène a considérablement augmenté. Le nombre de pièces jointes SVG malveillantes a été multiplié par cinquante en 2025 par rapport à 2024 (rapport Hoxhunt 2026 sur les tendances en matière de hameçonnage), et lors d’une seule campagne menée en février 2026, Microsoft a recensé l’envoi de 1,2 million de messages de hameçonnage basés sur le format SVG à plus de 53 000 organisations réparties dans 23 pays. La technique n'est pas nouvelle, mais son adoption à grande échelle l'est.

D'autre part, le paysage de la sécurité a évolué d'une manière qui a rendu le format SVG plus attractif. Microsoft a désactivé les macros Office par défaut en 2022, les menaces liées aux fichiers PDF ont fait l'objet d'une surveillance accrue, et le format SVG a fait son apparition sur de nombreuses passerelles avec un historique de réputation relativement vierge, ce qui signifie que les attaquants, cherchant la voie de la moindre résistance, ont rapidement trouvé le format SVG très attractif.

La technique de contournement décrite par Mertens est subtile. Le code JavaScript intégré au fichier SVG est déclaré avec le type « application/ecmascript » plutôt que le type standard « text/javascript »; bien que les navigateurs traitent ces deux types de manière identique et exécutent les scripts désignés par l’un ou l’autre, c’est précisément dans cette divergence entre ce que les navigateurs acceptent et ce que les outils de sécurité analysent que réside la faille d’attaque.

Lorsque la RFC 9239 a mis à jour la norme en 2022, les éditeurs de solutions de sécurité s'y sont conformés et ont supprimé « application/ecmascript » de leurs listes d'inspection. Les navigateurs, conçus pour assurer la rétrocompatibilité, ont toutefois continué à l'exécuter. La norme indiquait que ce type était obsolète. Les navigateurs n'ont jamais reçu cette information.

Il en résulte une faille persistante. « application/ecmascript » n’est pas un identifiant nouveau ou obscur, mais son histoire remonte au début des années 2000. Ce ne sont pas les attaquants qui l’ont inventé. Ils ont remarqué que la transition décrite dans la RFC avait créé une asymétrie entre les navigateurs conservant l’ancien comportement et les scanners appliquant la nouvelle norme, et que cette asymétrie ne se résout pas d’elle-même. Toute passerelle qui n’a pas explicitement réintégré les alias MIME ECMAScript obsolètes dans ses règles d’inspection reste exposée, non pas parce qu’elle est obsolète, mais parce qu’elle a mis en œuvre une norme que les navigateurs n’ont pas suivie.

L'adresse du destinataire est encodée en Base64 et intégrée directement dans le contenu SVG, ce qui signifie que chaque pièce jointe de cette campagne génère une URL de hameçonnage unique et personnalisée, destinée à un destinataire spécifique, pour un coût quasi nul.

Ce niveau de personnalisation est important car il permet de contourner les algorithmes de détection qui repèrent les campagnes génériques : il n'y a en effet ni contenu répété, ni URL de redirection commune, ni schéma récurrent chez les destinataires, contrairement au hameçonnage de masse.

La destination de la redirection est encodée en Base64, puis chiffrée à l'aide d'une clé générée à l'exécution à partir de deux variables distinctes. Il ne s'agit pas d'un système de chiffrement sophistiqué, mais c'est précisément le processus de génération de la clé qui rend cette méthode efficace contre les scanners automatisés.

Les systèmes de détection qui tentent de contourner l’obfuscation doivent connaître à la fois l’algorithme et la clé, et cette dernière n’existe pas sous la forme d’une valeur unique dans le fichier. Elle est répartie entre deux variables et n’est concaténée qu’au moment de l’exécution, ce qui signifie qu’un scanner ne peut pas reconstituer l’URL de destination sans avoir d’abord décomposé l’assembly d’exécution, ce qui nécessite d’exécuter le script plutôt que de se contenter de le lire. L’analyse statique ne fournit que peu d’informations exploitables, et la charge utile ne devient lisible que dans un environnement de navigateur en temps réel, c’est-à-dire précisément là où la plupart des inspections au niveau de la passerelle n’ont pas lieu.

Chacune de ces techniques de contournement pourrait à elle seule être détectée, mais combinées entre elles — un format de pièce jointe classé comme image, un type MIME obsolète, une charge utile chiffrée et un domaine de destination situé sur un domaine de premier niveau présentant un historique d'abus limité —, elles augmentent considérablement la probabilité d'atteindre la boîte de réception.

La sécurité des e-mails basée sur la détection repose sur une question fondamentale : ce fichier correspond-il à une menace connue ou identifiable ? Son efficacité dépend des connaissances préalables, qu'il s'agisse de signatures ou de modèles comportementaux.

Cette dépendance constitue la faille structurelle mise en évidence par cette campagne. L’accumulation de techniques de dissimulation fait qu’il y a véritablement peu d’éléments à détecter pour un scanner, et la classification du fichier au format SVG implique qu’il ne fasse pas l’objet d’un examen aussi minutieux qu’un document Office ou un fichier exécutable. Si votre passerelle classe les fichiers SVG comme des formats d’image et applique donc une inspection moins approfondie, cette campagne n’a probablement pas été détectée au niveau de la passerelle. Il s’agit ici d’un cas où l’attaque opère en dehors du champ d’évaluation des systèmes de détection.

Il ne s'agit pas ici de dire que la détection ne fonctionne pas. Elle fonctionne bien contre les menaces connues, et aucune architecture de sécurité des e-mails ne peut être efficace sans elle. La question est de savoir ce qu'il advient des menaces totalement inédites que les systèmes de détection n'ont jamais rencontrées auparavant.

Une approche axée sur la prévention met en place une mesure complémentaire à la détection : ce fichier contient-il encore du contenu actif ?

La technologie Deep CDR™ ne cherche pas à déterminer si un fichier est malveillant. Elle se contente plutôt de décomposer le fichier, d’en supprimer tous les éléments potentiellement malveillants ou non conformes à la politique en vigueur, puis de fournir une version nettoyée et utilisable. Dans le cas d’un fichier SVG contenant un script actif, cela signifie que l’utilisateur reçoit un fichier qui s’affiche comme prévu s’il contient du contenu graphique légitime, mais sans le script permettant l’attaque.

Cette approche a été validée par le tout premier score de 100 % obtenu lors du test de neutralisation et de reconstruction de contenu réalisé par SE Labs, qui a reconnu la technologie Deep CDR™ comme la toute première solution CDR à atteindre un score de 100 % en matière de protection et de précision.

La désinfection ne suffit pas à elle seule à neutraliser toutes les menaces. Les charges utiles furtives, c'est-à-dire les fichiers conçus pour paraître inoffensifs lors d'une analyse statique et qui ne s'activent qu'au moment de l'exécution, nécessitent une inspection comportementale allant au-delà de ce que couvre la désinfection. MetaDefender comble cette lacune grâce à une analyse dynamique en sandbox, qui met en évidence les comportements malveillants par émulation et fournit un verdict unique et fiable. Avec un taux de détection des failles « zero-day » de 99,9 %, Aether traite les risques résiduels que la sanitisation et les analyses multiples ne sont pas conçues pour contrer à elles seules.

Le SVG en est un exemple actuel, mais ce ne sera pas le dernier. Ce phénomène dépasse le cadre du SVG : tout format de fichier qui semble légitime tout en dissimulant du contenu exécutable est susceptible d'être traité de la même manière.

Les pièces jointes au format HTML permettent de faire passer clandestinement des charges utiles au-delà des passerelles de sécurité. Les codes QR intégrés dans des fichiers PDF redirigent vers des pages destinées à récupérer des identifiants. Les charges utiles stéganographiques se cachent dans les métadonnées des images. Dans chaque cas, le fichier correspond exactement à ce qu’il prétend être d’un point de vue structurel, tout en contenant des éléments que le contrôle de classification de surface n’a jamais été conçu pour détecter.

La leçon à retenir n'est pas qu'un format particulier soit dangereux. C'est plutôt que l'argument « ce fichier semble inoffensif » ne constitue plus un fondement valable pour les décisions de transmission. Lorsqu'un fichier passe tous les contrôles de détection, faut-il le transmettre automatiquement, ou faut-il le nettoyer dans tous les cas ?

Les cyberattaquants partent chaque jour du principe que la détection constitue la dernière ligne de défense. Pour nous, celle-ci s’inscrit dans une approche multicouche qui combine différentes technologies afin d’optimiser la sécurité périmétrique de nos clients. MetaDefender™ Email Security applique cette logique à deux modèles de déploiement :

• Email Gateway Security MetaDefender™ se déploie sur site sous forme de logiciel au niveau SMTP/MX. La technologie Deep CDR™, compatible avec plus de 200 types de fichiers, supprime le contenu actif de chaque pièce jointe et analyse de manière récursive les archives imbriquées pour une désinfection en profondeur ; la technologie Metascan™ Multiscanning, qui s'appuie sur plus de 30 moteurs antivirus, effectue la détection en parallèle ; l’IA prédictive Alin rend un verdict en quelques millisecondes quant à la présence ou non de menaces dans la pièce jointe sans exécution, la technologie de sandbox MetaDefender couvre les charges utiles évasives nécessitant une analyse comportementale plus approfondie, et la technologie Proactive DLP™ empêche les fuites à la source sur plus de 125 types de fichiers.
• MetaDefender™ Cloud Email Security applique la même approche axée sur la prévention au sein des environnements Microsoft 365, sans modification des enregistrements MX, sans matériel supplémentaire et sans interruption du flux de messagerie. La technologie Deep CDR™, MetaDefender , Multiscanning Metascan Multiscanning jusqu'à 17 moteurs antivirus et l'IA prédictive Alin inspectent et assainissent chaque pièce jointe des e-mails entrants et sortants, y compris les fichiers chiffrés, avant qu'ils n'atteignent l'utilisateur.