Quelles versions de jQuery sont vulnérables, et comment trouver la vôtre

Un scanner ou un rapport de pentest indique « vulnerable version of the library jQuery found », et la première réaction est en général « on a mis ça à jour il y a des années ». Les deux sont souvent vrais en même temps. Votre bundle embarque un jQuery récent, et un plugin, un thème, un widget d'un fournisseur ou une ligne CDN dans un vieux template embarque une seconde copie que personne ne se souvient avoir ajoutée.

Cet article liste les versions de jQuery avec des CVE publiées, explique pourquoi les vieilles copies continuent de réapparaître, montre comment trouver chaque copie qu'une page charge réellement, et se termine par le correctif.

Quelles versions de jQuery sont vulnérables

Chaque version de jQuery antérieure à 3.5.0 est concernée par au moins une CVE publiée. Les avis qui comptent, avec les versions qu'ils couvrent :

CVE	Versions concernées	Classe	Corrigé dans
CVE-2020-11022	Avant 3.5.0	XSS quand du HTML issu d'une source non fiable est passé à une méthode de manipulation du DOM, même après assainissement	3.5.0
CVE-2020-11023	Avant 3.5.0	XSS via des éléments `<option>` passés aux méthodes de manipulation du DOM	3.5.0
CVE-2019-11358	Avant 3.4.0	Pollution de prototype via `jQuery.extend` avec un objet source non fiable	3.4.0
CVE-2015-9251	Avant 3.0.0	XSS quand une requête Ajax cross-domain est émise sans `dataType` et que la réponse est exécutée	3.0.0
CVE-2012-6708	Avant 1.9.0	XSS quand une chaîne contenant `<` est passée à `jQuery()`, qui la traite comme du HTML. `location.hash` est le vecteur classique	1.9.0

En résumé : 3.5.0 ou ultérieur n'a aucune CVE publiée au moment où nous écrivons (septembre 2026). 3.4.x a les deux avis XSS de 2020. Tout ce qui se trouve dans les lignes 1.x ou 2.x cumule toutes celles qui s'appliquent, et ces lignes ne reçoivent plus de versions.

La sévérité est le plus souvent Medium selon CVSS, et les scanners classent souvent un jQuery obsolète comme un constat informatif. L'exploitabilité dépend de votre code : les avis de 2020 exigent que du HTML non fiable atteigne .html(), .append() ou une méthode similaire. Une page qui ne le fait jamais court un risque faible ; une page qui affiche des résultats de recherche ou des profils utilisateur via jQuery, non.

Pourquoi un vieux jQuery est encore sur votre site

jQuery est encore présent sur environ deux tiers de tous les sites web selon W3Techs, et la copie dans votre build est rarement celle que le scanner a trouvée. jQuery arrive sur une page par plus de chemins que n'importe quelle autre bibliothèque :

Le cœur d'un CMS. WordPress livre son propre jQuery et l'a mis à jour lentement pendant des années ; les installations anciennes servent encore une copie 1.x à chaque page.
Les plugins et les thèmes. Beaucoup embarquent une copie privée pour fonctionner quoi que le site fournisse. Deux ou trois copies sur une même page, c'est courant.
Les zones d'administration et les zones legacy. Un dashboard interne ou une étape de checkout construite à une autre époque garde ses propres balises script.
Les widgets et tags de fournisseurs. Un widget de chat, un outil de sondage ou un conteneur de tag manager charge jQuery pour son propre usage, dans la version choisie par son éditeur.
Une URL CDN figée. Une ligne <script src="https://code.jquery.com/jquery-1.12.4.min.js"> dans un template fonctionne aujourd'hui exactement comme le jour où elle a été écrite.
jQuery UI et jQuery Migrate. Les deux dépendent de jQuery et maintiennent souvent en vie un vieux cœur, parce que le mettre à jour les casserait.

