The npm registry now hosts over 2.5 million packages, making it the largest software ecosystem on the planet. Every day, developers pull billions of downloads to power everything from weekend side projects to enterprise platforms handling millions of users. But this massive scale comes with a massive attack surface. In 2026, the security landscape for npm packages is more complex than ever, with vulnerability reports increasing year over year and attackers growing more sophisticated in their techniques.

Tracking the most common types of npm vulnerabilities is not just an academic exercise — it is a practical necessity. A single unpatched dependency deep in your node_modules tree can open the door to data breaches, service disruptions, or complete system compromise. Whether you maintain a single application or manage dozens of projects for an agency, understanding these vulnerability categories helps you prioritize remediation and make informed decisions about which packages to trust.

In this article, we break down the top 10 npm vulnerability types that continue to dominate the CVE landscape in 2026, explain why each one is dangerous, and show you how to protect your Node.js projects effectively.

1. Prototype Pollution

Prototype pollution remains the single most prevalent vulnerability class in the npm ecosystem. This attack exploits JavaScript's prototype-based inheritance by injecting properties into Object.prototype, which then propagate to every object in the application. The consequences range from denial of service to remote code execution, depending on how the polluted properties are consumed downstream.

Packages that perform deep merging, cloning, or recursive property assignment are particularly susceptible. Libraries in the lodash family, merge-deep, defaults-deep, and dozens of similar utilities have historically been affected. Despite years of awareness, new instances continue to surface because the pattern of recursively copying properties from user-controlled input is so common in JavaScript code.

Severity: Critical to High. When prototype pollution reaches a code path that evaluates properties dynamically — for instance, a template engine checking constructor or __proto__ — it can escalate to full remote code execution.

What makes it dangerous: The vulnerability often exists in transitive dependencies that developers never directly interact with, making it invisible without automated scanning. A project with 500 dependencies might have 10 or more packages vulnerable to prototype pollution without anyone on the team realizing it.

2. Regular Expression Denial of Service (ReDoS)

ReDoS attacks exploit poorly written regular expressions that exhibit catastrophic backtracking. When a specially crafted input string is matched against a vulnerable regex, the matching algorithm can take exponential time, effectively freezing the Node.js event loop and making the entire application unresponsive.

This vulnerability type is especially dangerous in Node.js because of its single-threaded architecture. Unlike multi-threaded servers where a stuck thread only affects one request, a blocked event loop in Node.js means every single request is frozen. Input validation libraries, URL parsers, email validators, and syntax highlighters are frequent targets.

Severity: High. While ReDoS does not directly lead to data theft, it causes complete service denial with minimal attacker effort — sometimes a single HTTP request with a malicious header is enough.

What makes it dangerous: Developers rarely audit the complexity of regular expressions in their dependencies. A regex that works perfectly on normal input can become a weapon when fed adversarial strings. Tools like safe-regex and vuln-regex-detector can help, but they are not part of most CI pipelines.

3. Path Traversal in File-Handling Packages

Path traversal vulnerabilities allow attackers to access files outside the intended directory by manipulating file paths with sequences like ../ or encoded variants. In the npm ecosystem, this affects archive extraction libraries, static file servers, upload handlers, and any package that resolves user-supplied paths against the filesystem.

The classic scenario involves extracting a ZIP or tar archive that contains entries with relative paths pointing outside the extraction directory. Packages like tar, unzip, and various static file servers have all had path traversal bugs. In 2026, the problem persists because new packages frequently reimplement file handling without proper sanitization.

Severity: High to Critical. Successful path traversal can expose configuration files containing database credentials, environment variables with API keys, or even allow overwriting application code.

What makes it dangerous: Path traversal is deceptively simple. Developers often assume that a path like /uploads/../../../etc/passwd will be caught by their framework, but in many cases the vulnerable code runs before any middleware-level checks.

4. Command Injection via child_process Wrappers

Node.js provides the child_process module for executing system commands, and many npm packages wrap this functionality to provide convenient interfaces for tasks like image processing, PDF generation, Git operations, or system administration. When user input reaches these wrappers without proper sanitization, attackers can inject arbitrary shell commands.

