Knockout.js est-il en fin de vie ? Situation actuelle, risques et mesures de sécurité à prendre

Principaux enseignements

• Knockout.js n'a jamais été officiellement déclaré en fin de vie. Le projet a publié deux versions de maintenance, la v3.5.2 et la v3.5.3, en mars 2026, après plus de six ans sans aucune mise à jour.
• « Pas abandonné » ne signifie pas « pris en charge ». Il n'y a pas de version LTS, pas de SLA de sécurité, pas de calendrier de fin de vie publié, ni de politique de divulgation des vulnérabilités publiée. Vous ne pouvez pas planifier un calendrier de correctifs pour un projet qui ne s'est jamais engagé à en respecter un.
• La seule vulnérabilité CVE répertoriée pour Knockout, CVE-2019-14862, est une vulnérabilité XSS de gravité moyenne corrigée dans la version 3.5.0. Le chemin d'exécution de cette vulnérabilité ne fonctionne que sur Internet Explorer 7 et les versions antérieures ; par conséquent, sur un parc de navigateurs modernes, il s'agit avant tout d'un problème lié aux scanners, à la SBOM et à l'audit, plutôt que d'un risque d'exploitation active.
• Il existe désormais un successeur dont le développement est assuré. TKO, la gamme Knockout 4.x, a atteint sa première version stable en avril 2026 et propose une version compatible avec Knockout, mais son adoption reste négligeable par rapport à celle de Knockout 3.x.
• Options réalistes : assistance fournie par le fournisseur, application autonome des correctifs, renforcement de la sécurité sur place ou migration progressive. Une refonte radicale est rarement la bonne première étape.

Knockout.js se trouve dans une situation délicate qui prend beaucoup d’équipes au dépourvu. Il n’a jamais été déclaré obsolète, mais entre fin 2019 et début 2026, son développement était pratiquement au point mort. Puis deux nouvelles versions ont été publiées en mars 2026, sans aucune feuille de route ni annonce préalable. Si vous gérez un site DNN (anciennement DotNetNuke) ou une application .NET interne construite autour de celui-ci, ce mélange de long silence et d’activité soudaine est précisément le problème : vous dépendez de quelque chose que vous ne pouvez pas prévoir.

Cet article vous offre un aperçu clair de la situation actuelle de Knockout, de l’historique des versions, des risques réellement significatifs pour les systèmes de production, ainsi que des pistes concrètes pour aller de l’avant. Soyons francs dès le départ : le danger ici ne réside pas dans une bibliothèque non corrigée qui poserait un problème majeur. Il réside plutôt dans l’écart entre « toujours installable » et « dont la maintenance est prévisible », et c’est dans ce fossé que s’accumulent les constatations d’audit et que les équipes se rendent compte qu’elles ne disposent d’aucune voie fiable pour y remédier.

Knockout.js a-t-il officiellement atteint sa fin de vie ?

Non, pas officiellement. Knockout.js n'a jamais été officiellement déclaré en fin de vie, et les versions 3.5.2 et 3.5.3 ont toutes deux été publiées en mars 2026. La prise en charge de Trusted Types a été introduite dans la version 3.5.2 et se poursuit dans la version 3.5.3, qui est la version actuelle. Les affirmations selon lesquelles Knockout aurait été purement et simplement abandonné ne correspondent plus à son historique de versions.

De nombreux projets JavaScript gérés par la communauté ne publient jamais d'avis officiel de fin de vie. Il n'y a ni éditeur commercial en amont, ni contrat de support assorti d'une date d'expiration. On assiste plutôt à un déclin progressif : moins de commits Git, une pile croissante de tickets ouverts, des intervalles de plus en plus longs entre les versions. On peut dire que Knockout est davantage « maintenu de manière intermittente » que « mort ».

Cette distinction a son importance quant à la manière dont vous le traitez. D’un point de vue formel , un logiciel en fin de vie a une date de fin de vie connue qui vous permet de vous organiser en conséquence. Une bibliothèque dont la maintenance est intermittente ne vous fournit pas de date de ce type, ce qui rend la gestion plus difficile, et non plus facile.

