Fin de vie de jQuery UI et comment garantir la sécurité

Principaux enseignements

• jQuery UI est en mode « maintenance uniquement » depuis octobre 2021, et seules les corrections sont apportées à la version mineure la plus récente.
• jQuery UI 1.10.4 comporte trois failles XSS connues, qui ont toutes été corrigées uniquement dans la version 1.13.0.
• Les versions de jQuery antérieures à la 3.5.0 comportent une faille XSS exploitée et répertoriée par la CISA, et une version de jQuery UI datant de 2014 complique cette mise à jour.
• Les solutions réalistes consistent à passer à la version 1.14.x, à remplacer les widgets ou à souscrire à une assistance étendue.

De nombreuses entreprises qui ont développé des applications web entre 2008 et 2018 utilisent encore jQuery UI quelque part dans leur code. Le sélecteur de date d’un formulaire de notes de frais. La boîte de dialogue modale d’un panneau d’administration. La fonction d’autocomplétion d’un champ de recherche interne. Ces composants fonctionnent toujours, et c’est précisément pour cette raison que personne n’y a touché depuis des années. Le problème, c’est que la fin de vie de jQuery UI est arrivée discrètement alors que ces applications continuaient de fonctionner, et que pour les anciennes versions, les correctifs de sécurité en amont ne sont plus rétroportés.

Cet article fait le point sur l'état actuel de la prise en charge de jQuery UI, passe en revue les vulnérabilités CVE qui affectent les versions encore en production, explique pourquoi sa dépendance à jQuery mérite davantage d'attention que la bibliothèque elle-même, et présente les options qui s'offrent à vous à partir de là.

Figure 1 : Les widgets que vous reconnaîtrez.

jQuery UI est-il vraiment en fin de vie ?

Pour toutes les versions sauf la plus récente, oui. En octobre 2021, les responsables de jQuery ont placé jQuery UI en mode « maintenance uniquement », annonçant que la version 1.13.0 serait la dernière version prévue pour le projet. Les plans ont quelque peu évolué et des versions ont continué à être publiées depuis, mais uniquement pour des corrections de sécurité, de compatibilité et de régression, et uniquement sur la version mineure la plus récente.

Il n'existe pas de calendrier de fin de vie publié pour jQuery UI ; les dates indiquées ci-dessous découlent donc de cette politique de « mise à jour uniquement vers la version mineure la plus récente » plutôt que d'avis de fin de vie officiels.

C'est dans les lignes du bas que les choses se compliquent. La version 1.12.1 est restée la version active pendant cinq ans et c'est celle sur laquelle de nombreuses équipes se sont figées, mais beaucoup d'applications ne sont jamais allées aussi loin. La version 1.10.4 a été lancée en janvier 2014 et a cessé de recevoir des correctifs la même année ; ainsi, tout ce qui fonctionne encore avec cette version a passé plus d'une décennie sans correctif de sécurité en amont. Si votre application a été développée avant 2014 et que personne n’a délibérément mis à jour le front-end, c’est la première chose à vérifier.

Figure 2 : Écart de prise en charge entre les différentes versions.

Ce que signifie la fin de vie de jQuery UI pour vos applications

Une bibliothèque UI abandonnée présente des failles différentes de celles d'un environnement d'exécution serveur abandonné. Le code vulnérable s'exécute dans les navigateurs de vos utilisateurs, sur des pages avec lesquelles ils interagissent quotidiennement, et les vulnérabilités de jQuery UI évoquées ci-dessous relèvent toutes du « cross-site scripting » (XSS) et non d'un problème côté serveur.

Les CVE déjà répertoriées

Quatre failles XSS ont été corrigées dans la branche 1.13. Trois d'entre elles remontent jusqu'à la version 1.10.4. La quatrième ne concerne que la version 1.12.0 et les versions ultérieures, car le widget qu'elle cible n'existait pas avant cette version.

