Bloom Security découvre une faille dans la publication de paquets, et les agents IA en démultiplient le risque

En 2025, des chercheurs ont analysé 576 000 extraits de code écrits par 16 modèles. En moyenne, 19,7% des paquets recommandés n'existaient tout simplement pas. Ces noms peuvent être enregistrés et remplis de code malveillant, puis il suffit d'attendre que l'assistant IA les intègre de lui-même dans un projet. Le problème a désormais une couche supplémentaire : la société Bloom Security décrit une vulnérabilité dans l'infrastructure de publication de logiciels qui, associée aux installations automatiques, peut acheminer du code malveillant jusque dans l'environnement d'une entreprise. C'est ce que rapporte The Next Web.

Ce que l'on sait de la vulnérabilité

Les détails techniques sont limités dans la partie accessible de la publication, il faut donc éviter toute extrapolation. Voici ce qui est établi : Bloom Security a trouvé un point faible dans les mécanismes de publication de paquets, et il devient plus dangereux quand l'installation des dépendances est confiée non plus à un humain, mais à un agent IA. À en juger par l'adresse de l'article, il s'agit du mécanisme Trusted Publishing de npm.

Ce dispositif permet de publier un paquet depuis un processus CI de confiance, sans jeton de longue durée. L'idée est raisonnable : les vols de jetons sont fréquents, et après la vague d'attaques contre npm en 2025, dont le ver Shai-Hulud qui a touché des centaines de paquets, l'écosystème a sérieusement revu ses pratiques de publication.

Une vulnérabilité dans le mécanisme de confiance lui-même s'attaque à une hypothèse de base : si un paquet est publié de la « bonne » manière, on peut lui faire confiance. L'agent partage cette hypothèse et ne la vérifiera pas.

Pourquoi les agents changent l'échelle du problème

Un humain qui ajoute une dépendance jette généralement au moins un coup d'œil au nom, au nombre de téléchargements, au dépôt. L'agent fonctionne autrement : il veut que les tests passent et que le build aboutisse. Si un paquet résout le problème, il se retrouve dans `package.json` en quelques secondes.

Trois facteurs se renforcent mutuellement :

• Vitesse. Un agent peut installer des dizaines de dépendances en une seule session, et chacune devient un point d'entrée.
• Hallucinations de noms. Selon l'étude de 2025, environ 20% de paquets inexistants dans les réponses des modèles offrent un terrain d'attaque par l'enregistrement de noms similaires.
• Droits. Les agents travaillent souvent dans un environnement ayant accès aux secrets, à la CI et aux dépôts internes, et les scripts d'installation npm s'exécutent immédiatement.

La vulnérabilité de publication ajoute un vecteur de plus : même un nom de paquet correct ne garantit plus la sécurité.

Qui est concerné

Les plus exposées sont les équipes où le codage assisté par IA est intégré au flux de travail sans politique dédiée aux dépendances : startups à cycle de release rapide, sous-traitants, équipes internes de plateforme. Les services de sécurité des entreprises ont l'habitude de contrôler les personnes et les pipelines, mais l'agent se place entre les deux et contourne ces deux niveaux de contrôle.

On ne sait pas encore dans quelle mesure la faille a été exploitée en pratique ni quelles versions sont touchées. Ces questions sont à poser au fournisseur du registre et aux chercheurs eux-mêmes.

Que faire dès maintenant

Il faut d'abord déterminer quels agents de l'entreprise peuvent exécuter `npm install`, et dans quel environnement. S'il s'agit du poste d'un développeur disposant de jetons et d'un accès aux dépôts privés, c'est la première zone à restreindre.

Ensuite, des mesures éprouvées s'appliquent :

• activer les fichiers de verrouillage (lock files) et interdire aux agents de les modifier sans revue ;
• désactiver l'exécution des scripts d'installation (`--ignore-scripts`) là où ils ne sont pas nécessaires ;
• mettre en place une allowlist de dépendances ou un miroir interne du registre avec un délai sur les nouvelles versions ;
• vérifier les nouveaux paquets selon leur ancienneté, le nombre de mainteneurs et la source de build ;
• exécuter les agents dans des bacs à sable isolés, sans secrets permanents.

La conclusion principale est simple : la confiance accordée au registre doit être vérifiée comme celle accordée au code, et la vitesse de l'agent ne doit pas dépasser celle de la vérification.