Attaque contre Axios et fausses applications Claude : la confiance logicielle devient une faille

Les attaques contre Axios en mars 2026 et la campagne SilverFox visant de fausses applications Claude n’employaient pas le même mode opératoire. Leur principe, en revanche, était identique : donner à un logiciel malveillant l’apparence d’un outil digne de confiance.

Dans un cas, l’attaque a exploité le compte légitime d’un mainteneur npm et une dépendance logicielle très répandue. Dans l’autre, les pirates ont usurpé l’identité d’un produit d’intelligence artificielle qu’un salarié pouvait raisonnablement vouloir installer pour son travail.

Ni la bibliothèque Axios légitime ni le produit Claude d’Anthropic ne sont intrinsèquement malveillants. La compromission concernait des versions précises d’Axios, tandis que SilverFox distribuait des programmes d’installation contrefaits.

Ce qui s’est passé chez Axios le 31 mars 2026

Un attaquant a pris le contrôle des accès de publication npm associés à un mainteneur principal d’Axios, puis a publié deux versions contaminées du paquet : axios@1.14.1 et axios@0.30.4. Toutes deux introduisaient une dépendance dissimulée, plain-crypto-js@4.2.1, qui n’était pas utilisée par les fonctions normales d’Axios. Son rôle était d’exécuter du code malveillant lors de l’installation.

Le script d’installation communiquait avec une infrastructure contrôlée par les attaquants et téléchargeait un cheval de Troie d’accès à distance — ou RAT — adapté à Windows, macOS et Linux. Une simple installation de dépendance pouvait donc devenir le point de départ d’une compromission plus large.

Les versions concernées sont restées disponibles environ trois heures. Google Threat Intelligence Group a observé l’activité entre 00 h 21 et 03 h 20 UTC le 31 mars, tandis que d’autres analyses évoquent une fenêtre comparable de deux à trois heures. Axios est une dépendance particulièrement sensible : les estimations publiées font état de 80 à plus de 100 millions de téléchargements hebdomadaires sur npm, selon les sources.

Un compte de mainteneur au cœur de l’attaque

Les informations publiques disponibles pointent vers une prise de contrôle d’un compte npm plutôt que vers une faille intrinsèque dans Axios. Un rapport indique que les attaquants ont utilisé un jeton d’accès npm ancien appartenant au mainteneur principal ; d’autres sources décrivent plus généralement une compromission du compte ou des identifiants de publication.

Cette nuance est importante. L’attaque a franchi la frontière de confiance entre l’autorité de publication d’un mainteneur et le processus de mise en ligne de npm. Comme les versions avaient été publiées via un compte légitime, les développeurs et les systèmes automatisés avaient moins de raisons de les considérer comme suspectes.

Le rôle de la dépendance malveillante

plain-crypto-js@4.2.1 se présentait comme une dépendance ordinaire, mais servait à exécuter un script postinstall. Celui-ci contactait un serveur de commande et de contrôle, puis récupérait une charge utile de second niveau adaptée au système d’exploitation de la machine.

Les développeurs n’avaient donc pas nécessairement besoin de télécharger un exécutable manifestement douteux. Le déclenchement pouvait venir d’une mise à jour classique, d’une compilation CI ou d’un

npm install

BlueNoroff est-il responsable ?

L’attribution n’est pas définitivement établie dans les éléments disponibles. Certains rapports relient l’opération à des acteurs associés à la Corée du Nord, notamment BlueNoroff ou des groupes apparentés, tandis que Microsoft attribue la compromission à Sapphire Sleet.

Ces évaluations ne doivent pas être présentées comme une conclusion unique et confirmée. Les similitudes de code, d’infrastructure ou de méthodes peuvent constituer une piste d’attribution, mais elles ne suffisent pas à prouver quel groupe a mené l’attaque. La conclusion la plus solide est que la compromission d’Axios a combiné un compte de mainteneur détourné, des versions piégées et un RAT multiplateforme ; l’identité de l’acteur reste discutée dans les analyses publiques.

SilverFox et les fausses applications Claude