41182 et 41183 permet l'injection de scripts via le sélecteur de date altField option et son *Text options respectives. 41184 fait de même par le biais de la of option de la .position() utilitaire, auquel ont recours en arrière-plan des widgets tels que les infobulles et la saisie semi-automatique. Ces trois problèmes ont été corrigés dans la version 1.13.0 ; une installation de la version 1.10.4 contient donc chacun d'entre eux. Le quatrième, 31160, il s'agit d'une vulnérabilité XSS déclenchée par l'actualisation d'un widget « checkboxradio » comportant une étiquette de type HTML ; celle-ci a été corrigée dans la version 1.13.2. Ce widget ayant fait son apparition dans la version 1.12.0, le chemin d'exécution vulnérable n'existe pas dans les versions 1.10.4 ou 1.11.x. Il est toutefois utile de le savoir avant de recevoir votre prochain rapport d’analyse, car l’avis publié considère que toutes les versions antérieures à la 1.13.2 sont concernées sans limite inférieure ; un scanner signalera donc de toute façon cette vulnérabilité pour la version 1.10.4.

Il est intéressant de s'intéresser à la chronologie. Trois de ces quatre failles ont été corrigées dans la version 1.13.0 elle-même, celle qui a été publiée en même temps que l'annonce du passage en mode de maintenance, leurs avis de sécurité ayant été publiés quelques semaines plus tard. La quatrième a été corrigée neuf mois après le passage en mode de maintenance. Les failles de sécurité n'ont pas cessé d'apparaître lorsque le développement actif a pris fin. Ce qui a changé, c'est la période sur laquelle s'étendent les correctifs.

Figure 3 : Emplacement des CVE dans l'interface.

Ce qui n'est jamais rétroporté

La politique de maintenance ne couvre que la dernière version mineure. Lorsqu'une nouvelle faille apparaît dans le sélecteur de date ou la boîte de dialogue, elle est évaluée par rapport à la version 1.14.x ; si un correctif s'avère nécessaire, celui-ci est appliqué à cette version, mais aucune modification n'est apportée aux autres versions.

L'avis vous indiquera probablement que votre branche est concernée, car les avis relatifs à jQuery UI mentionnent les plages concernées sous la forme suivante : < 1.13.0 et < 1.13.2. Ce qui n'aura pas lieu, c'est un portage en arrière. Pour les équipes utilisant des versions figées, tout avis de sécurité futur qui concernera leur branche signalera une faille que personne en amont ne comblera.

Quand les cadres de conformité se font sentir

La logique d'audit est la même pour tout composant non maintenu, mais son application varie en fonction du référentiel auquel vous êtes soumis. La norme PCI DSS 4.x exige l’application de correctifs pour les vulnérabilités critiques dans un délai d’un mois à compter de leur publication, tandis que pour toutes les autres, elle s’appuie sur des délais basés sur les risques que vous définissez vous-même ; or, aucun de ces deux délais n’est facile à respecter par le biais de correctifs lorsqu’aucun correctif pris en charge n’existe. Si vos contrôles SOC 2 incluent la gestion des vulnérabilités, un composant non pris en charge rend plus difficile de démontrer que les risques identifiés sont réellement gérés dès lors qu’aucun correctif en amont n’est disponible ; c’est à ce moment-là que les auditeurs commencent à s’interroger sur l’efficacité réelle de votre processus de gestion des vulnérabilités. La règle de sécurité de l’HIPAA exige des entités réglementées qu’elles identifient les risques pesant sur les ePHI et les réduisent à un niveau raisonnable et approprié ; ainsi, une faille XSS connue et irréparable dans un portail destiné aux patients fait partie intégrante de cette analyse, que vous le vouliez ou non.

Les pratiques fédérales ont évolué récemment, et l’ancienne terminologie est désormais obsolète. La CISA a abrogé la directive BOD 22-01 en juin 2026 et l’a remplacée par la directive BOD 26-04, qui établit des délais de correction échelonnés pour les agences civiles fédérales en fonction de l’exposition des actifs, du statut KEV, de l’automatisation des exploits et de l’impact technique, les cas les plus graves devant être traités dans un délai pouvant aller jusqu’à trois jours seulement. FedRAMP s’aligne sur cette même approche fondée sur les risques, et ses règles relatives à la détection et à la réponse aux vulnérabilités deviendront obligatoires pour les fournisseurs de services cloud à compter du 7 décembre 2026, remplaçant ainsi le délai forfaitaire de 30 jours pour les vulnérabilités de haute gravité par une évaluation fondée sur les risques. Les fabricants de produits sont soumis à leur propre version de ces dispositions en vertu de la loi européenne sur la cyber-résilience (Cyber Resilience Act), dans le cadre de laquelle les obligations de signalement des vulnérabilités activement exploitées entreront en vigueur le 11 septembre 2026, les exigences complètes en matière de gestion des vulnérabilités prenant effet en décembre 2027.

