Support technique
Documentation
Connexion
Nous contacter
Accédez directement au résumé généré par l'IA de cet article de blog 
Principaux enseignements
- La plupart des risques liés à jQuery proviennent d'anciennes versions encore utilisées en production, et non de failles récemment découvertes.
- Les failles XSS occupent les premières places du classement grâce aux vulnérabilités CVE-2020-11022, CVE-2020-11023 et CVE-2015-9251, suivies de près par la pollution de prototype.
- Les versions 1.x et 2.x de jQuery ne sont plus prises en charge ; la version 3.x ne bénéficie que de correctifs critiques ; et la version 4.x est la branche actuelle.
- Si une mise à niveau n'est pas encore envisageable, les correctifs fournis par le fournisseur permettent d'éviter qu'une ancienne version ne devienne un risque.
Un scanner de sécurité signale une vulnérabilité dans jQuery 3.4.1 au sein d’une application que personne n’a modifiée depuis trois ans, et vous vous retrouvez soudainement avec une faille CVE dont vous ignoriez l’existence. Voilà en quelques mots l’histoire des vulnérabilités de jQuery en 2026. Les failles sont anciennes, les correctifs existent, et le risque se cache dans une version dont personne ne se souvenait qu’elle était encore en production.
Ce guide passe en revue les vulnérabilités CVE concernées, explique ce qu'elles permettent à un attaquant de faire, pourquoi elles échappent systématiquement aux audits, et comment y remédier, que vous puissiez ou non effectuer une mise à jour.
Aperçu des vulnérabilités de jQuery
Les vulnérabilités jQuery sont des failles de sécurité présentes dans certaines versions de la bibliothèque qui peuvent permettre à un attaquant d'exécuter du code JavaScript non fiable dans le navigateur, de corrompre les prototypes d'objets partagés ou de provoquer le plantage d'une page. Elles sont répertoriées sous le nom de CVE, comme toute autre faille signalée.
Le problème, c'est que jQuery n'est pratiquement jamais maintenu activement par une équipe. Il est intégré à un paquet, verrouillé sur une version qui fonctionne, puis oublié. C'est dans cet écart entre « un correctif existe » et « le correctif est appliqué » que réside le véritable risque.
Types de vulnérabilités jQuery
Les failles présentées ci-dessous, correspondant à cinq CVE, se répartissent en trois catégories. Le XSS prédomine, bien que la pollution de prototype et le le déni de service complètent ce qui apparaît effectivement dans les résultats d’analyse.
| CVE | Type | Versions concernées | Corrigé dans |
| 11022 | XSS (htmlPrefilter) | 1,2 – 3,4.x | 3.5.0 |
| 11023 | XSS (select/option) | 1.0.3 – 3.4.x | 3.5.0 |
| 11358 | Pollution liée aux prototypes | 1.1.4 – 3.3.x | 3.4.0 |
| 9251 | XSS (Ajax inter-domaines) | Avant la version 3.0.0 | 3.0.0 |
Cross-Site Scripting (XSS)
Le XSS est le principal problème lié à jQuery. La vulnérabilité CVE-2020-11022 concerne le code HTML non vérifié transmis aux méthodes de manipulation du DOM de jQuery, et trouve son origine dans la manière dont jQuery.htmlPrefilter normalise le code HTML. CVE-2020-11023 concerne le code HTML contenant des éléments `option`. À elles deux, ces vulnérabilités touchent toutes les versions comprises entre la 1.0.3 et n'importe quelle version antérieure à la 3.5.0, ce qui inclut jQuery 3.4.1, toujours très répandue en production. Dans certaines conditions, un code contrôlé par un attaquant et transmis à l'une de ces méthodes peut finir par exécuter un script sur la page, même après avoir été nettoyé. Sur toutes les versions antérieures à la 3.0.0, vous êtes également exposé à la vulnérabilité CVE-2015-9251, une vulnérabilité XSS Ajax inter-domaines, pour laquelle la version 1.12.2 est la seule à avoir été corrigée dans cette plage.
Pollution liée aux prototypes
CVE-2019-11358 concerne les versions allant de la 1.1.4 à la 3.4.0, cette dernière non comprise. Un objet spécialement conçu transmis via jQuery.extend(true, {}, …) peut écrire dans Object.prototype, ce qui fait que les propriétés contrôlées par l'attaquant sont héritées par d'autres objets qui s'appuient sur cette chaîne de prototypes. En soi, il s'agit d'une technique de manipulation primitive. Selon la manière dont les propriétés corrompues sont utilisées en aval, cela peut déboucher sur des attaques XSS ou d'autres impacts spécifiques à l'application. Cette vulnérabilité a été particulièrement mise en évidence dans Drupal et Backdrop CMS, ce qui explique en partie pourquoi on la rencontre bien au-delà du code jQuery écrit à la main.
Déni de service (DoS)
La catégorie la plus silencieuse. La vulnérabilité CVE-2016-10707 affecte jQuery 3.0.0-rc.1 et rien d’autre. Cette version candidate ne gérait pas correctement les noms d’attributs booléens en majuscules et minuscules, ce qui entraînait une récursion infinie du getter concerné et épuisait la pile d’appels. L’impact est différent de celui de la paire de failles XSS, mais l’accès à ce chemin de code provoque tout de même le blocage de la page sur laquelle il s’exécute. La version finale 3.0.0 a corrigé ce problème.
Le saviez-vous ? Le rapport OSSRA 2026 (Black Duck) a identifié quatre CVE liés à jQuery parmi les 10 vulnérabilités les plus répandues, touchant au total entre 25 % et 28 % des bases de code auditées. Des failles vieilles de plusieurs années, pour lesquelles des correctifs sont disponibles depuis longtemps, apparaissent encore dans plus d'un quart des logiciels commerciaux.
Risques liés à l'absence de correction des vulnérabilités de jQuery
Une vulnérabilité CVE liée à jQuery n'est pas un risque abstrait. Cette bibliothèque est au cœur d'une grande partie du Web et, selon la nature de la vulnérabilité CVE présente et la manière dont votre application l'utilise, les conséquences peuvent aller de l'exécution de code dans les navigateurs de vos utilisateurs à une remarque dans un rapport d'audit, en passant par une page qui cesse de répondre.
Prise de contrôle de compte et vol de session
Les failles XSS constituent la principale conséquence des vulnérabilités CVE les plus répandues dans jQuery ; elles permettent à un attaquant d'exécuter du code JavaScript dans le navigateur de vos utilisateurs. Concrètement, cela se traduit par la capture d'identifiants sur un formulaire de connexion, le vol de toutes les données de session accessibles via JavaScript, ou encore la réalisation d'actions à l'insu de l'utilisateur connecté.
Les cookies « HttpOnly » empêchent l'accès au cookie lui-même, ce qui est utile, mais n'empêche en rien un attaquant d'agir au sein de cette session. Pour une petite application SaaS dont le tableau de bord d'administration fonctionne encore sous jQuery 3.4.1, une seule charge utile stockée suffit pour accéder à la session d'un administrateur.
Défauts de conformité et d'audit
Les vulnérabilités connues dans les dépendances de production apparaissent constamment lors des évaluations PCI DSS, des analyses de vulnérabilité et des audits de sécurité d’entreprise, et l’argument « ce n’est qu’une bibliothèque front-end » ne suffit pas à valider le rapport. Vous devez tout de même démontrer que le composant a été corrigé ou que des mesures correctives ont été prises. Les CVE sous-jacents sont ici réels et non pas de faux positifs, même si chaque résultat de scan doit tout de même être recoupé avec votre code réel et l’état de vos correctifs. Il est utile d’avoir cette distinction à portée de main avant qu’un auditeur ne la demande.
Un rayon d'action plus large que vous ne le pensez
jQuery n'est pratiquement jamais utilisé sous la forme d'une instance unique. Les thèmes, les plugins et les noyaux de CMS y ont tous recours ; ainsi, une version en fin de vie peut se retrouver sur des dizaines de pages ou de sous-systèmes. Suivre cette propagation demande un effort délibéré, et la lecture de correctement les scores CVSS est essentiel dès lors que l’on commence à établir des priorités dans la file d’attente.
Attention : De nombreux scanners de vulnérabilités et de conformité déduisent l’exposition à partir de la chaîne de caractères de la version de jQuery qu’ils détectent. Un correctif rétroporté qui conserve le numéro de version en amont peut tout de même déclencher une alerte ; veillez donc à documenter explicitement le correctif.
Comment les failles de sécurité de jQuery apparaissent-elles ?
Trois causes sont à l'origine de la quasi-totalité de ces problèmes : l'utilisation d'une ancienne version, l'héritage d'une version de jQuery que vous n'avez jamais choisie et la transmission de données non fiables à cette bibliothèque.
Versions obsolètes de jQuery
C'est la cause principale du problème pour la plupart des équipes. Les versions finales de jQuery 1.x et 2.x, respectivement 1.12.4 et 2.2.4, ont été publiées le 20 mai 2016, et aucune nouvelle version n'a été publiée depuis. La branche 3.x ne reçoit désormais que des correctifs de sécurité critiques et des corrections de bogues ; la version 3.7.1, datant d'août 2023, reste sa version la plus récente, et les responsables du projet recommandent à tous de passer à la version 4.x.
Une fois qu'une version n'est plus prise en charge en amont, les failles récemment découvertes ne seront pas corrigées par le projet jQuery, à moins que vous ne procédiez à une mise à jour ou que vous n'appliquiez des correctifs provenant d'une autre source prise en charge. C'est la même chose que pour tout logiciel en fin de vie : les responsables de la maintenance en amont cessent de s'en occuper, mais vos systèmes de production continuent de fonctionner quoi qu'il arrive.
jQuery hérité et transitif
On prend rarement des risques exprès. WordPress, Drupal et une longue liste de thèmes et de plugins d’interface utilisateur intègrent automatiquement jQuery. Il se retrouve dans votre pile sans que personne n’ait pris de décision, généralement lié à la version sur laquelle l’auteur du plugin a effectué ses tests. Pour repérer ces copies, il faut effectuer une analyse approfondie, et pas seulement jeter un œil à votre propre fichier package.json. C’est le même problème de dépendances cachées que celui qui apparaît dans la gestion des vulnérabilités PHP et dans de nombreux autres écosystèmes.
Modèles DOM non sécurisés
Même dans une version actuelle, l'injection de code HTML non fiable via .html() ou .append() peut encore entraîner une attaque XSS au niveau de l'application. La bibliothèque fait exactement ce que vous lui avez demandé. Le bug réside dans les données d'entrée auxquelles vous avez accordé votre confiance.
Les fusions en profondeur d'objets non fiables méritent le même examen minutieux, même si une version corrigée résout la vulnérabilité CVE-2019-11358 en elle-même ; le risque lié à $.extend réside dans ce que vous lui transmettez plutôt que dans la fonction elle-même. L'application du correctif comble la faille au niveau de la bibliothèque. La révision du code doit néanmoins détecter ce schéma.
Retour à la réalité : « Nous utilisons jQuery 3, donc tout va bien » est l’idée fausse la plus répandue. Les vulnérabilités CVE-2020-11022 et CVE-2020-11023 ne sont corrigées qu’à partir de la version 3.5.0 ; les versions 3.4.1 et toutes les versions antérieures de la série 3.x restent donc exposées.
Comment corriger les failles de sécurité de jQuery
Il existe un ordre clair des opérations à suivre. Effectuez une mise à jour si vous le pouvez, procurez-vous des correctifs fournis par le fournisseur si ce n'est pas possible, et dans tous les cas, mettez en place des mesures de protection supplémentaires.
1. Passez à une version prise en charge
La solution la plus propre. Passer à jQuery 3.5.0 ou une version ultérieure permet de corriger la vulnérabilité XSS, tandis que passer à la dernière version 4.x vous place sur la branche actuelle, bénéficiant d'un support complet en amont. Le hic, ce sont les changements rompant la compatibilité, car la version 4.0 a supprimé des API obsolètes telles que jQuery.trim et jQuery.isArray.
Commencez par un audit :
npm ls jquery
Si l'arborescence est propre, effectuez la mise à jour et exécutez la version de développement du plugin jQuery Migrate afin que les avertissements de compatibilité apparaissent avant la mise en production plutôt qu'après. Si une application héritée cesse de fonctionner suite à cette mise à jour, la deuxième option ci-dessous constitue la solution la plus réaliste.
2. Correctifs fournis par le fournisseur lorsque la mise à niveau n'est pas possible
De nombreuses équipes se trouvent véritablement dans une impasse. Un tableau de bord d’entreprise hérité, qui repose sur jQuery 1.x, ou un thème de CMS qui plante lors d’un changement majeur de version, ne va pas passer à la version 4.x du jour au lendemain. C’est précisément là que réside le problème que comble le service « Endless Lifecycle Support » (ELS) de TuxCare pour jQuery .
ELS intègre les correctifs CVE dans la version que vous utilisez déjà et les distribue via npm. La couverture s'étend sur dix versions, de jQuery 1.8.2 à 3.4.1, toutes dépassées depuis longtemps par la fin de vie définie par le développeur d'origine. L'avantage concret est d'assurer la sécurité sans imposer une migration ni une réécriture immédiate du front-end ; ainsi, une application fortement dépendante de jQuery peut continuer à bénéficier des correctifs pendant que l'équipe planifie la migration en bonne et due forme.
Cette couverture s'étend d'ailleurs au-delà de jQuery, pour englober les écosystèmes Java, JavaScript, Python, PHP et .NET.
3. Défense en profondeur
L'application de correctifs de vulnérabilités est la solution. Ces couches réduisent les dégâts lorsqu’une faille parvient malgré tout à passer. Considérez le code HTML contrôlé par un attaquant comme non sécurisé, privilégiez les API DOM sécurisées pour le texte lorsque c’est possible, et utilisez un outil de nettoyage HTML éprouvé lorsque l’application doit réellement afficher du balisage non fiable. Définissez en outre une politique de sécurité du contenu (CSP) stricte. Et générez un SBOM afin que chaque copie de jQuery répertoriée dans vos métadonnées de dépendances soit consignée.
Conseil de pro : Une recherche grep sur la chaîne de version ne détecte pas les copies minifiées et regroupées, et une SBOM générée à partir de vos manifestes et fichiers de verrouillage ne détectera pas celles qui n’ont jamais comporté de métadonnées npm. Exécutez également un scanner basé sur le contenu, tel que retire.js, sur vos ressources compilées, car il a été spécialement conçu pour détecter les bibliothèques qui ont été téléchargées et validées plutôt qu’installées.
Réduire au minimum les risques opérationnels liés à la fin de vie de jQuery
Le problème avec jQuery, ce n’est pas que cette bibliothèque soit obscure. C’est qu’elle est omniprésente, souvent obsolète, et que personne ne la surveille activement. C’est ainsi qu’une vulnérabilité CVE divulguée entre 2015 et 2020 finit par apparaître lors de votre prochain audit. Selon W3Techs, jQuery sur environ 66 % de tous les sites web, et un peu plus d’un site sur cinq utilise encore une branche 1.x ou 2.x dont la dernière version en amont remonte à 2016.
Identifiez toutes les occurrences. Mettez à jour ce que vous pouvez. Pour ce qui ne peut pas l’être, optez pour une couverture assurée par le fournisseur plutôt que de laisser le code exposé. Si vous êtes bloqué sur une version en fin de vie, le support à cycle de vie illimité de TuxCare pour jQuery vous permet de continuer à recevoir les correctifs pendant que vous planifiez la migration, sans vous obliger à réécrire le code avant d’être prêt.