SilverFox a emprunté une autre voie pour pénétrer les organisations : la diffusion d’applications Claude contrefaites pour Windows, macOS et Linux. La campagne visait des organisations des secteurs industriel, du conseil, du commerce et du transport en Inde, en Indonésie, en Afrique du Sud et en Russie.

Ces programmes imitaient la marque Claude d’Anthropic ; il ne s’agissait pas d’installateurs officiels. Leur efficacité reposait sur un scénario professionnel crédible : un salarié cherche un outil d’IA pour gagner en productivité, télécharge une application qui semble familière, puis installe en réalité un logiciel malveillant. Kaspersky a décrit cette opération comme une série de vagues liées aux activités de SilverFox observées depuis décembre 2025.

Des faux contrôles fiscaux aux fausses applications d’IA

La campagne s’inscrivait dans le prolongement de précédentes opérations d’hameçonnage sur le thème des impôts. En janvier et février 2026, les chercheurs ont recensé plus de 1 600 courriels malveillants se présentant comme des notifications officielles de contrôle fiscal ou prétendant contenir des listes d’infractions fiscales.

Le moyen de diffusion a évolué, mais le ressort psychologique est resté le même. Une notification fiscale joue sur l’urgence et l’autorité ; une application d’IA connue joue sur la pertinence et la commodité. Dans les deux cas, l’objectif est d’inciter l’utilisateur à ouvrir une pièce jointe, télécharger une archive ou installer un logiciel sans en vérifier l’origine.

SilverFox a également utilisé une diffusion en plusieurs étapes, avec une infrastructure distincte pour les différentes phases de l’intrusion. Cette segmentation peut compliquer le travail des équipes de sécurité, qui doivent repérer ou bloquer une chaîne d’attaque répartie entre plusieurs domaines et indicateurs.

La leçon commune : la confiance fait partie de la surface d’attaque

Les deux campagnes ont visé des relations de confiance différentes :

• Confiance dans le mainteneur : les versions d’Axios semblaient provenir d’un éditeur npm autorisé.
• Confiance dans les dépendances : le gestionnaire de paquets a traité la dépendance malveillante comme une étape normale de l’installation.
• Confiance dans la marque : les faux installateurs Claude empruntaient l’identité d’un produit d’IA reconnu.
• Confiance dans les habitudes de travail : développeurs et salariés ont suivi des actions ordinaires — mettre à jour des dépendances ou installer un outil de productivité.

Le cas Axios montre pourquoi une fenêtre d’exposition courte peut avoir des conséquences importantes. Les installations de paquets et les tâches CI peuvent s’exécuter automatiquement : le nombre de systèmes atteints ne dépend donc pas uniquement des personnes qui examinent manuellement une version.

Le cas SilverFox illustre le même phénomène côté poste de travail. À mesure que les outils d’IA deviennent courants dans les entreprises, ils offrent aux attaquants des leurres crédibles et faciles à contextualiser.

Les mesures à prendre

Pour l’incident Axios, les organisations devraient examiner leurs fichiers de verrouillage, manifestes de paquets, journaux de compilation, caches et inventaires de dépendances à la recherche de axios@1.14.1, axios@0.30.4 et plain-crypto-js@4.2.1. Toute machine ayant installé une version concernée pendant la fenêtre d’exposition doit être vérifiée pour détecter d’éventuelles charges téléchargées, une persistance non autorisée ou des identifiants compromis. Les avis recommandent de traiter ces installations comme potentiellement compromises.

Pour les logiciels d’IA, les entreprises devraient imposer l’utilisation de canaux approuvés, vérifier l’éditeur et le domaine de téléchargement, et bloquer ou placer en quarantaine les installateurs non autorisés.

Côté publication npm, l’authentification multifacteur résistante à l’hameçonnage, les identifiants à durée de vie courte ou aux privilèges limités, la provenance des versions, les fichiers de verrouillage et la revue des changements de dépendances peuvent réduire le risque qu’un seul compte compromis se transforme en attaque contre la chaîne logicielle.

Le contrôle le plus large consiste à vérifier chaque frontière de confiance. Un nom de paquet familier ne garantit pas que toutes ses versions sont sûres ; de même, le nom d’un produit connu ne garantit pas que chaque installateur qui l’utilise est authentique.