Retour à la réalité : Knockout a enregistré environ 158 000 téléchargements npm au cours de la semaine se terminant le 24 juillet 2026. Un logiciel largement utilisé sans engagement documenté en matière de sécurité représente un risque difficile à assumer : les équipes en dépendent, mais personne n’a promis quand, ni même si, une vulnérabilité sera corrigée.

Principales étapes et dates de sortie des versions de Knockout.js

Si vous êtes venu ici à la recherche d'un tableau clair répertoriant les versions LTS avec leurs dates de fin de vie, voici la réponse décevante : Knockout n'a jamais adopté de modèle LTS et n'a jamais publié de dates de fin de vie. Toutes les dates de sortie mentionnées ci-dessous ont été vérifiées sur la page officielle de téléchargement de Knockout.

C'est la forme de cette chronologie qui est révélatrice. Aucune version n'a été publiée entre la 3.5.1, en novembre 2019, et la 3.5.2, en mars 2026, soit un écart de plus de six ans. Puis deux versions sont sorties le même mois, et la version 3.5.2 a été marquée comme obsolète sur npm à peine deux semaines plus tard, avec un avis indiquant qu’elle contenait des modifications incompatibles corrigées dans la version 3.5.3. Parmi ces régressions figuraient des liaisons qui échouaient complètement lorsque Knockout fonctionnait en mode strict.

Deux versions publiées après un intervalle de six ans ne permettent pas d'établir un rythme de sécurité prévisible. Il ne s'agit pas là d'une critique à l'égard des responsables de la maintenance, qui ont corrigé une longue liste de véritables bogues. C'est simplement un constat concernant ce sur quoi les équipes de production peuvent compter : aucun engagement n'ayant été publié concernant les délais de réponse, il n'y a donc aucun élément sur lequel s'appuyer pour planifier.

Attention : Compte tenu de ce délai de six ans, vous ne pouvez pas partir du principe que le prochain correctif sera disponible prochainement, ni même qu'il le sera un jour. Considérez tout problème de sécurité lié à Knockout comme un problème que vous devrez peut-être résoudre vous-même.

Risques liés à l'utilisation d'une version non prise en charge de Knockout.js

La maintenance intermittente n'est pas une échéance que l'on peut repousser indéfiniment. Il s'agit d'une situation dans laquelle vous vous trouvez déjà, et qui détermine le profil de risque de chaque système utilisant ce composant, que vous ayez ou non modifié le code récemment. Les risques énumérés ci-dessous sont ceux qui apparaissent dans des incidents réels et lors d'audits concrets.

La seule vulnérabilité CVE connue, et ce qu'elle affecte réellement

Un CVE a été enregistré concernant Knockout : CVE-2019-14862, une vulnérabilité de type « cross-site scripting » (XSS) de gravité moyenne, avec un score de base CVSS 3.1 de 6,1, classée sous le code CWE-79. Elle affecte les versions stables jusqu'à la version 3.4.2 et n'est pas présente dans la version 3.5.0 ou les versions ultérieures.

Il est important de bien comprendre ce mécanisme, car cela influe sur la manière dont vous devez réagir. Knockout traitait l'attribut « name » de manière particulière dans son binding « attr » et transmettait les noms d'éléments au DOM via une concaténation de chaînes de caractères. Ce chemin de code n'existe qu'à titre de solution de contournement pour Internet Explorer 6 et 7, et il ne s'exécute que lorsque Knockout détecte une version d'IE 7 ou antérieure. Les responsables de Knockout n'ont pas réussi à reproduire le problème dans un navigateur moderne, et le score de prévision d'exploitation de cette vulnérabilité est resté inférieur à 1 %.

Ainsi, sur un parc de navigateurs actuel, l’exposition pratique est proche de zéro. Le coût est d’une autre nature : chaque analyse de composition logicielle, chaque SBOM et chaque questionnaire de sécurité client fera apparaître un avis de sécurité non résolu concernant votre version, et « nos utilisateurs n’utilisent pas Internet Explorer 7 » est un argument de contrôle compensatoire que vous devez avancer et documenter, plutôt qu’un correctif que vous pouvez mettre en avant. Cet avis a également été mentionné dans les mises à jour de correctifs critiques d’Oracle de juillet 2020, janvier 2021 et avril 2022, et suivi par Red Hat ; il apparaît donc dans de nombreux inventaires en aval.

