Les utilisateurs du package npm « @adonisjs/bodyparser » sont encouragés à mettre à jour vers la dernière version suite à la divulgation d'une vulnérabilité de sécurité critique qui, si elle est exploitée avec succès, pourrait permettre à un attaquant distant d'écrire des fichiers arbitraires sur le serveur.
Suivie comme CVE-2026-21440 (score CVSS : 9,2), la faille a été décrite comme un problème de traversée de chemin affectant le mécanisme de gestion des fichiers multiparts AdonisJS. “@adonisjs/bodyparser” est un package npm associé à AdonisJS, un framework Node.js pour développer des applications Web et des serveurs API avec TypeScript. La bibliothèque est utilisée pour traiter le corps de la requête HTTP AdonisJS.
“Si un développeur utilise MultipartFile.move() sans le deuxième argument d'options ou sans nettoyer explicitement le nom du fichier, un attaquant peut fournir une valeur de nom de fichier contrefaite contenant des séquences de parcours, écrivant dans un chemin de destination en dehors du répertoire de téléchargement prévu”, ont déclaré les responsables du projet dans un avis publié la semaine dernière. “Cela peut conduire à l'écriture arbitraire de fichiers sur le serveur.”
Cependant, une exploitation réussie dépend d’un point de recharge accessible. Le problème réside essentiellement dans une fonction appelée “MultipartFile.move(location, options)” qui vous permet de déplacer un fichier vers l'emplacement spécifié. Le paramètre « options » a deux valeurs : le nom d'un fichier et un indicateur d'écrasement indiquant « vrai » ou « faux ».
Le problème survient lorsque le paramètre name n'est pas transmis en entrée, ce qui amène l'application à utiliser par défaut un nom de fichier client non vérifié, ce qui ouvre la porte à la traversée d'itinéraire. Ceci, à son tour, permet à un attaquant de choisir une destination arbitraire de son choix et d'écraser les fichiers sensibles, si l'indicateur d'écrasement est défini sur « true ».
“Si l'attaquant peut écraser le code de l'application, les scripts de démarrage ou les fichiers de configuration qui sont ensuite exécutés/chargés, RCE [remote code execution] “C'est possible”, a déclaré AdonisJS. “RCE n'est pas garanti et dépend des autorisations du système de fichiers, de la conception du déploiement et du comportement de l'application/de l'exécution.”
Le problème, découvert et signalé par Hunter Wodzenski (@wodzen), affecte les versions suivantes :
Bug dans la bibliothèque jsPDF npm
Le développement coïncide avec la divulgation d'une autre vulnérabilité de traversée de chemin dans un package npm appelé jsPDF (CVE-2025-68428, score CVSS : 9,2) qui pourrait être exploitée pour transmettre des chemins non nettoyés et récupérer le contenu de fichiers arbitraires sur le système de fichiers local exécutant le processus de nœud.
La vulnérabilité a été corrigée dans la version 4.0.0 de jsPDF publiée le 3 janvier 2026. Pour contourner ce problème, il est recommandé d'utiliser l'indicateur –permission pour restreindre l'accès au système de fichiers. Un chercheur nommé Kwangwoon Kim a été crédité pour avoir signalé le bug.
“Le contenu du fichier est inclus textuellement dans les PDF générés”, a déclaré Parallax, les développeurs de la bibliothèque de génération de PDF JavaScript. “Seules les versions node.js de la bibliothèque sont concernées, c'est-à-dire les fichiers dist/jspdf.node.js et dist/jspdf.node.min.js.”
Dans une analyse distincte, Endor Labs a déclaré qu'une exploitation réussie entraîne une divulgation non autorisée de données sensibles, telles que des fichiers de configuration, des variables d'environnement et des informations d'identification, accessibles par le processus Node.js.
Le problème provient de la méthode “loadFile()” du module npm. Dans le cas où une entrée contrôlée par l'utilisateur est transmise comme argument de chemin de fichier, la bibliothèque lit le fichier spécifié à partir du disque et incorpore son contenu textuellement dans la sortie PDF générée. Cela affecte les méthodes publiques telles que addImage, html et addFont, chacune d'elles appelant en interne “loadFile()”.
“Il existe de nombreuses conditions dans lesquelles cette vulnérabilité n'est pas exploitable”, a-t-il déclaré. La question centrale est de savoir si un attaquant ou un utilisateur peut contrôler le premier argument passé aux méthodes affectées (loadFile, addImage, html, addFont). Si les chemins de fichiers sont cryptés ou proviennent de sources fiables, le risque est considérablement réduit. »