Secu
La cyberattaque sur Notepad++ : 5 leçons à en tirer pour DSI et RSSI
Par Laurent Delattre, publié le 03 février 2026
Le mécanisme de mise à jour de Notepad++ a été entièrement sous le contrôle de cyberattaquants étatiques durant six mois. Un vrai cauchemar de cybersécurité et une piqure de rappel pour les DSI et RSSI alors que les attaques à la supply chain se diversifient et gagnent en ampleur.
Notepad++ est un des plus célèbres et anciens outils de l’univers open source. Né en 2003, cet éditeur de texte (et de code source) est l’un des utilitaires les plus populaires de l’univers Windows, très apprécié aussi bien par les développeurs que les administrateurs système. Au cours du second semestre 2025, l’infrastructure servant les mises à jour automatiques de Notepad++ a été compromise de façon à rediriger certains utilisateurs vers des serveurs malveillants, permettant la distribution d’exécutables « backdoorés » (autrement dit contenant des portes dérobées) à une sélection de cibles. Cette compromission, qui a duré plusieurs mois avant d’être détectée et corrigée, ne résultait pas d’une faille dans le code de Notepad++ lui‑même mais d’une compromission au niveau de l’hébergement et du mécanisme de mise à jour.
Tous les indices pointent vers une campagne d’espionnage ciblée, pilotée par un groupe de hackers chinois (Lotus Blossom) que l’on soupçonne d’être directement financé et contrôlé par l’état chinois. Les victimes identifiées jusqu’ici appartiennent principalement aux secteurs des télécommunications, des services financiers, de l’aviation et des infrastructures critiques en Asie de l’Est.
Mécanique technique de l’attaque
Le vecteur exploité combinait une faiblesse dans la vérification des mises à jour côté client et un contrôle illégitime de l’infrastructure d’hébergement. L’updater de Notepad++ interrogeait un fichier pour obtenir l’URL de téléchargement. Les attaquants ont découvert qu’en interceptant ou en redirigeant ce trafic, ils pouvaient forcer la mise à jour avec un binaire différent de celui officiel. D’autant que le système de mise à jour utilisait des contrôles de signature et des certificats qui n’étaient pas toujours robustes. La compromission de l’infrastructure hébergeant Notepad++ a servi de tremplin pour déposer une porte dérobée inédite, baptisée Chrysalis, via une exécution enchaînant notepad++.exe, GUP.exe puis un update.exe téléchargé depuis une IP externe malveillante.
Mesures correctives prises par l’editeur
Le projet Notepad++ a migré son site et son infrastructure vers un hébergeur aux pratiques de sécurité renforcées et a durci le processus de mise à jour côté client pour vérifier l’intégrité des binaires. Les réponses techniques incluent la correction des mécanismes d’authentification des mises à jour et la révocation des accès compromis chez le fournisseur. Au‑delà des correctifs immédiats, cet incident rappelle l’importance de la sécurité de la chaîne d’approvisionnement logicielle, de la surveillance des journaux d’accès chez les hébergeurs et de la nécessité pour les organisations de contrôler et de surveiller les processus de mise à jour automatisés.
Mesures correctives à prendre par les DSI
Pour les DSI et RSSI, la réponse immédiate est de s’assurer que les postes sont au moins en version Notepad++ 8.8.9 et que l’update n’accepte plus un installeur non vérifié, tout en retirant les éventuels anciens certificats racine Notepad++. Ensuite, il faut traiter Notepad++ comme n’importe quel autre composant tiers. Identifier les postes qui ont mis à jour pendant la fenêtre de risque, rechercher les indicateurs comportementaux autour de gup.exe et d’exécutables déposés dans le TEMP, et, en cas de doute, basculer sur une réinstallation contrôlée depuis une source officielle.
Reste que cette affaire remet au goût du jour l’une des grandes craintes de tous les acteurs de la cybersécurité : une compromission “infrastructure”, au niveau de l’hébergement et de la chaîne de distribution, d’un outil populaire capable de se mettre à jour plus ou moins automatiquement. C’est la démonstration, très opérationnelle, qu’un mécanisme de mise à jour reste l’un des meilleurs moyens d’entrer dans une organisation. Il bénéficie d’un a priori de confiance, s’exécute souvent avec des droits élevés, et traverse plus facilement les contrôles, notamment lorsque l’outil est vu comme un utilitaire anodin.
En outre, le scénario d’attaques n’avait pas ici vocation à toucher tout le monde, mais à rester discret le plus longtemps possible et à frapper juste, chez des organisations à forte valeur de renseignement.
Voici cinq leçons que les DSI et RSSI doivent retenir de cet incident :
#1 / Les « petits » logiciels sont aussi risqués que les Gros
Les SI privilégient souvent la surveillance et le contrôle de l’exposition de Windows, des suites bureautiques, des navigateurs, des sécurités EDR et des clients VPN. En revanche les applications internes développées par les métiers et les petits utilitaires de confort des équipes IT (devs, exploitation, data Teams) passent souvent sous les radars. Notepad++ est typiquement dans cette zone grise : il est présent partout mais rarement géré comme un logiciel critique, et très souvent installé hors des circuits de packaging d’entreprise.
L’incident Notepad++ vient rappeler à tous que tout binaire capable de se mettre à jour automatiquement depuis Internet est un composant de la surface d’attaque, qu’il soit payant ou gratuit, propriétaire ou open source, un logiciel complexe ou un “simple éditeur de texte”.
Conséquence pratique : les RSSI et DSI doivent chercher, voire exiger, une visibilité fine sur toutes les versions installées et les modes de mise à jour activés.
« Savoir exactement quels systèmes disposaient de Notepad++ et quelles versions étaient installées permet d’identifier plus rapidement les machines potentiellement exposées. Un inventaire à jour permet aux équipes de désactiver rapidement les mises à jour, d’appliquer des mesures d’atténuation ou de rechercher des signes de compromission liés au logiciel concerné », rappellent les analystes de Forrester dans un billet de blog.
#2 / L’auto-update non maîtrisé est une dette de sécurité
C’est une pratique de sécurité que l’on a un peu oublié selon le principe qu’il faut que tous systèmes et tous logiciels soient toujours à jour pour réduire les risques : on ne devrait jamais laisser un parc applicatif décider seul quand et comment il se met à jour.
La bonne pratique consiste à internaliser la distribution de tous les binaires via un dépôt d’entreprise, un catalogue applicatif, ou un système de gestion de parc, afin de casser la dépendance directe entre le poste et l’infrastructure publique de l’éditeur.
Cette approche ne vise pas à ralentir les mises à jour, mais à les rendre vérifiables, traçables, et réversibles. Elle permet aussi de désactiver, quand c’est possible, les updaters intégrés qui téléchargent et exécutent du code sur un poste en production. L’incident Notepad++ illustre parfaitement le paradoxe. Beaucoup d’organisations durcissent l’accès aux dépôts de code ou aux registries de conteneurs, mais tolèrent des mécanismes de mise à jour “historiques” sur des utilitaires pourtant omniprésents.
#3 / Le chiffrement ne se négocie pas
L’attaque en elle-même et plus encore la correction apportée par les équipes de Notepad++ viennent nous rappeler qu’une mise à jour doit être authentifiée et intègre, sinon ce n’est pas une mise à jour, c’est une exécution distante !
Le projet indique explicitement que la mitigation a reposé sur la vérification de la signature et du certificat des installeurs téléchargés. Ce qui veut dire qu’avant l’incident, ce minimal n’existait pas.
Les logiciels autorisés à se mettre à jour automatiquement devraient démontrer la robustesse de leur mécanisme et ne pas se contenter d’une connexion HTTPS “par défaut”. Et les RSSI devraient pouvoir éprouver les mécanismes de mises à jour. Est-ce que l’updater refuse un binaire non signé, un certificat inattendu, une altération du manifest, une redirection vers un autre domaine, une rupture de chaîne de confiance ? Si la réponse est floue, l’auto-update doit être considéré comme non conforme.
#4 / La détection doit couvrir la chaîne de mise à jour
Détecter les malwares, c’est bien mais ça ne suffit pas. Ici, les attaquants ont joué sur un comportement légitime, un exécutable attendu, et une séquence standard.
Il faut veiller à formaliser des contrôles autour des updaters, au même titre que les navigateurs ou les outils d’administration, en utilisant des signaux autour des domaines de mises à jour, les requêtes réseaux, le comportement des outils de type « update.exe » ou « autoupdater.exe ». Ce sont des pistes immédiatement actionnables, parce qu’elles s’intègrent à des règles EDR, à une supervision Sysmon, ou à des corrélations réseau simples.
Dit autrement, il ne suffit plus de chercher “le binaire malveillant” : il faut surveiller la grammaire de l’update. Les outils EDR, la télémétrie réseau et les journaux proxy doivent être corrélés pour repérer un updater qui exécute des binaires inconnus ou initie des connexions suspectes, en croisant les événements locaux avec les flux réseau pour confirmer une compromission.
Forrester va un peu plus loin dans ses conseils : « À long terme, envisagez votre approche EDR spécifique au développeur. La plupart des programmes EDR sont conçus à l’aveugle face au comportement « attendu » des développeurs. Un utilitaire compromis n’a pas besoin d’exploits, de LOLBins ou de malwares exotiques. Il suffit que ça ait l’air ennuyeux — comme quelque chose qu’un développeur ferait. Un curl de spawn, PowerShell ou CMD mis à jour est normal. Un développeur qui exécute des binaires non signés depuis l’espace utilisateur est également normal, tout comme la sortie réseau depuis les ordinateurs portables. Les attaques de la chaîne d’approvisionnement l’emportent en se cachant à l’intérieur de ce que les défenseurs ont déjà normalisé comme un bruit acceptable. Si votre stratégie de détection repose sur la nouveauté plutôt que sur la violation des hypothèses de confiance, vous concédez structurellement cette catégorie d’attaque. »
#5 / L’open source n’est pas le problème, l’absence de modèle de confiance l’est
L’attaque ne remet nullement en cause l’open source, le risque étant identique avec les logiciels propriétaires. Elle rappelle que la sécurité d’un projet se joue autant sur son dépôt Git que sur son hébergement, ses DNS, ses clés de signature, sa CI/CD, et son processus de publication.
Autrement dit, tout projet logiciel doit aussi être évalué sur sa chaîne de livraison (et non seulement sur son binaire déployé ou sur son code source).
Pour Forrester, il faut aussi cesser de considérer le poste du développeur comme une zone d’exception où tout est permis. Dans un monde de diversification et de multiplication des attaques à la Supply Chain numérique, il est essentiel de les considérer comme des environnements d’exécution « sensibles » qui doivent être soumis à des règles strictes : définissez précisément quels logiciels sont autorisés, encadrez les processus qu’ils peuvent lancer et formalisez la politique de mise à jour qui leur est applicable. Si une organisation n’est pas capable d’imposer et de vérifier ces contraintes, elle ne maîtrise pas correctement le risque lié à la chaîne d’approvisionnement logicielle.
Voir plus loin encore
Au final, cet incident doit être vu comme une piqure de rappel et doit venir alimenter les exercices de crise. Les scénarios supply chain ne sont plus réservés aux gros éditeurs ou aux bibliothèques Java. Ils touchent aussi les petits outils “banals”, y compris ceux utilisés quotidiennement par les équipes IT. C’est précisément ce qui les rend stratégiques.
Pour Forrester, l’alerte va même au-delà. Elle doit nous ouvrir les yeux sur risques des déploiements en cours de l’IA. « Les agents IA brouillent encore davantage la dichotomie outil/opérateur. Les agents peuvent modifier des fichiers, exécuter des commandes, installer des dépendances et obtenir des mises à jour sans que vous interveniez. Ainsi, chaque utilitaire de confiance est une surface d’exécution autonome. Les mêmes angles morts de la chaîne d’approvisionnement qui permettent à un outil compromis de se fondre dans le bruit des développeurs permettront à un agent compromis d’établir de la persistance et d’élever des privilèges à grande échelle. »
Et les analystes d’ajouter un ultime avertissement : « Si vous ne pouvez pas définir strictement ce qui doit être exécuté, généré, mis à jour et communiqué avant de déléguer ces capacités aux agents, votre automatisation devient une vulnérabilité auto-propagée de la chaîne d’approvisionnement. »
À LIRE AUSSI :
À LIRE AUSSI :