Une rectification qui mérite d'être signalée, car cette information circule : le CVE-2019-14863 est parfois attribué à Knockout. Il s'agit en réalité d'un avis de sécurité concernant AngularJS, portant sur des attributs xlink:href non validés, et qui n'a aucun rapport avec Knockout. Knockout ne compte qu'un seul CVE, et non deux.

La mise à niveau reste la bonne solution lorsque cela est possible. L'obstacle est rarement d'ordre technique : Knockout est souvent intégré à une installation DNN ou à une application monopage contrôlée par un fournisseur que le client ne peut pas modifier facilement, et aucune pression en amont n'a jamais poussé à régler cette question.

Constatations d'audit et examens de sécurité au point mort

Les évaluations de conformité s'intéressent moins au bon fonctionnement de votre interface utilisateur qu'à votre capacité à démontrer l'existence d'un processus défini permettant d'identifier et de corriger les vulnérabilités présentes dans le code tiers. Les détails varient selon le framework, et il est important d'être précis à ce sujet. La norme PCI DSS v4.0.1 est la norme la plus concrète : elle exige un inventaire des composants tiers, des calendriers de correction pour les vulnérabilités connues et, en vertu de l’exigence 12.3.4, un examen documenté et validé par la direction pour les logiciels ne bénéficiant plus de correctifs de sécurité. Si Knockout affiche une partie quelconque d’une page de paiement, les exigences relatives à l’inventaire et à l’intégrité des scripts s’appliquent en plus de cela. La norme SOC 2 ne prescrit aucune liste de contrôles fixe ; les auditeurs testent le processus de gestion des vulnérabilités que vous déclarez mettre en œuvre. La règle de sécurité HIPAA repose sur une analyse des risques plutôt que sur des prescriptions, et FedRAMP exige une surveillance continue avec des délais de correction définis.

Un logiciel non pris en charge n'entraîne pas automatiquement l'échec à l'une de ces étapes. Cela génère simplement une remarque à laquelle vous devrez répondre, et une dépendance pour laquelle aucun processus de réponse en matière de sécurité n'est documenté est difficile à justifier, même si aucune vulnérabilité n'y est actuellement associée. La même question revient souvent de la part des clients lors de la phase d'approvisionnement, et c'est là qu'une question du questionnaire à laquelle il est impossible de répondre peut discrètement bloquer la conclusion d'un contrat.

C'est précisément ce genre de lacune que les correctifs fournis par les éditeurs pour les composants open source sont destinés à combler. Le support à cycle de vie illimité de TuxCare pour Knockout.js est l’une des solutions vers lesquelles les équipes se tournent lorsqu’une mise à niveau n’est pas envisageable.

L'environnement environnant comporte généralement davantage de risques

Le package Knockout publié ne déclare aucune dépendance d'exécution. Il s'agit d'une bibliothèque autonome ; ainsi, contrairement à une application Node ou PHP tentaculaire, elle ne comporte pas d'arborescence transitive complexe susceptible de dissimuler des vulnérabilités.

Le risque réside dans les composants auxquels Knockout est associé. Dans les applications plus anciennes, il coexiste généralement avec jQuery 1.x, Bootstrap 3, RequireJS et une instance vieillissante de DNN ou de SharePoint. Selon les versions utilisées, ces composants peuvent présenter leurs propres failles de sécurité connues et leurs propres contraintes de maintenance. Knockout devient alors le pivot qui maintient l'ensemble en place, car sa mise à niveau implique souvent de modifier tout ce qui l'entoure.

C'est ainsi qu'une bibliothèque gérée de manière intermittente finit par constituer une contrainte à l'échelle de toute la pile.

Vos options lorsque Knockout.js ne bénéficie pas d'un soutien prévisible