Aucun de ces cadres ne transforme la mention « jQuery hérité détecté » en un constat automatique, car la portée, l'exposition et les contrôles compensatoires ont tous leur importance. Cependant, les scanners signalent rapidement les piles front-end héritées, et quel que soit le régime appliqué, ce signalement devient un travail que vous devez justifier.

Comment jQuery UI (en fin de vie) permet de conserver l'ancienne version de jQuery

L'arborescence des dépendances de jQuery UI est on ne peut plus simple. Dans le paquet npm actuel, jQuery est la seule dépendance d'exécution déclarée, fixée comme jquery >=1.12.0 <5.0.0. L'ancien code jQuery UI comportait effectivement une dépendance au niveau du composant vis-à-vis du plugin jQuery Mousewheel au sein du widget « spinner », dépendance qui a été supprimée dans la version 1.14.2 en janvier 2026 ; toutefois, celle-ci n'a jamais constitué une deuxième dépendance déclarée. Quoi qu'il en soit, il ne s'agit pas d'un composant intégré à un binaire d'exécution. jQuery se charge dans sa propre balise script, généralement la ligne située au-dessus de celle de jQuery UI, et la plupart des équipes peuvent identifier leur version de jQuery plus rapidement que celle de jQuery UI. Le risque ici n’est pas caché. Il s’agit d’un couplage.

Commençons par examiner les enjeux liés à cette dépendance visible. La vulnérabilité CVE-2020-11023, une faille XSS affectant toutes les versions de jQuery comprises entre 1.0.3 et 3.4.1, a été ajoutée au catalogue des vulnérabilités connues pour avoir été exploitées (Known Exploited Vulnerabilities) de la CISA en janvier 2025, après la découverte de preuves d’exploitation en milieu réel, avec une date limite fédérale de correction fixée au 13 février 2025. Sa vulnérabilité sœur, CVE-2020-11022, concerne la même famille de manipulations du DOM, tandis que CVE-2019-11358 ajoute une vulnérabilité de type « pollution de prototype » pour les versions antérieures à la 3.4.0. La vulnérabilité de type « pollution de prototype » a été corrigée dans la version 3.4.0 et les deux failles XSS dans la version 3.5.0 ; tout a donc été corrigé en amont depuis 2020.

Alors pourquoi, six ans plus tard, certains environnements utilisent-ils encore jQuery 1.x ou 2.x ? Pour certains d’entre eux, jQuery UI est l’un des éléments qui complique la transition. jQuery UI 1.10.4 a été publié en janvier 2014, soit plus de deux ans avant l’apparition de jQuery 3.0, et l’équipe du projet a par la suite décrit l’objectif principal de la version 1.13.0 comme étant « l’amélioration de la compatibilité avec les versions récentes de jQuery ». Une version aussi ancienne n’a pas pu être testée avec une version de jQuery qui n’existait pas encore ; par conséquent, la mise à niveau de jQuery au sein d’un déploiement 1.10 figé relève davantage d’un exercice de compatibilité que d’un simple changement de version. La mise à niveau de jQuery dépend de celle de jQuery UI, qui dépend elle-même d’une phase d’assurance qualité qui ne semble jamais arriver. Une bibliothèque de widgets en fin de vie ne masque pas le risque lié à jQuery. Elle peut contribuer à le maintenir en place.

Figure 4 : Comment une bibliothèque de widgets en fin de vie peut compliquer la mise à niveau de jQuery.

