Assurez la sécurité des versions Webpack épinglées sans avoir à réécrire votre configuration ni à mettre à jour votre chaîne de chargement

L'équipe Webpack n'a jamais publié de date officielle de fin de vie, mais dans les faits, Webpack 4 n'est plus développé. Sa dernière version, la 4.47.0, date de septembre 2023, et aucun correctif de sécurité n'a été publié depuis. npm propose toujours une balise « webpack-4 » renvoyant à cette version, ce qui explique pourquoi certaines équipes pensent qu'elle est encore maintenue. webpack 4 utilise également toujours l'algorithme de hachage MD4, ce qui entraîne des erreurs sur Node.js 17 et les versions ultérieures sous OpenSSL 3, à moins d'utiliser le drapeau « legacy provider ».

ELS couvre actuellement les versions 5.50.0, 5.55.0, 5.76.1, 5.88.2 et 5.94.0 de webpack, ainsi que certaines versions de webpack-dev-server comprises entre 2.7.1 et 4.15.2 et les dépendances éligibles couvertes. D'autres versions pourront être ajoutées en fonction de l'évolution des besoins des clients. Contactez TuxCare pour discuter de la couverture d'une version ne figurant pas dans cette liste.

webpack 5 fait toujours l'objet d'un développement actif, mais les correctifs de sécurité sont intégrés dans les nouvelles versions du paquet plutôt que d'être rétroportés vers toutes les versions historiques de la branche 5.x. Même la version la plus récente prise en charge comporte des avis de sécurité en cours de traitement en amont : les vulnérabilités CVE-2025-68157 et CVE-2025-68458, toutes deux publiées en février 2026, ne sont corrigées que dans les versions 5.104.0 et 5.104.1, et affectent toutes les versions à partir de la 5.49.0 lorsque l’option `experiments.buildHttp` est activée. Un projet « pinned » dispose donc de trois options : effectuer une mise à niveau, maintenir un fork privé ou recourir à un support étendu commercial.

Parfois, ces failles parviennent jusqu’à l’environnement de production. La faille CVE-2024-43788, corrigée en amont dans la version 5.94.0, était un « gadget » de corruption du DOM présent dans le code d’exécution de Webpack lui-même, susceptible d’entraîner une attaque XSS sur les pages hébergeant des fichiers générés par Webpack ; des chercheurs en sécurité ont d’ailleurs démontré un exploit fonctionnel dans Canvas LMS. La vulnérabilité CVE-2023-28154, corrigée dans la version 5.76.0, permettait l’accès à des objets hors domaine lors de l’analyse syntaxique. Les scanners et les auditeurs signalent également les devDependencies non prises en charge, quel que soit l’environnement d’exécution.

Avec TuxCare ELS, configurez le registre npm de TuxCare, remplacez votre dépendance webpack par le paquet @els-js/webpack correspondant, ajoutez une entrée « overrides », réinstallez vos dépendances, puis vérifiez le résultat à l'aide de la commande « npm list ». Le TuxCare Patcher peut également détecter les versions de webpack prises en charge et mettre à jour automatiquement les dépendances et les remplacements concernés.

Non. Les paquets ELS sont des remplacements adaptés à la version, conçus pour préserver le comportement de la version de Webpack déjà utilisée par votre projet. Vos points d'entrée, chargeurs, plugins, règles de sortie, paramètres d'optimisation et scripts npm peuvent tous rester en place. Le déploiement nécessite une configuration du registre et des dépendances plutôt qu'une réécriture de la configuration, et les paquets sont compatibles avec Docker ; ils s'intègrent donc directement dans les environnements de build et d'intégration continue (CI) conteneurisés.

La mise à niveau constitue l'approche à privilégier à long terme lorsque votre projet est prêt. Dans la pratique, une mise à niveau de Webpack peut également nécessiter des mises à jour de Node.js, de l'interface CLI de Webpack, des plugins, des chargeurs et des options de configuration obsolètes ; elle peut également modifier le hachage, les identifiants de modules ou la gestion des ressources d'une manière susceptible d'affecter la purge du cache et la reproductibilité des builds. ELS maintient une version couverte et mise à jour pendant que votre équipe planifie et teste ces changements selon un calendrier raisonnable.