Vous disposez de quatre options réalistes. Trois d’entre elles vous permettent de rester sur Knockout et sont abordées ici ; la quatrième, une migration par étapes, fait l’objet de la section suivante. Le choix approprié dépend de votre capacité à modifier l’application et de la durée pendant laquelle vous devez la maintenir en service. Aucune de ces options ne consiste à « ne rien faire », car l’inaction ne ferait que reporter le coût à votre prochain audit ou à votre prochain incident.

Acheter une assistance assurée par le fournisseur

La question qui se pose ici est de savoir s'il est possible de faire fonctionner Knockout en toute sécurité sans modifier le code de l'application. Pour la plupart des équipes qui dépendent d'un CMS tiers, c'est tout à fait possible, et le support fourni par le fournisseur constitue la solution la plus simple.

Le support à cycle de vie prolongé signifie qu’un tiers prend en charge la maintenance de sécurité que le projet en amont ne garantit pas : surveillance des nouvelles vulnérabilités, portage des correctifs et engagement contractuel quant aux délais de réponse. Cela permet de transformer un composant ne bénéficiant d’aucun engagement de support en un élément que vous pouvez justifier lors d’un audit.

Comme Knockout ne déclare aucune dépendance d'exécution, la question de la couverture est plus simple que pour la plupart des bibliothèques. Le support à vie de TuxCare couvre actuellement les versions 2.3.0, 3.2.0 et 3.4.2 de Knockout.js, en fournissant des correctifs CVE via npm à partir des dépôts hébergés par TuxCare. Si vous ne pouvez pas mettre à niveau votre application et que vous avez besoin d’une source documentée de correctifs de sécurité, ce service peut vous aider dans vos efforts de gestion des risques et de conformité sans nécessiter de migration immédiate.

Application autonome des correctifs

Disposez-vous en interne de l'expertise nécessaire en matière de sécurité JavaScript pour prendre en charge ce projet ? Si tel est le cas, vous pouvez verrouiller une version dont la fiabilité est avérée, surveiller l'apparition de nouveaux problèmes et réintégrer les correctifs dans votre propre fork.

En contrepartie, c'est vous qui devenez le responsable de la maintenance. Cela implique de surveiller le NVD, la base de données des avis de sécurité de GitHub, le dépôt en amont et les avis des fournisseurs en aval pour tout ce qui concerne Knockout ou les composants qui l'entourent, puis de rédiger et de tester des correctifs, et d'assumer ce coût indéfiniment. Cette approche fonctionne bien pour les équipes disposant de solides compétences en sécurité front-end et dont l'empreinte est réduite et bien maîtrisée.

Cela ne fonctionne pas bien lorsque les connaissances sont cantonnées dans l'esprit d'un seul ingénieur. Le jour où celui-ci part, votre fork maintenu devient discrètement une dépendance de plus qui n'est plus entretenue.

Consolider et maintenir en place

Est-il possible de réduire suffisamment le rayon d'explosion pour gagner du temps tout en préparant une véritable fuite ? Souvent oui, et c'est l'option la plus sous-utilisée.

Concrètement : lorsque la compatibilité le permet, effectuez la mise à jour vers la version 3.5.3, la version actuelle, qui n’est pas affectée par la vulnérabilité CVE-2019-14862 et intègre les derniers correctifs du projet. Mettez ensuite en place une politique de sécurité du contenu (CSP) restrictive, et envisagez l’utilisation d’un pare-feu d’application web comme couche supplémentaire de détection et de filtrage. Aucune de ces mesures ne remplace l’application d’un correctif à une bibliothèque vulnérable, mais, combinées, elles réduisent considérablement la surface d’attaque pendant que vous décidez de la suite à donner.