L'étude à l'échelle du web qui a mesuré ce phénomène en premier, publiée à NDSS en 2017, a constaté qu'une grande part des inclusions de bibliothèques vulnérables venait de code tiers et de scripts injectés dynamiquement, plutôt que des développeurs du site eux-mêmes. Rien n'a changé depuis.

Comment vérifier quelle version de jQuery une page charge

Pour une page, ouvrez la console du navigateur et demandez :

jQuery.fn.jquery
// "3.7.1"

Cela répond pour la copie qui possède la globale jQuery. Cela ne répond pas pour les autres. Si un plugin a chargé sa propre copie en noConflict, ou si un widget d'un fournisseur a embarqué jQuery dans son propre fichier, la console vous montre une version et la page en exécute deux.

Pour les voir toutes, ouvrez le panneau Network des DevTools, filtrez sur JS et lisez la liste des scripts. Un nom de fichier ou un chemin CDN comme jquery-1.12.4.min.js donne la version. Une copie embarquée dans vendor.js ou widget.js ne la donne pas, et c'est là qu'un scanner de fichiers aide : téléchargez les scripts et passez Retire.js dessus. Il reconnaît jQuery au contenu du fichier, pas au nom.

npx retire --path ./downloaded-scripts

C'est une réponse pour une page, un jour donné. Le même site a d'autres pages, d'autres templates, et des tags qui changent sans déploiement.

Ce que signifie le constat du scanner

Les libellés varient selon l'outil : « Vulnerable version of the library jQuery found », « Out-of-date version (jQuery) », « Outdated JavaScript libraries », « Older and vulnerable jQuery version detected ». Ils veulent tous dire la même chose : le scanner a vu un fichier jQuery, a lu une version dans son contenu ou son URL, et a comparé cette version à une liste de CVE.

Trois choses à savoir quand vous en lisez un :

La sévérité est en général Information ou Low. Les scanners notent la présence de la version, pas l'exploitabilité sur votre page. Prenez-le comme un fait à traiter, pas comme un score de risque.
Un correctif rétroporté ne change pas la chaîne de version. Certaines distributions corrigent une CVE en gardant l'ancien numéro de version, donc le constat peut être un faux positif. L'inverse est vrai aussi : une chaîne de version ne prouve rien sur le contenu du fichier, et c'est pour cela qu'un hash de contenu vaut mieux qu'un nom de fichier.
Le constat nomme une seule URL. Il ne vous dit pas combien d'autres pages portent la même copie, ni quelles autres copies existent.

Trouver chaque copie sur tout le site, en continu

Le seul endroit qui voit chaque jQuery qu'une page exécute est le navigateur. Le hash reporting de la politique de sécurité du contenu (CSP) lui demande de rapporter un hash de chaque script qu'il exécute, sous la forme d'un rapport csp-hash, pour chaque page que de vrais visiteurs chargent. Le mécanisme est détaillé dans Comment détecter les bibliothèques JavaScript vulnérables sur un site en production ; la version courte, c'est une expression de source, 'report-sha256', et un endpoint de reporting.

Technologies dans CentralCSP transforme ces rapports en une ligne par version de bibliothèque. Un site qui exécute trois copies de jQuery affiche trois lignes, chacune avec son statut (à jour, obsolète ou dépréciée), les avis qui la concernent, et la liste des URL de scripts qui la portent. Cette liste répond à « d'où ça vient » : votre propre bundle, un chemin de plugin, un hôte de fournisseur ou une URL CDN figée, chacun avec un propriétaire différent et un correctif différent.

Le moteur identifie la bibliothèque derrière chaque script rapporté plutôt que de se fier à son nom de fichier, donc une copie embarquée dans un autre fichier est reconnue comme jQuery, et un fichier qui change à une URL stable apparaît comme un nouveau hash. Tout est continu, donc une mise à jour de plugin qui réintroduit une vieille copie est visible le jour même. La fonctionnalité est incluse dans les plans Scale et Enterprise ; la page des tarifs compare les plans, et la page de la fonctionnalité supply chain en fait le tour.