The pattern is almost always the same: a package constructs a shell command string by concatenating user input, then passes it to exec() or execSync(). Even packages that use spawn() can be vulnerable if they pass shell: true as an option. Image manipulation wrappers around ImageMagick, FFmpeg wrappers, and Git client libraries are common culprits.

Severity: Critical. Command injection gives the attacker the same privileges as the Node.js process, which often means full server access including reading environment variables, accessing the database, and pivoting to other systems on the network.

What makes it dangerous: Many developers do not realize their dependencies invoke shell commands under the hood. A seemingly innocent call to resize an image might be constructing an ImageMagick command line that is vulnerable to injection.

5. Supply Chain Attacks (Typosquatting and Account Takeover)

Supply chain attacks target the npm ecosystem itself rather than exploiting bugs in legitimate packages. Typosquatting involves publishing malicious packages with names similar to popular ones — loadash instead of lodash, expres instead of express — hoping developers will install them by mistake. Account takeover attacks compromise the npm credentials of legitimate maintainers and push malicious updates to trusted packages.

In 2026, supply chain attacks have become increasingly sophisticated. Attackers now use automated tools to register misspellings of trending packages within hours of their publication. Some attacks involve long games where a malicious actor contributes legitimate code to a project for months before injecting a payload. The event-stream incident set the template, and variations of this approach continue to succeed.

Severity: Critical. Malicious packages typically exfiltrate environment variables (which often contain database URLs, API keys, and cloud credentials) during installation via postinstall scripts, or inject backdoors that activate under specific conditions.

What makes it dangerous: Traditional vulnerability scanners cannot detect supply chain attacks because there is no CVE for "this package was intentionally made malicious." Detection requires behavioral analysis, installation script auditing, and monitoring for packages that suddenly change ownership or behavior.

6. Insecure Deserialization

Insecure deserialization occurs when an application reconstructs objects from untrusted data without validation, allowing attackers to inject malicious objects that execute code during the deserialization process. In the Node.js world, this most commonly affects packages that serialize and deserialize JavaScript objects beyond simple JSON — particularly those that preserve functions, class instances, or special object types.

The node-serialize package is the textbook example, but the pattern appears in many form: YAML parsers that support custom types, template engines that evaluate embedded expressions, and session stores that deserialize complex objects. Any package that calls eval(), new Function(), or vm.runInNewContext() on data derived from user input is a potential target.

Severity: Critical. Insecure deserialization almost always leads to remote code execution because the attacker controls the object being reconstructed, including any methods that run during construction.

What makes it dangerous: The vulnerability is often hidden behind an abstraction layer. A developer using a session middleware might not realize it deserializes cookies using an unsafe method internally.

7. XML External Entity (XXE) Injection

XXE injection exploits XML parsers that process external entity declarations, allowing attackers to read local files, perform server-side requests, or cause denial of service. While JSON dominates the Node.js ecosystem, many applications still process XML for SOAP APIs, RSS feeds, SVG files, SAML authentication, Office document parsing, and payment gateway integrations.