Conseil d'expert : La prise en charge de Trusted Types a été introduite dans Knockout 3.5.2 et se poursuit dans la version 3.5.3, qui crée une politique nommée « knockout » pour ses opérations internes. Si vous définissez « require-trusted-types-for ‘script’ » dans votre CSP, Knockout s’y adapte automatiquement — mais si vous utilisez également la directive « trusted-types » comme liste blanche, veillez à y inclure Knockout. Sinon, la politique échouera silencieusement lors de son enregistrement, et le traitement HTML de Knockout ne fonctionnera plus correctement lors de son application. La fonctionnalité « Trusted Types » est compatible avec tous les navigateurs depuis février 2026 ; veillez donc à la tester sur des clients plus anciens. Elle réduit l’exposition aux attaques XSS basées sur le DOM, mais n’élimine pas toutes les formes d’attaques XSS.

Élaborer une stratégie de sortie à long terme pour Knockout.js

Il s'agit ici d'un exercice de planification, et non d'un tutoriel sur la migration. L'objectif est d'organiser les décisions dans l'ordre plutôt que d'écrire du code de migration, et cela vaut pour toutes les approches : il faut éviter une refonte radicale et inutilement importante, qui concentre les risques liés à la mise en production et retarde toutes les améliorations progressives en matière de sécurité derrière une seule étape décisive.

Choisissez la cible et le modèle d'interopérabilité

Vers quel framework allez-vous migrer, et comment l'ancien et le nouveau code vont-ils coexister pendant la transition ? Il existe deux grandes réponses à cette question, et la plus récente mérite qu'on s'y attarde avant de se lancer dans une réécriture.

La première est TKO, la branche officielle de Knockout 4.x. Elle a atteint sa première version stable en avril 2026 et propose une version compatible avec Knockout, spécialement conçue pour faciliter la migration, ainsi qu’une version modulaire orientée TSX, sans oublier une feuille de route documentée pour la mise à niveau de la version 3.x vers la 4.x. Pour une équipe souhaitant rester dans le modèle de programmation Knockout, c’est la voie la plus directe vers un code activement maintenu. La mise en garde concerne son adoption : la version compatible de TKO n’enregistre qu’une centaine de téléchargements npm par semaine, contre plusieurs centaines de milliers pour Knockout ; il convient donc de la valider à l’aide de votre propre suite de tests et de la considérer comme un petit projet plutôt que comme une plateforme établie.

Le second est un framework grand public. Knockout se lie à des nœuds DOM spécifiques, ce qui est un avantage dans ce cas : vous pouvez souvent intégrer des composants React, Vue ou Svelte au sein d’une page Knockout existante et faire fonctionner l’ancien et le nouveau côte à côte, à condition que chaque framework dispose d’une partie clairement délimitée du DOM. Choisissez la cible en fonction des compétences existantes de votre équipe et du marché de l’emploi, et non en fonction de benchmarks. La frontière d’interopérabilité, là où Knockout transfère une partie du DOM au nouveau framework, est l’élément qu’il faut concevoir avec soin ; c’est une frontière mal définie qui fait que ces migrations s’enlisent pendant des mois.

Séquence reprenant le motif du figuier étrangleur

Le modèle « strangler-fig » remplace progressivement certaines parties d’un système, étape par étape ou fonctionnalité par fonctionnalité, tandis que le reste de l’application existante continue de fonctionner. Commencez par les segments présentant le taux de rotation le plus élevé ou le risque le plus important : ceux que vous modifiez souvent, ou ceux qui traitent des données sensibles. Cela permet d’optimiser la valeur dès le départ, car vous réduisez les risques liés au code qui change le plus souvent.

Les écrans peu fréquentés et stables peuvent rester sur Knockout plus longtemps, et certains ne mériteront peut-être jamais d'être migrés.

Mettre en place un dispositif et mesurer le débit de sortie

Définissez clairement les critères de réussite avant de commencer : pourcentage de liaisons migrées, nombre de routes dépendantes de Knockout restantes, taille du bundle et exposition aux vulnérabilités CVE dans l’ensemble de la pile front-end. Utilisez des indicateurs de fonctionnalité pour déployer les parties migrées via un commutateur, et lancez un analyseur de dépendances à chaque build afin de pouvoir observer la diminution du nombre de risques.

Conseil de pro : Ajoutez une ligne « Knockout » dans le rapport de votre outil d’analyse des dépendances et représentez-la sous forme de graphique mois après mois. Une migration qui semble bien se dérouler mais dont l’utilisation de Knockout ne diminue jamais ne se passe pas bien, et le graphique rend cela impossible à ignorer.