Comment corriger

Mettez à jour chaque copie qui vous appartient, retirez celles dont vous n'avez pas besoin, et figez ce qui reste.

Passez à la version 3.x actuelle. Les API supprimées sont la casse habituelle ; jQuery Migrate les restaure et journalise chaque usage pour que vous puissiez les nettoyer. Migrate restaure la compatibilité, il ne corrige pas les CVE, donc le cœur doit quand même bouger. N'appelez pas jQuery.UNSAFE_restoreLegacyHtmlPrefilter() pour faire taire les avertissements de Migrate : cela ramène le comportement XSS de 2020.
Supprimez les copies en double. Dans WordPress, retirez de la file (dequeue) la copie du plugin ou du thème et laissez celle du cœur servir. Ailleurs, supprimez la seconde balise script et laissez le bundle fournir jQuery.
Remplacez ou mettez à jour les widgets de fournisseurs qui embarquent une vieille copie. Si le fournisseur refuse de mettre à jour, le tag est le constat.
Figez le fichier avec Subresource Integrity. Un attribut integrity sur la balise script du CDN, généré à partir du fichier que vous livrez, empêche un fichier modifié de se charger. Il confirme les octets, il ne dit pas que la version est sûre, donc il vient après la mise à jour, pas à sa place. Voir Subresource Integrity expliqué.
Alertez sur les régressions. La règle d'alerte Outdated or deprecated version se déclenche quand une vieille copie revient via une mise à jour de plugin ou un nouveau tag, pour que le correctif reste corrigé.

FAQ

jQuery 3.x est-il encore vulnérable ?

Les versions 3.0.0 à 3.4.1 sont concernées par les deux avis XSS de 2020, CVE-2020-11022 et CVE-2020-11023, et les versions 3.0.0 à 3.3.x aussi par l'avis de pollution de prototype CVE-2019-11358. À partir de 3.5.0, aucune CVE publiée au moment où nous écrivons. Passez à la version 3.x actuelle et cherchez d'autres copies sur la page.

Comment vérifier quelle version de jQuery un site web utilise ?

Exécutez jQuery.fn.jquery dans la console du navigateur pour la copie qui possède la globale, puis regardez le panneau Network des DevTools pour d'autres fichiers jQuery, car les plugins et les widgets de fournisseurs chargent souvent le leur. Pour chaque page d'un site, en continu, utilisez le hash reporting CSP et un inventaire à l'exécution plutôt qu'une vérification manuelle.

jQuery 1.12 peut-il encore être utilisé sans risque ?

Non. La ligne 1.x est concernée par CVE-2020-11022, CVE-2020-11023, CVE-2019-11358 et CVE-2015-9251, et elle ne reçoit plus de versions, donc aucun correctif ne viendra. Passez à la version 3.x actuelle, en utilisant jQuery Migrate pour faire le pont sur les API supprimées pendant la migration, et vérifiez qu'un plugin ne charge pas une seconde copie sur la page.

jQuery Migrate corrige-t-il les vulnérabilités ?

Non. jQuery Migrate restaure les API que les versions récentes de jQuery ont supprimées, pour que l'ancien code continue de fonctionner après une mise à jour, et journalise chaque usage pour vous aider à le moderniser. Il ne corrige pas les failles de sécurité du cœur. Le correctif est le nouveau cœur jQuery ; Migrate facilite seulement la mise à jour.

Trouvez d'abord vos copies

La mise à jour est la partie facile. Le travail, c'est de trouver chaque copie, et le navigateur est le seul endroit qui les voit toutes. Ajoutez 'report-sha256' à votre directive de script, laissez les vrais chargements de page rapporter ce qui s'exécute, et lisez les lignes jQuery sur la page Technologies avec l'URL qui porte chacune. Commencez gratuitement avec CentralCSP et les premières copies apparaissent avec les premiers rapports.

Quelles versions de jQuery sont vulnérables, et comment trouver celle que votre site charge