La prise en charge prolongée constitue un moyen de sortir de cette impasse sans obliger à effectuer de mise à niveau préalable, et TuxCare fournit déjà des correctifs de sécurité pour certaines versions de jQuery en fin de vie, de la version 1.8.2 à la version 3.4.1, ce qui permet à la couche jQuery de rester à jour exactement là où elle se trouve.

Vos options après la fin de vie de jQuery UI

Le choix de la voie à suivre dépend de la charge de travail que vous pouvez assumer actuellement au niveau du front-end. Si vous devez continuer à appliquer les correctifs sans modifier une interface qui fonctionne, la prolongation du support pour la couche jQuery vous permettra de gagner du temps. Si vous pouvez planifier une migration vers jQuery et une véritable phase d’assurance qualité, la mise à niveau vers la version 1.14.x constitue la solution la plus propre. Et si le front-end doit de toute façon être refait, intégrer la refonte de jQuery UI dans ce projet vous évitera de faire deux fois le même travail.

Gagnez du temps grâce à l'assistance prolongée

Le support à cycle de vie illimité ( ELS ) de TuxCare pour les versions de jQuery en fin de vie (EOL) garantit que la version que vous utilisez déjà reste mise à jour ; il existe d’ailleurs un package ELS correspondant pour jQuery UI 1.10.4. Les correctifs sont rétroportés vers cette version, testés par rapport au comportement existant, signés, couverts par un SLA et distribués via npm ; leur intégration se résume donc à une simple modification de la configuration des dépendances, sans nécessiter de migration de framework. TuxCare couvre également certaines versions du cœur de jQuery en fin de vie (EOL) ; ainsi, une équipe utilisant jQuery UI 1.10.4 avec une version de jQuery couverte peut gérer les deux couches sans avoir à migrer de framework d’un côté comme de l’autre. La matrice de support publique répertorie des versions spécifiques plutôt que des branches entières, et la version 1.10.4 est la version de jQuery UI actuellement documentée ; vérifiez donc que la vôtre y figure avant de planifier quoi que ce soit.

TuxCare intervient en tant que membre « Gold » de la Fondation OpenJS et partenaire stratégique du programme « Ecosystem Sustainability Program », le programme non exclusif mis en place par la Fondation pour mettre en relation ses projets avec des soutiens commerciaux pour les versions qu’elle ne maintient plus. Vous pouvez également consulter en temps réel les vulnérabilités et les correctifs dans le CVE Tracker de TuxCare.

L'objectif de la prise en charge prolongée n'est pas de vous obliger à rester indéfiniment sur une ancienne version. Elle vous libère de la pression liée aux délais, afin que la mise à niveau puisse avoir lieu selon votre calendrier et soit effectuée dans les règles de l'art.

Passer à la version 1.14.x

Rester sur la version mineure prise en charge est la solution la plus simple, même si, pour une application datant de l'époque de la version 1.10, le chemin à parcourir est bien plus long que ne le laisse supposer le numéro de version. La version 1.14 a cessé de prendre en charge les versions de jQuery allant de 1.7 à 1.11, de 2.0 à 2.1 et de 3.0 à 3.5, ce qui signifie concrètement toutes les versions sauf la dernière de chaque branche majeure de jQuery.

Cela crée un piège qui mérite d’être signalé. jQuery UI 1.14.x est toujours testé avec jQuery 1.12.4 et 2.2.4 ; par conséquent, un déploiement fonctionnant déjà sur l’une de ces versions ne nécessite pas de mise à niveau de jQuery pour passer à la version 1.14. Cela n’apporte d’ailleurs aucun gain en matière de sécurité, car ces deux versions sont antérieures à la 3.5.0 et comportent toujours le CVE répertorié par KEV. Il est tout à fait possible de se retrouver avec une version mineure prise en charge de jQuery UI tout en conservant une version vulnérable de jQuery.

Du côté de jQuery, la version 4.0.0, sortie en janvier 2026, ne prend plus en charge Internet Explorer 10 et les versions antérieures, tout en conservant IE 11 pour l'instant ; jQuery UI 1.14.2 a été testée avec cette version. Si vous restez sur la branche 3.x, une version récente telle que la 3.7.1 constitue un meilleur choix que la version minimale qui corrige justement les anciennes vulnérabilités (CVE).