Assurez la sécurité de vos applications Knockout.js avec TuxCare

Knockout n'est pas mort, mais planifier un projet sans calendrier publié ni SLA de sécurité vous expose à un risque dont vous ne pouvez pas évaluer l'ampleur. Que vous continuiez à l'exploiter ou que vous prévoyiez de vous en affranchir, la question qui reste en suspens est de savoir qui est responsable de la réponse en matière de sécurité en attendant.

Si vous ne pouvez pas procéder à la refonte dès maintenant, l'assistance fournie par l'éditeur peut vous apporter les correctifs de sécurité continus pour Knockout.js ainsi que la documentation qu'un auditeur vous demandera, sans vous obliger à effectuer une migration immédiate. Le support « Endless Lifecycle » de TuxCare couvre les versions 2.3.0, 3.2.0 et 3.4.2 de Knockout.js, avec des correctifs CVE fournis via npm, ce qui vous laisse le temps de migrer selon votre propre calendrier plutôt qu’en plein milieu d’un incident.

FAQ

Peut-on encore utiliser Knockout.js en production en toute sécurité en 2026 ?

Cela est possible, une fois que l'application a été évaluée et sécurisée de manière appropriée. La version 3.5.3 est la version actuelle et n'est pas concernée par la vulnérabilité CVE-2019-14862, mais Knockout ne publie ni accord de niveau de service (SLA) en matière de sécurité, ni calendrier de publication prévisible. Il convient de la considérer comme une dépendance gérée de manière explicite plutôt que comme un choix par défaut pour les nouveaux développements.

Comment puis-je savoir quelle version de Knockout.js est utilisée par mon application ?

Vérifiez la version de ko.version dans la console de votre navigateur, ou exécutez la commande « npm ls knockout » s'il s'agit d'une dépendance npm. Pour les plateformes intégrées telles que DNN, examinez directement l'en-tête du fichier Knockout ou le manifeste de votre package, car la bibliothèque est souvent fournie avec la plateforme plutôt qu'installée séparément.

Les navigateurs modernes vont-ils cesser de prendre en charge Knockout.js ?

Aucune date limite de prise en charge des navigateurs n'a été annoncée, et les navigateurs actuels exécutent Knockout sans problème, puisqu'il s'agit de JavaScript pur. À plus long terme, des modifications apportées aux API des navigateurs ou des politiques de sécurité par défaut plus strictes pourraient entraîner des problèmes de compatibilité pour les anciennes applications. Le risque à court terme réside davantage dans le vieillissement de la bibliothèque et de la pile qui l'entoure, en l'absence de correctifs, que dans l'abandon de la prise en charge par les navigateurs.

Knockout.js peut-il coexister avec un framework moderne pendant la migration ?

En général, oui. Étant donné que Knockout se lie à des nœuds DOM spécifiques, vous pouvez intégrer des composants React, Vue ou Svelte à côté de lui et migrer une route ou une fonctionnalité à la fois, à condition que chaque framework gère une partie clairement distincte du DOM.

Existe-t-il des vulnérabilités CVE connues pour Knockout.js ?

Premièrement : CVE-2019-14862, une vulnérabilité de type « cross-site scripting » (XSS) de gravité moyenne affectant les versions stables jusqu'à la version 3.4.2. La version 3.5.0 et les versions ultérieures ne sont pas concernées. La vulnérabilité CVE-2019-14863 est parfois attribuée à Knockout, mais il s'agit en réalité d'un avis de sécurité concernant AngularJS.

Résumé

Nom de l'article

Knockout.js est-il en fin de vie ? Situation actuelle, risques et mesures de sécurité à prendre

Description

Knockout.js n'a jamais été déclaré en fin de vie, et deux versions ont été publiées en mars 2026. Voici les risques réels et quatre moyens d'assurer sa sécurité.

Auteur

Rohan Timalsina

Nom de l'éditeur

de TuxCare

Logo de l'éditeur