The vulnerability exists when an XML parser is configured to resolve external entities by default. The attacker submits an XML document containing an entity definition that references a local file (file:///etc/passwd) or an internal URL, and the parser dutifully fetches and includes it in the response. Several npm XML parsing libraries have historically shipped with unsafe defaults.

Severity: High. XXE can expose sensitive files, enable SSRF, and in some configurations lead to remote code execution. The impact depends on the parser configuration and what the application does with the parsed result.

What makes it dangerous: Developers often assume that because they "mainly use JSON," they are not vulnerable to XXE. But a single endpoint that accepts XML — perhaps a webhook, a file upload handler for DOCX files, or a SAML integration — is enough for an attacker to exploit.

8. Server-Side Request Forgery (SSRF)

SSRF vulnerabilities allow attackers to make the server send HTTP requests to arbitrary destinations, including internal services that are not directly accessible from the internet. In the npm ecosystem, SSRF commonly affects HTTP client libraries, URL preview generators, webhook dispatchers, image proxy services, and PDF generation tools.

The attack is straightforward: the attacker provides a URL pointing to an internal resource (like http://169.254.169.254/latest/meta-data/ on AWS, or http://localhost:6379/ for Redis), and the vulnerable package fetches it on the server's behalf. Cloud metadata endpoints are the highest-value targets, as they often contain temporary credentials with broad permissions.

Severity: High to Critical. SSRF against cloud metadata services can yield full cloud account compromise. Even without cloud metadata, SSRF can expose internal APIs, bypass firewalls, and scan internal networks.

What makes it dangerous: Many packages that fetch URLs do not validate the destination. A URL shortener redirect, a DNS rebinding attack, or an IPv6 address can bypass naive allowlist checks. The rise of microservice architectures makes internal network access especially valuable to attackers.

9. Cross-Site Scripting via Template Engines

Server-side template engines in the Node.js ecosystem — including EJS, Pug, Handlebars, Nunjucks, and others — can introduce cross-site scripting (XSS) vulnerabilities when they render user-controlled data without proper escaping. While most modern template engines escape output by default, vulnerabilities arise from raw output modes, helper functions that bypass escaping, or template injection where the attacker controls part of the template itself.

Server-side template injection (SSTI) is the more severe variant. If an attacker can inject template syntax into a string that gets compiled as a template, they can often achieve remote code execution by accessing the template engine's internal objects and reaching Node.js built-in modules.

Severity: Medium to Critical. Simple XSS allows session hijacking and phishing. Template injection can escalate to full RCE, making it one of the most dangerous web vulnerabilities when present.

What makes it dangerous: Developers sometimes use raw/unescaped output for "trusted" content without considering that the content might originate from a database that was populated by user input. Template injection is less common but devastating when it occurs, and it is difficult to detect through automated testing.

10. Arbitrary Code Execution in Build Tools

Build tools, bundlers, transpilers, and development servers form a critical part of the Node.js toolchain, and vulnerabilities in these tools can lead to arbitrary code execution during the build process. This category includes issues in webpack plugins, Babel transforms, PostCSS plugins, and development servers that evaluate code in response to file changes.

The attack surface here is broad. A malicious or compromised configuration file, a crafted source file that exploits a parser bug, or a development server endpoint that accepts eval-able input can all lead to code execution. Since build tools often run with the developer's full privileges and have access to source code, environment variables, and deployment credentials, the impact of compromise is severe.

Severity: High to Critical. Build-time code execution can inject backdoors into production bundles, exfiltrate secrets from CI/CD environments, or compromise developer machines.

What makes it dangerous: Build tools are trusted implicitly. Developers run npm run build thousands of times without questioning whether their webpack configuration or PostCSS plugins might be executing malicious code. Security audits rarely cover the build pipeline with the same rigor as production code.

How to Protect Your Node.js Projects

Knowing the vulnerability types is only half the battle. Here are concrete steps to defend your projects against the threats listed above:

Use npm audit regularly

Run npm audit after every install and as part of your CI pipeline. While it only catches known vulnerabilities with published advisories, it is the minimum baseline for dependency security. Pay attention to the severity ratings and prioritize fixing critical and high issues immediately.

Lock your dependencies

Always commit your package-lock.json (or yarn.lock / pnpm-lock.yaml) and use npm ci instead of npm install in CI environments. This ensures reproducible builds and prevents unexpected updates from introducing new vulnerabilities.

Audit postinstall scripts

Use --ignore-scripts during installation and selectively enable scripts only for packages that genuinely need them. Tools like npm-audit-resolver and socket.dev can help identify packages with suspicious installation behavior.

Monitor continuously

New vulnerabilities are disclosed daily. A project that passes npm audit today can have three critical vulnerabilities tomorrow. Continuous monitoring tools like CVE OptiBot scan your lockfiles on a regular schedule and alert you immediately when new issues are found — without requiring access to your source code.

Keep dependencies minimal

Every dependency is a liability. Before adding a new package, ask whether the functionality it provides justifies the security surface it adds. For simple utilities, consider copying the relevant function into your codebase rather than importing an entire library.

The Case for Continuous Monitoring

The npm vulnerability landscape changes daily. In any given week, dozens of new advisories are published across the ecosystem. Manually running npm audit once in a while is not enough — by the time you check, your projects might have been exposed for days or weeks.

This is especially true for agencies and developers managing multiple projects. If you have 15 projects each with hundreds of dependencies, the combinatorial explosion of potential vulnerabilities makes manual tracking impossible. You need an automated system that watches your dependency files, cross-references them against the latest vulnerability databases, and notifies you the moment something requires attention.

CVE OptiBot was built for exactly this purpose. Upload your package-lock.json, requirements.txt, or composer.lock, and get continuous monitoring with daily scans, email alerts for new vulnerabilities, and PDF reports you can share with clients. No source code access required — just your dependency manifest files.

In a world where a single overlooked CVE can lead to a breach, continuous monitoring is not optional. It is a fundamental part of responsible software development.

Le registre npm héberge désormais plus de 2,5 millions de packages, ce qui en fait le plus grand écosystème logiciel au monde. Chaque jour, les développeurs téléchargent des milliards de fois ces packages pour alimenter aussi bien des projets personnels que des plateformes d'entreprise servant des millions d'utilisateurs. Mais cette échelle massive s'accompagne d'une surface d'attaque tout aussi massive. En 2026, le paysage sécuritaire des packages npm est plus complexe que jamais, avec des rapports de vulnérabilités en hausse constante et des attaquants toujours plus sophistiqués dans leurs techniques.

Suivre les types de vulnérabilités npm les plus courants n'est pas un exercice académique — c'est une nécessité pratique. Une seule dépendance non corrigée au fond de votre arbre node_modules peut ouvrir la porte à des fuites de données, des interruptions de service ou une compromission complète du système. Que vous mainteniez une seule application ou que vous gériez des dizaines de projets pour une agence, comprendre ces catégories de vulnérabilités vous aide à prioriser les corrections et à prendre des décisions éclairées sur les packages à utiliser.

Dans cet article, nous analysons les 10 types de vulnérabilités npm qui continuent de dominer le paysage CVE en 2026, nous expliquons pourquoi chacun est dangereux et nous vous montrons comment protéger efficacement vos projets Node.js.

1. Pollution de prototype (Prototype Pollution)

La pollution de prototype reste la classe de vulnérabilité la plus répandue dans l'écosystème npm. Cette attaque exploite l'héritage prototypal de JavaScript en injectant des propriétés dans Object.prototype, qui se propagent ensuite à tous les objets de l'application. Les conséquences vont du déni de service à l'exécution de code à distance, selon la manière dont les propriétés polluées sont consommées en aval.

Les packages qui effectuent des fusions profondes, du clonage ou de l'assignation récursive de propriétés sont particulièrement vulnérables. Les bibliothèques de la famille lodash, merge-deep, defaults-deep et des dizaines d'utilitaires similaires ont historiquement été affectés. Malgré des années de sensibilisation, de nouvelles instances continuent d'apparaître car le pattern de copie récursive de propriétés à partir d'entrées contrôlées par l'utilisateur est extrêmement courant en JavaScript.

Sévérité : Critique à Haute. Lorsque la pollution de prototype atteint un chemin de code qui évalue dynamiquement des propriétés — par exemple, un moteur de templates vérifiant constructor ou __proto__ — elle peut escalader jusqu'à une exécution de code à distance complète.

Ce qui la rend dangereuse : La vulnérabilité existe souvent dans des dépendances transitives avec lesquelles les développeurs n'interagissent jamais directement, ce qui la rend invisible sans scan automatisé. Un projet avec 500 dépendances peut avoir 10 packages ou plus vulnérables à la pollution de prototype sans que personne dans l'équipe ne s'en rende compte.

2. Déni de service par expressions régulières (ReDoS)

Les attaques ReDoS exploitent des expressions régulières mal écrites qui présentent un backtracking catastrophique. Lorsqu'une chaîne d'entrée spécialement conçue est testée contre une regex vulnérable, l'algorithme de correspondance peut prendre un temps exponentiel, gelant effectivement la boucle événementielle de Node.js et rendant l'application entière non réactive.

Ce type de vulnérabilité est particulièrement dangereux dans Node.js en raison de son architecture mono-thread. Contrairement aux serveurs multi-threadés où un thread bloqué n'affecte qu'une seule requête, une boucle événementielle bloquée dans Node.js signifie que chaque requête est gelée. Les bibliothèques de validation d'entrées, les parseurs d'URL, les validateurs d'e-mails et les outils de coloration syntaxique sont des cibles fréquentes.

Sévérité : Haute. Bien que le ReDoS ne mène pas directement au vol de données, il provoque un déni de service complet avec un effort minimal de l'attaquant — parfois une seule requête HTTP avec un en-tête malveillant suffit.

Ce qui le rend dangereux : Les développeurs audittent rarement la complexité des expressions régulières dans leurs dépendances. Une regex qui fonctionne parfaitement sur des entrées normales peut devenir une arme lorsqu'elle est alimentée par des chaînes adversariales. Des outils comme safe-regex et vuln-regex-detector peuvent aider, mais ils ne font pas partie de la plupart des pipelines CI.

3. Traversée de répertoire (Path Traversal)

Les vulnérabilités de traversée de répertoire permettent aux attaquants d'accéder à des fichiers en dehors du répertoire prévu en manipulant les chemins avec des séquences comme ../ ou des variantes encodées. Dans l'écosystème npm, cela affecte les bibliothèques d'extraction d'archives, les serveurs de fichiers statiques, les gestionnaires d'upload et tout package qui résout des chemins fournis par l'utilisateur contre le système de fichiers.

Le scénario classique implique l'extraction d'une archive ZIP ou tar contenant des entrées avec des chemins relatifs pointant en dehors du répertoire d'extraction. Des packages comme tar, unzip et divers serveurs de fichiers statiques ont tous eu des bugs de traversée de répertoire. En 2026, le problème persiste car de nouveaux packages réimplémentent fréquemment la gestion des fichiers sans assainissement adéquat.

Sévérité : Haute à Critique. Une traversée de répertoire réussie peut exposer des fichiers de configuration contenant des identifiants de base de données, des variables d'environnement avec des clés API, ou même permettre l'écrasement du code applicatif.

Ce qui la rend dangereuse : La traversée de répertoire est trompeusement simple. Les développeurs supposent souvent qu'un chemin comme /uploads/../../../etc/passwd sera intercepté par leur framework, mais dans de nombreux cas, le code vulnérable s'exécute avant tout contrôle au niveau middleware.

4. Injection de commande via les wrappers child_process

Node.js fournit le module child_process pour exécuter des commandes système, et de nombreux packages npm encapsulent cette fonctionnalité pour offrir des interfaces pratiques pour des tâches comme le traitement d'images, la génération de PDF, les opérations Git ou l'administration système. Lorsque l'entrée utilisateur atteint ces wrappers sans assainissement approprié, les attaquants peuvent injecter des commandes shell arbitraires.

Le schéma est presque toujours le même : un package construit une chaîne de commande shell en concaténant l'entrée utilisateur, puis la passe à exec() ou execSync(). Même les packages qui utilisent spawn() peuvent être vulnérables s'ils passent shell: true en option. Les wrappers de manipulation d'images autour d'ImageMagick, les wrappers FFmpeg et les bibliothèques client Git sont des coupables fréquents.

Sévérité : Critique. L'injection de commande donne à l'attaquant les mêmes privilèges que le processus Node.js, ce qui signifie souvent un accès complet au serveur, incluant la lecture des variables d'environnement, l'accès à la base de données et le pivotement vers d'autres systèmes du réseau.

Ce qui la rend dangereuse : De nombreux développeurs ne réalisent pas que leurs dépendances invoquent des commandes shell en coulisses. Un appel apparemment innocent pour redimensionner une image peut construire une ligne de commande ImageMagick vulnérable à l'injection.

5. Attaques de la chaîne d'approvisionnement (Typosquatting et prise de contrôle de compte)

Les attaques de la chaîne d'approvisionnement ciblent l'écosystème npm lui-même plutôt que d'exploiter des bugs dans des packages légitimes. Le typosquatting consiste à publier des packages malveillants avec des noms similaires à ceux de packages populaires — loadash au lieu de lodash, expres au lieu de express — en espérant que les développeurs les installeront par erreur. Les attaques par prise de contrôle de compte compromettent les identifiants npm de mainteneurs légitimes et poussent des mises à jour malveillantes vers des packages de confiance.

En 2026, les attaques de la chaîne d'approvisionnement sont devenues de plus en plus sophistiquées. Les attaquants utilisent désormais des outils automatisés pour enregistrer des fautes de frappe de packages tendance dans les heures suivant leur publication. Certaines attaques impliquent des stratégies à long terme où un acteur malveillant contribue du code légitime à un projet pendant des mois avant d'injecter une charge utile. L'incident event-stream a établi le modèle, et des variations de cette approche continuent de réussir.

Sévérité : Critique. Les packages malveillants exfiltrent typiquement les variables d'environnement (qui contiennent souvent des URL de base de données, des clés API et des identifiants cloud) pendant l'installation via des scripts postinstall, ou injectent des portes dérobées qui s'activent sous des conditions spécifiques.

Ce qui les rend dangereuses : Les scanners de vulnérabilités traditionnels ne peuvent pas détecter les attaques de la chaîne d'approvisionnement car il n'y a pas de CVE pour « ce package a été intentionnellement rendu malveillant ». La détection nécessite une analyse comportementale, un audit des scripts d'installation et une surveillance des packages qui changent soudainement de propriétaire ou de comportement.

6. Désérialisation non sécurisée

La désérialisation non sécurisée se produit lorsqu'une application reconstruit des objets à partir de données non fiables sans validation, permettant aux attaquants d'injecter des objets malveillants qui exécutent du code pendant le processus de désérialisation. Dans le monde Node.js, cela affecte le plus souvent les packages qui sérialisent et désérialisent des objets JavaScript au-delà du simple JSON — en particulier ceux qui préservent les fonctions, les instances de classe ou les types d'objets spéciaux.

Le package node-serialize est l'exemple classique, mais le pattern apparaît sous de nombreuses formes : les parseurs YAML qui supportent les types personnalisés, les moteurs de templates qui évaluent les expressions intégrées et les magasins de session qui désérialisent des objets complexes. Tout package qui appelle eval(), new Function() ou vm.runInNewContext() sur des données dérivées de l'entrée utilisateur est une cible potentielle.

Sévérité : Critique. La désérialisation non sécurisée mène presque toujours à l'exécution de code à distance car l'attaquant contrôle l'objet reconstruit, y compris toutes les méthodes qui s'exécutent pendant la construction.

Ce qui la rend dangereuse : La vulnérabilité est souvent cachée derrière une couche d'abstraction. Un développeur utilisant un middleware de session peut ne pas réaliser qu'il désérialise les cookies en utilisant une méthode non sécurisée en interne.

7. Injection d'entité externe XML (XXE)

L'injection XXE exploite les parseurs XML qui traitent les déclarations d'entités externes, permettant aux attaquants de lire des fichiers locaux, d'effectuer des requêtes côté serveur ou de provoquer un déni de service. Bien que le JSON domine l'écosystème Node.js, de nombreuses applications traitent encore du XML pour les API SOAP, les flux RSS, les fichiers SVG, l'authentification SAML, le parsing de documents Office et les intégrations de passerelles de paiement.

La vulnérabilité existe lorsqu'un parseur XML est configuré pour résoudre les entités externes par défaut. L'attaquant soumet un document XML contenant une définition d'entité qui référence un fichier local (file:///etc/passwd) ou une URL interne, et le parseur le récupère et l'inclut fidèlement dans la réponse. Plusieurs bibliothèques npm de parsing XML ont historiquement été livrées avec des paramètres par défaut non sécurisés.

Sévérité : Haute. Le XXE peut exposer des fichiers sensibles, permettre le SSRF et, dans certaines configurations, mener à l'exécution de code à distance. L'impact dépend de la configuration du parseur et de ce que l'application fait avec le résultat analysé.

Ce qui la rend dangereuse : Les développeurs supposent souvent que parce qu'ils « utilisent principalement du JSON », ils ne sont pas vulnérables au XXE. Mais un seul endpoint qui accepte du XML — peut-être un webhook, un gestionnaire d'upload pour les fichiers DOCX ou une intégration SAML — suffit pour qu'un attaquant exploite la faille.

8. Falsification de requête côté serveur (SSRF)

Les vulnérabilités SSRF permettent aux attaquants de faire envoyer par le serveur des requêtes HTTP vers des destinations arbitraires, y compris des services internes qui ne sont pas directement accessibles depuis Internet. Dans l'écosystème npm, le SSRF affecte couramment les bibliothèques client HTTP, les générateurs d'aperçu d'URL, les dispatchers de webhooks, les services proxy d'images et les outils de génération de PDF.

L'attaque est directe : l'attaquant fournit une URL pointant vers une ressource interne (comme http://169.254.169.254/latest/meta-data/ sur AWS, ou http://localhost:6379/ pour Redis), et le package vulnérable la récupère au nom du serveur. Les endpoints de métadonnées cloud sont les cibles de plus haute valeur, car ils contiennent souvent des identifiants temporaires avec des permissions étendues.

Sévérité : Haute à Critique. Le SSRF contre les services de métadonnées cloud peut mener à la compromission complète du compte cloud. Même sans métadonnées cloud, le SSRF peut exposer des API internes, contourner les pare-feu et scanner les réseaux internes.

Ce qui le rend dangereux : De nombreux packages qui récupèrent des URL ne valident pas la destination. Une redirection de raccourcisseur d'URL, une attaque par rebinding DNS ou une adresse IPv6 peuvent contourner les vérifications naïves de listes blanches. L'essor des architectures microservices rend l'accès au réseau interne particulièrement précieux pour les attaquants.

9. Cross-Site Scripting via les moteurs de templates

Les moteurs de templates côté serveur de l'écosystème Node.js — incluant EJS, Pug, Handlebars, Nunjucks et d'autres — peuvent introduire des vulnérabilités de cross-site scripting (XSS) lorsqu'ils affichent des données contrôlées par l'utilisateur sans échappement approprié. Bien que la plupart des moteurs de templates modernes échappent la sortie par défaut, les vulnérabilités surviennent des modes de sortie brute, des fonctions helper qui contournent l'échappement ou de l'injection de template où l'attaquant contrôle une partie du template lui-même.

L'injection de template côté serveur (SSTI) est la variante la plus sévère. Si un attaquant peut injecter de la syntaxe de template dans une chaîne qui est compilée comme template, il peut souvent atteindre l'exécution de code à distance en accédant aux objets internes du moteur de template et en atteignant les modules natifs de Node.js.

Sévérité : Moyenne à Critique. Le XSS simple permet le détournement de session et le phishing. L'injection de template peut escalader jusqu'à une RCE complète, ce qui en fait l'une des vulnérabilités web les plus dangereuses lorsqu'elle est présente.

Ce qui le rend dangereux : Les développeurs utilisent parfois la sortie brute/non échappée pour du contenu « de confiance » sans considérer que ce contenu pourrait provenir d'une base de données alimentée par des entrées utilisateur. L'injection de template est moins courante mais dévastatrice quand elle se produit, et elle est difficile à détecter par des tests automatisés.

10. Exécution de code arbitraire dans les outils de build

Les outils de build, bundlers, transpileurs et serveurs de développement forment une partie critique de la chaîne d'outils Node.js, et les vulnérabilités dans ces outils peuvent mener à l'exécution de code arbitraire pendant le processus de build. Cette catégorie inclut les problèmes dans les plugins webpack, les transforms Babel, les plugins PostCSS et les serveurs de développement qui évaluent du code en réponse aux changements de fichiers.

La surface d'attaque ici est large. Un fichier de configuration malveillant ou compromis, un fichier source conçu pour exploiter un bug de parseur, ou un endpoint de serveur de développement qui accepte des entrées évaluables peuvent tous mener à l'exécution de code. Comme les outils de build s'exécutent souvent avec les pleins privilèges du développeur et ont accès au code source, aux variables d'environnement et aux identifiants de déploiement, l'impact d'une compromission est sévère.

Sévérité : Haute à Critique. L'exécution de code au moment du build peut injecter des portes dérobées dans les bundles de production, exfiltrer des secrets des environnements CI/CD ou compromettre les machines des développeurs.

Ce qui la rend dangereuse : Les outils de build sont implicitement dignes de confiance. Les développeurs exécutent npm run build des milliers de fois sans se demander si leur configuration webpack ou leurs plugins PostCSS pourraient exécuter du code malveillant. Les audits de sécurité couvrent rarement le pipeline de build avec la même rigueur que le code de production.

Comment protéger vos projets Node.js

Connaître les types de vulnérabilités n'est que la moitié de la bataille. Voici des étapes concrètes pour défendre vos projets contre les menaces listées ci-dessus :

Utilisez npm audit régulièrement

Exécutez npm audit après chaque installation et dans le cadre de votre pipeline CI. Bien qu'il ne détecte que les vulnérabilités connues avec des avis publiés, c'est le minimum de base pour la sécurité des dépendances. Faites attention aux niveaux de sévérité et priorisez la correction immédiate des problèmes critiques et hauts.

Verrouillez vos dépendances

Committez toujours votre package-lock.json (ou yarn.lock / pnpm-lock.yaml) et utilisez npm ci au lieu de npm install dans les environnements CI. Cela garantit des builds reproductibles et empêche les mises à jour inattendues d'introduire de nouvelles vulnérabilités.

Auditez les scripts postinstall

Utilisez --ignore-scripts pendant l'installation et activez sélectivement les scripts uniquement pour les packages qui en ont véritablement besoin. Des outils comme npm-audit-resolver et socket.dev peuvent aider à identifier les packages avec un comportement d'installation suspect.

Surveillez en continu

De nouvelles vulnérabilités sont divulguées chaque jour. Un projet qui passe npm audit aujourd'hui peut avoir trois vulnérabilités critiques demain. Les outils de surveillance continue comme CVE OptiBot scannent vos fichiers de lock selon un planning régulier et vous alertent immédiatement lorsque de nouveaux problèmes sont trouvés — sans nécessiter l'accès à votre code source.

Gardez un minimum de dépendances

Chaque dépendance est une responsabilité. Avant d'ajouter un nouveau package, demandez-vous si la fonctionnalité qu'il fournit justifie la surface de sécurité qu'il ajoute. Pour des utilitaires simples, envisagez de copier la fonction pertinente dans votre code plutôt que d'importer une bibliothèque entière.

L'importance du monitoring continu

Le paysage des vulnérabilités npm change quotidiennement. Au cours d'une semaine donnée, des dizaines de nouveaux avis sont publiés à travers l'écosystème. Exécuter manuellement npm audit de temps en temps ne suffit pas — le temps que vous vérifiez, vos projets pourraient avoir été exposés pendant des jours ou des semaines.

C'est particulièrement vrai pour les agences et développeurs gérant plusieurs projets. Si vous avez 15 projets avec chacun des centaines de dépendances, l'explosion combinatoire des vulnérabilités potentielles rend le suivi manuel impossible. Vous avez besoin d'un système automatisé qui surveille vos fichiers de dépendances, les croise avec les dernières bases de données de vulnérabilités et vous notifie dès que quelque chose nécessite votre attention.

CVE OptiBot a été conçu exactement pour cela. Importez votre package-lock.json, requirements.txt ou composer.lock, et bénéficiez d'une surveillance continue avec des scans quotidiens, des alertes e-mail pour les nouvelles vulnérabilités et des rapports PDF que vous pouvez partager avec vos clients. Aucun accès au code source n'est requis — uniquement vos fichiers manifestes de dépendances.

Dans un monde où une seule CVE négligée peut mener à une brèche, la surveillance continue n'est pas optionnelle. C'est une partie fondamentale du développement logiciel responsable.