La version 1.14 supprime également complètement la prise en charge d'Internet Explorer et d'Edge Legacy et désactive par défaut l'ancienne couche de compatibilité API 1.11, bien que le paramètre jQuery.uiBackCompat à true rétablit le comportement de la version 1.13 si vous avez besoin d’une transition en douceur. Si vous passez directement de la version 1.10.4, vous devrez également vous adapter aux changements majeurs apportés par les versions 1.11 et 1.12, notamment les modifications de l’API Button et la refonte de l’API des effets ; or, cette couche de compatibilité s’appuie sur l’API de la version 1.11 plutôt que sur le comportement complet de la version 1.10. Ces deux aspects sont importants précisément pour le type d’application d’entreprise interne où jQuery UI trouve encore sa place. Et le cycle de maintenance se poursuit après votre migration, puisque la version 1.14 n’est prise en charge que jusqu’à la sortie de la prochaine version mineure.

Migration hors de jQuery UI

Ces widgets ont des équivalents modernes. Les contrôles natifs tels que <input type="date"> Les cas les plus simples sont pris en charge, tandis que les bibliothèques de composants conçues pour React ou Vue, ou encore les composants web basés sur des normes, couvrent le reste. Si l’application doit de toute façon faire l’objet d’une refonte du front-end, intégrer la suppression de jQuery UI à ce projet est la bonne décision. En tant que réponse isolée à la fin de vie du produit, c’est généralement l’option la plus coûteuse parmi celles envisagées, car cela implique de reconstruire et de retester chaque interface interactive actuellement gérée par ces widgets.

Les risques liés à une mise à niveau précipitée

Une mise à jour de jQuery UI est un changement visible pour l'utilisateur, ce qui rend toute précipitation plus perceptible que dans le cas d'une mise à jour du backend. La migration vers jQuery 3.x peut modifier des comportements sur lesquels le code des années 2010 s'appuyait discrètement. Le balisage des widgets et la gestion des thèmes ont évolué d'une version à l'autre ; il est donc nécessaire de revoir les feuilles de style CSS personnalisées datant de l'époque de ThemeRoller. Et la vérification ne peut se limiter à l’exécution de tests unitaires. Elle implique de réaliser des tests de régression visuels et fonctionnels sur chaque page comportant un sélecteur de date, une boîte de dialogue, un accordéon ou une fonctionnalité de saisie semi-automatique, et ce sur tous les navigateurs que vos utilisateurs utilisent encore.

Les équipes qui condensent tout cela en un sprint d’urgence risquent de livrer directement aux utilisateurs des mises en page défectueuses et des formulaires qui ne fonctionnent pas correctement, puis de passer les semaines suivantes à traiter des tickets d’assistance et à publier des correctifs. La dette technique s’accumule insidieusement, car les solutions de contournement mises en place dans l’urgence deviennent ensuite des éléments que personne n’ose plus toucher. Les mises à jour des bibliothèques destinées aux utilisateurs récompensent la planification et pénalisent les délais serrés.

Sécurisez vos interfaces utilisateur héritées au-delà de leur fin de vie grâce à TuxCare

Depuis plus d'une décennie, TuxCare assure la mise à jour des logiciels open source utilisés en production par des milliers d'entreprises, grâce à un processus de correction qui associe la surveillance automatisée des CVE et le backporting à des tests et à une révision obligatoire par des experts. Pour une interface utilisateur « gelée », cela signifie que le code dont dépend encore votre entreprise continue de bénéficier de correctifs de sécurité sans que la réécriture de l'interface ne devienne une urgence.

Découvrez ELS pour jQuery, ou commencez par consulter le CVE Tracker pour voir quelles vulnérabilités ont déjà fait l'objet de correctifs.

Résumé

Nom de l'article

Fin de vie de jQuery UI et comment garantir la sécurité

Description

jQuery UI 1.10.4 n'est plus pris en charge depuis plus d'une décennie et comporte des failles XSS connues. Découvrez les risques associés et comment y remédier.

Auteur

Artem Karasev

Nom de l'éditeur

de TuxCare

Logo de l'éditeur