Ist Knockout.js nicht mehr weiterentwickelt? Status, Risiken und wie man die Sicherheit gewährleistet

Wichtigste Erkenntnisse

• Knockout.js wurde nie offiziell als „End of Life“ erklärt. Das Projekt veröffentlichte im März 2026 zwei Wartungsversionen, v3.5.2 und v3.5.3, nachdem mehr als sechs Jahre lang keine neuen Versionen erschienen waren.
• „Nicht eingestellt“ ist nicht dasselbe wie „weiterhin unterstützt“. Es gibt kein LTS, kein Sicherheits-SLA, keinen veröffentlichten EOL-Zeitplan und keine veröffentlichte Richtlinie zur Offenlegung von Sicherheitslücken. Man kann keinen Patch-Rhythmus für ein Projekt planen, für das sich niemand jemals dazu verpflichtet hat.
• Die einzige gegen Knockout gemeldete CVE, CVE-2019-14862, ist eine XSS-Schwachstelle mittlerer Schwere, die in Version 3.5.0 behoben wurde. Der betroffene Codepfad wird nur im Internet Explorer 7 und älteren Versionen ausgeführt, sodass es sich bei einer modernen Browserflotte in erster Linie um ein Problem für Scanner, SBOM und Audits handelt und nicht um ein aktives Ausnutzungsrisiko.
• Mittlerweile gibt es eine weiterentwickelte Nachfolgeversion. TKO, die Knockout-4.x-Reihe, erreichte im April 2026 ihre erste stabile Version und enthält eine Knockout-kompatible Version, doch ihre Verbreitung ist im Vergleich zu Knockout 3.x nach wie vor verschwindend gering.
• Realistische Optionen: Herstellerunterstützung, selbstverwaltete Patches, Absicherung der bestehenden Umgebung oder eine schrittweise Migration. Eine komplette Neuprogrammierung ist selten der richtige erste Schritt.

Knockout.js befindet sich in einer heiklen Lage, die viele Teams überrascht. Es wurde zwar nie für tot erklärt, doch zwischen Ende 2019 und Anfang 2026 lag die Release-Aktivität fast vollständig auf Eis. Dann erschienen im März 2026 zwei neue Versionen im März 2026, ohne dass eine Roadmap oder Ankündigung dahinterstand. Wenn Sie eine DNN-Website (ehemals DotNetNuke) oder eine darauf aufbauende interne .NET-Anwendung betreiben, ist genau diese Mischung aus langem Schweigen und plötzlicher Aktivität das Problem: Sie sind von etwas abhängig, das Sie nicht vorhersagen können.

Dieser Artikel bietet Ihnen einen klaren Überblick über den aktuellen Stand von Knockout, die Versionshistorie, die Risiken, die für Produktionssysteme tatsächlich von Bedeutung sind, sowie praktische Lösungsansätze für die Zukunft. Um es gleich vorweg zu nehmen: Die Gefahr liegt hier nicht in einer dramatisch veralteten, ungepatchten Bibliothek. Es ist vielmehr die Kluft zwischen „noch installierbar“ und „vorhersehbar gepflegt“– und genau in dieser Lücke häufen sich die Ergebnisse von Sicherheitsüberprüfungen an und stellen Teams fest, dass sie keinen verlässlichen Weg zu einer Lösung haben.

Ist Knockout.js offiziell nicht mehr weiterentwickelt?

Nein, nicht offiziell. Knockout.js wurde nie offiziell für als „End of Life“, und die Versionen 3.5.2 und 3.5.3 wurden beide im März 2026 veröffentlicht. Die Unterstützung für „Trusted Types“ wurde mit Version 3.5.2 eingeführt und ist auch in Version 3.5.3, der aktuellen Version, enthalten. Die Darstellung von Knockout als vollständig aufgegeben entspricht nicht mehr der Release-Historie.

Viele von der Community gepflegte JavaScript-Projekte veröffentlichen überhaupt keine offizielle EOL-Mitteilung. Es gibt keinen kommerziellen Upstream-Anbieter und keinen Supportvertrag mit Ablaufdatum. Stattdessen kommt es zu einem langsamen Niedergang: weniger Git-Commits, eine wachsende Zahl offener Issues, längere Abstände zwischen den Releases. Knockout lässt sich am besten als „zeitweise gepflegt“ und nicht als „tot“ beschreiben.

Diese Unterscheidung ist entscheidend für die Art und Weise, wie Sie damit umgehen. Formal gesehen EOL-Software ein bekanntes Ablaufdatum, auf das man sich bei der Planung einstellen kann. Eine nur sporadisch gepflegte Bibliothek bietet kein solches Datum, was die Verwaltung erschwert statt erleichtert.

Realitätscheck: Knockout verzeichnete rund 158.000 npm-Downloads in der Woche bis zum 24. Juli 2026. Weit verbreitete Software ohne dokumentierte Verpflichtung zur Sicherheitsreaktion stellt ein schwer zu tragendes Risiko dar: Teams sind darauf angewiesen, aber niemand hat versprochen, wann oder ob eine Sicherheitslücke behoben wird.

Wichtige Meilensteine und Veröffentlichungsdaten von Knockout.js

Falls Sie auf der Suche nach einer übersichtlichen LTS-Tabelle mit EOL-Daten hierher gekommen sind, lautet die unbequeme Antwort: Knockout hat nie ein LTS-Modell verwendet und nie End-of-Life-Daten veröffentlicht. Alle unten aufgeführten Veröffentlichungsdaten wurden anhand der offiziellen Knockout-Download-Seite überprüft.

Der Verlauf dieser Zeitachse ist das eigentliche Thema. Zwischen Version 3.5.1 im November 2019 und Version 3.5.2 im März 2026 wurde nichts veröffentlicht – eine Lücke von mehr als sechs Jahren. Dann erschienen zwei Releases im selben Monat, und 3.5.2 wurde kaum zwei Wochen später auf npm als veraltet markiert, mit dem Hinweis, dass es grundlegende Änderungen enthielt, die in 3.5.3 behoben wurden. Zu diesen Regressionen gehörte, dass Bindungen vollständig versagten, wenn Knockout im Strict-Modus lief.

Zwei Veröffentlichungen nach einer sechsjährigen Pause lassen keinen vorhersehbaren Sicherheitsrhythmus erkennen. Das ist keine Kritik an den Betreuern, die eine lange Liste echter Fehler behoben haben. Es ist vielmehr eine Feststellung darüber, worauf sich Produktionsteams verlassen können: Es gibt keine veröffentlichte Zusage hinsichtlich einer Reaktionszeit, sodass es keine Grundlage für die Planung gibt.

Achtung: Aufgrund der sechsjährigen Lücke können Sie nicht davon ausgehen, dass der nächste Fix bald oder überhaupt erscheint. Behandeln Sie jeden Knockout-Sicherheitsbedarf als etwas, das Sie möglicherweise selbst beheben müssen.

Risiken bei der Verwendung einer nicht unterstützten Knockout.js-Version

Intermittierende Wartung ist kein Termin, den man immer wieder verschieben kann. Es handelt sich um einen Zustand, in dem man sich bereits befindet, und dieser prägt das Risikoprofil jedes Systems, in dem die Komponente läuft – unabhängig davon, ob man den Code in letzter Zeit bearbeitet hat oder nicht. Die folgenden Risiken sind diejenigen, die bei tatsächlichen Vorfällen und bei echten Audits auftreten.

Die einzige bekannte CVE und welche Auswirkungen sie tatsächlich hat

Gegen Knockout wurde eine CVE-Meldung eingereicht: CVE-2019-14862, eine Cross-Site-Scripting-Sicherheitslücke mittlerer Schwere mit einem CVSS 3.1-Basiswert von 6,1, die unter CWE-79 klassifiziert ist. Sie betrifft stabile Versionen bis einschließlich 3.4.2 und ist in 3.5.0 oder höher nicht vorhanden.

Es lohnt sich, diesen Mechanismus zu verstehen, da er Einfluss darauf hat, wie Sie damit umgehen sollten. Knockout behandelte das „name“-Attribut bei der „attr“-Bindung auf besondere Weise und übergab Elementnamen durch Zeichenfolgenverkettung an das DOM. Dieser Codepfad existiert lediglich als Workaround für Internet Explorer 6 und 7 und wird nur ausgeführt, wenn Knockout eine IE-Version 7 oder niedriger erkennt. Den Knockout-Entwicklern gelang es nicht, das Problem in einem modernen Browser zu reproduzieren, und der „Exploit-Prediction-Score“ der Sicherheitslücke liegt weiterhin unter einem Prozent.

Bei einer aktuellen Browser-Flotte liegt das tatsächliche Risiko also nahe Null. Die Kosten sind jedoch anderer Art: Bei jeder Software-Kompositionsanalyse, jeder SBOM-Erstellung und jedem Sicherheitsfragebogen für Kunden wird eine ungelöste Sicherheitsempfehlung für Ihre Version angezeigt, und „Unsere Nutzer verwenden Internet Explorer 7 nicht“ ist ein Argument für eine kompensierende Kontrollmaßnahme, das Sie vorbringen und dokumentieren müssen – und keine Korrektur, auf die Sie verweisen können. Die Sicherheitsempfehlung wurde außerdem in den „Critical Patch Updates“ von Oracle im Juli 2020, Januar 2021 und April 2022 erwähnt und von Red Hat nachverfolgt, sodass sie in vielen nachgelagerten Bestandsaufnahmen erscheint.

Eine Korrektur, die es wert ist, erwähnt zu werden, da sie im Umlauf ist: CVE-2019-14863 wird manchmal Knockout zugeschrieben. Es handelt sich dabei um einen AngularJS-Sicherheitshinweis bezüglich nicht bereinigter xlink:href-Attribute, der nichts mit Knockout zu tun hat. Knockout hat eine CVE, nicht zwei.

Ein Upgrade ist nach wie vor die richtige Entscheidung, sofern dies möglich ist. Das Hindernis ist selten technischer Natur: Knockout ist häufig in eine DNN-Installation oder eine herstellerseitig kontrollierte Single-Page-Anwendung eingebettet, die der Kunde nicht ohne Weiteres ändern kann, und es gab bisher keinen Druck von oben, diese Frage voranzutreiben.

Prüfungsergebnisse und ins Stocken geratene Sicherheitsüberprüfungen

Bei Compliance-Prüfungen geht es weniger darum, ob Ihr Frontend funktioniert, als vielmehr darum, ob Sie einen definierten Prozess zum Aufspüren und Beheben von Schwachstellen im Code von Drittanbietern nachweisen können. Die Einzelheiten unterscheiden sich je nach Framework, und es lohnt sich, hier genau zu sein. PCI DSS v4.0.1 ist am konkretesten: Es verlangt ein Inventar der Komponenten von Drittanbietern, Zeitpläne für Patches bekannter Schwachstellen und gemäß Anforderung 12.3.4 eine dokumentierte Überprüfung mit Freigabe durch die Geschäftsleitung für Software, für die keine Sicherheitspatches mehr bereitgestellt werden. Wenn Knockout einen Teil einer Zahlungsseite rendert, gelten zusätzlich die Anforderungen an das Skriptinventar und die Integrität. SOC 2 schreibt keine feste Kontrollliste vor; die Prüfer testen den Schwachstellenmanagement-Prozess, den Sie nach eigenen Angaben betreiben. Die HIPAA Sicherheitsregel basiert auf einer Risikoanalyse und ist nicht präskriptiv, und FedRAMP verlangt eine kontinuierliche Überwachung mit festgelegten Zeitfenstern für Abhilfemaßnahmen.

Nicht unterstützte Software führt nicht automatisch zum Scheitern einer dieser Prüfungen. Vielmehr wird dadurch ein Befund generiert, auf den Sie anschließend reagieren müssen, und eine Abhängigkeit ohne dokumentierten Sicherheitsreaktionsprozess lässt sich nur schwer rechtfertigen – selbst wenn derzeit keine Sicherheitslücke bekannt ist. Die gleiche Frage wird häufig von Kunden während des Beschaffungsprozesses gestellt, und genau dort kann ein nicht beantwortbarer Fragebogenpunkt einen Vertragsabschluss stillschweigend verzögern.

Genau diese Lücke sollen die von Anbietern bereitgestellten Patches für Open-Source-Komponenten schließen. Der „Endless Lifecycle Support“ von TuxCare für Knockout.js ist eine Option, auf die Teams zurückgreifen, wenn ein Upgrade nicht in Frage kommt.

Die umgebende Struktur birgt in der Regel ein höheres Risiko

Das veröffentlichte Knockout-Paket weist keine Laufzeitabhängigkeiten auf. Es handelt sich um eine eigenständige Bibliothek, die – anders als eine weitverzweigte Node- oder PHP-Anwendung – keinen tiefgreifenden transitiven Baum aufweist, in dem sich Sicherheitslücken verbergen könnten.

Das Risiko liegt darin, woran Knockout angebunden ist. In älteren Anwendungen wird es häufig zusammen mit jQuery 1.x, Bootstrap 3, RequireJS und einer veralteten DNN- oder SharePoint-Shell eingesetzt. Je nach den verwendeten Versionen können diese Komponenten ihre eigenen bekannten Schwachstellen und Wartungsaufwände mit sich bringen. Knockout wird dann zum Dreh- und Angelpunkt des gesamten Systems, da ein Upgrade oft bedeutet, dass auch alle umliegenden Komponenten angepasst werden müssen.

So wird aus einer nur zeitweise gepflegten Bibliothek eine bibliotheksweite Einschränkung.

Ihre Optionen, wenn Knockout.js keinen verlässlichen Support bietet

Sie haben vier realistische Vorgehensweisen. Drei davon sorgen dafür, dass Sie bei Knockout bleiben und werden hier behandelt; die vierte, eine schrittweise Migration, wird im folgenden Abschnitt behandelt. Die richtige Wahl hängt davon ab, inwieweit Sie die Anwendung ändern können und wie lange Sie sie am Laufen halten müssen. Keine dieser Optionen bedeutet „nichts tun“, denn Untätigkeit verlagert die Kosten lediglich auf Ihr nächstes Audit oder Ihren nächsten Vorfall.

Hersteller-Support erwerben

Die Frage ist hier, ob Sie Knockout sicher weiterbetreiben können, ohne den Anwendungscode zu verändern. Für die meisten Teams, die an ein Hersteller-CMS gebunden sind, ist dies möglich, und der vom Hersteller angebotene Support ist dabei der Weg mit dem geringsten Aufwand.

Unter „erweitertem Lebenszyklus-Support“ versteht man, dass ein Drittanbieter die Sicherheitspflege übernimmt, die das Upstream-Projekt nicht gewährleistet: Überwachung auf neue Sicherheitslücken, Backporting von Korrekturen und die Zusicherung einer vertraglich festgelegten Reaktionsfrist. Dadurch wird aus einer Komponente ohne Support-Verpflichtung eine Komponente, die Sie bei einem Audit nachweisen können.

Da Knockout keine Laufzeitabhängigkeiten deklariert, ist die Frage nach der Abdeckung einfacher als bei den meisten Bibliotheken. Der „Endless Lifecycle Support“ von TuxCare umfasst derzeit die Knockout.js-Versionen 2.3.0, 3.2.0 und 3.4.2 und stellt CVE-Korrekturen über npm aus von TuxCare gehosteten Repositories bereit. Wenn Sie die Anwendung nicht aktualisieren können und eine dokumentierte Quelle für Sicherheitskorrekturen benötigen, kann dies Ihr Risikomanagement und Ihre Compliance-Maßnahmen unterstützen, ohne dass eine sofortige Migration erforderlich ist.

Selbstverwaltete Patch-Verwaltung

Verfügen Sie über das erforderliche interne JavaScript-Sicherheits-Know-how, um diese Aufgabe zu übernehmen? Wenn ja, können Sie eine als fehlerfrei bekannte Version festlegen, auf neue Probleme achten und Korrekturen in Ihren eigenen Fork zurückportieren.

Der Nachteil dabei ist, dass Sie zum Betreuer werden. Das bedeutet, dass Sie das NVD, die GitHub Advisory Database, das Upstream-Repository sowie die Sicherheitshinweise von Downstream-Anbietern auf alles überwachen müssen, was Knockout oder die damit verbundenen Komponenten betrifft, anschließend Patches erstellen und testen und diese Kosten auf unbestimmte Zeit tragen müssen. Dies funktioniert gut für Teams mit fundierten Frontend-Sicherheitskenntnissen und einem kleinen, gut nachvollziehbaren Einsatzbereich.

Es funktioniert schlecht, wenn das Wissen nur im Kopf eines einzigen Entwicklers steckt. An dem Tag, an dem dieser das Unternehmen verlässt, wird Ihre gepflegte Fork still und leise zu einer weiteren ungepflegten Abhängigkeit.

An Ort und Stelle befestigen und sichern

Kann man den Explosionsradius so weit verringern, dass man Zeit gewinnt, während man einen echten Rückzug plant? Oftmals ja, und dies ist die am wenigsten genutzte Option.

In der Praxis: Sofern die Kompatibilität dies zulässt, sollten Sie auf die aktuelle Version 3.5.3 aktualisieren, die nicht von CVE-2019-14862 betroffen ist und die neuesten Korrekturen des Projekts enthält. Implementieren Sie anschließend eine restriktive Content Security Policy und ziehen Sie den Einsatz einer Webanwendungs-Firewall als zusätzliche Erkennungs- und Filterstufe in Betracht. Keine dieser Maßnahmen ersetzt das Patchen einer anfälligen Bibliothek, doch zusammen verringern sie die Angriffsfläche erheblich, während Sie entscheiden, wie es weitergehen soll.

Expertentipp: Die Unterstützung für „Trusted Types“ wurde mit Knockout 3.5.2 eingeführt und ist auch in 3.5.3 enthalten, wodurch für die internen Abläufe eine Richtlinie namens „knockout“ erstellt wird. Wenn Sie in Ihrer CSP die Einstellung „require-trusted-types-for ‚script‘“ festlegen, funktioniert Knockout automatisch damit – sollten Sie die „trusted-types“-Direktive jedoch auch als Zulassungsliste verwenden, müssen Sie Knockout darin aufnehmen. Andernfalls schlägt die Registrierung der Richtlinie ohne Fehlermeldung fehl, und die HTML-Verarbeitung von Knockout funktioniert bei Durchsetzung nicht mehr. „Trusted Types“ ist seit Februar 2026 browserübergreifend verfügbar; testen Sie daher auch mit älteren Browsern. Die Funktion verringert das Risiko von DOM-basierten XSS-Angriffen, beseitigt jedoch nicht jede Form von XSS.

Planung einer langfristigen Ausstiegsstrategie für Knockout.js

Hierbei handelt es sich um eine Planungsübung und nicht um eine Anleitung zur Migration. Das Ziel besteht darin, Entscheidungen in die richtige Reihenfolge zu bringen, und nicht darin, Migrationscode zu schreiben. Dies gilt für jeden Ansatz gleichermaßen: Vermeiden Sie eine unnötig umfangreiche „Big-Bang“-Neuprogrammierung, die das Lieferrisiko konzentriert und jede schrittweise Sicherheitsverbesserung hinter einem einzigen riesigen Meilenstein verzögert.

Wählen Sie das Ziel und das Interoperabilitätsmodell aus

Auf welches Framework stellen Sie um, und wie werden alter und neuer Code während der Umstellung nebeneinander bestehen? Es gibt zwei grundlegende Antworten, und die neuere davon sollten Sie sich genauer ansehen, bevor Sie sich für eine Neuprogrammierung entscheiden.

Die erste ist TKO, die offizielle Knockout-4.x-Reihe. Sie erreichte im April 2026 ihre erste stabile Version und veröffentlicht neben einem modularen, TSX-orientierten Build auch einen bewusst migrationsfreundlichen, Knockout-kompatiblen Build sowie einen dokumentierten Upgrade-Pfad von 3.x auf 4.x. Für ein Team, das beim Knockout-Programmiermodell bleiben möchte, ist dies der kürzeste Weg zu aktiv gepflegtem Code. Der Haken liegt in der Akzeptanz: Die Kompatibilitätsversion von TKO verzeichnet etwa hundert npm-Downloads pro Woche, während Knockout sechsstellige Zahlen erreicht. Testen Sie sie daher mit Ihrer eigenen Testsuite und behandeln Sie sie eher als kleines Projekt denn als etablierte Plattform.

Das zweite ist ein Mainstream-Framework. Knockout bindet sich an bestimmte DOM-Knoten, was hier von Vorteil ist: Oft lassen sich React-, Vue- oder Svelte-Komponenten in eine bestehende Knockout-Seite einbinden und alte und neue Komponenten nebeneinander ausführen, vorausgesetzt, jedes Framework verfügt über einen klar abgegrenzten Teil des DOM. Wählen Sie das Ziel anhand der vorhandenen Kompetenzen Ihres Teams und des Arbeitsmarktes aus, nicht anhand von Benchmarks. Die Interoperabilitätsgrenze, an der Knockout einen Teil des DOM an das neue Framework übergibt, muss sorgfältig gestaltet werden; eine unklare Grenze ist der Grund dafür, dass sich solche Migrationen über Monate hinziehen.

Sequenz mit dem Würgefeigenmuster

Beim „Strangler-Fig“-Ansatz werden ausgewählte Teile eines Systems schrittweise ersetzt – Route für Route oder Funktion für Funktion –, während die verbleibende Altanwendung weiterläuft. Beginnen Sie mit den Bereichen mit der höchsten Fluktuation oder dem höchsten Risiko: jenen, die Sie häufig nutzen oder die sensible Eingaben verarbeiten. Dadurch wird der Nutzen vorzeitig realisiert, da Sie die Risiken bei dem Code mindern, der sich am häufigsten ändert.

Seiten mit geringem Traffic und stabiler Leistung können am längsten auf Knockout verbleiben, und bei manchen lohnt sich eine Migration möglicherweise gar nicht.

Den Ausgang messen und erfassen

Legen Sie vor Beginn in Zahlen fest, was „fertig“ bedeutet: Prozentsatz der migrierten Bindungen, Anzahl der verbleibenden Knockout-abhängigen Routen, Bundle-Größe und CVE-Risiko im gesamten Frontend-Stack. Verwenden Sie Feature-Flags, um migrierte Teile über einen Schalter bereitzustellen, und führen Sie bei jedem Build einen Abhängigkeitsscanner durch, damit Sie beobachten können, wie die Anzahl der Risiken sinkt.

Profi-Tipp: Fügen Sie eine Knockout-Position in den Bericht Ihres Abhängigkeits-Scanners ein und stellen Sie diese im Monatsvergleich grafisch dar. Eine Migration, die angeblich gut verläuft, bei der die Knockout-Nutzung jedoch nie zurückgeht, verläuft nicht gut – und die Grafik macht es unmöglich, dies zu übersehen.

Sorgen Sie mit TuxCare für die Sicherheit Ihrer Knockout.js-Anwendungen

Knockout ist zwar nicht tot, aber die Planung eines Projekts ohne veröffentlichten Zeitplan und ohne Sicherheits-SLA birgt ein Risiko, dessen Ausmaß Sie nicht abschätzen können. Ganz gleich, ob Sie das System weiterbetreiben oder einen Ausstieg planen – die offene Frage bleibt, wer in der Zwischenzeit für die Sicherheitsmaßnahmen verantwortlich ist.

Falls Sie derzeit keine Umstellung vornehmen können, bietet der vom Anbieter bereitgestellte Support fortlaufende Sicherheitsupdates für Knockout.js sowie die Dokumentation, die ein Prüfer anfordern wird, ohne dass eine sofortige Migration erforderlich ist. Der „Endless Lifecycle Support“ von TuxCare umfasst die Knockout.js-Versionen 2.3.0, 3.2.0 und 3.4.2, wobei CVE-Korrekturen über npm bereitgestellt werden. Dies verschafft Ihnen Spielraum, die Umstellung nach Ihrem eigenen Zeitplan durchzuführen, anstatt mitten in einem Vorfall.

FAQs

Ist die Verwendung von Knockout.js im Jahr 2026 in der Produktion noch sicher?

Dies ist möglich, sobald die Anwendung geprüft und entsprechend abgesichert wurde. Version 3.5.3 ist aktuell und von CVE-2019-14862 nicht betroffen, allerdings veröffentlicht Knockout weder ein Sicherheits-SLA noch einen vorhersehbaren Release-Rhythmus. Behandeln Sie es daher als explizit verwaltete Abhängigkeit und nicht als Standardwahl für neue Entwicklungen.

Wie kann ich feststellen, welche Version von Knockout.js in meiner Anwendung verwendet wird?

Überprüfen Sie „ko.version“ in der Konsole Ihres Browsers oder führen Sie „npm ls knockout“ aus, falls es sich um eine npm-Abhängigkeit handelt. Bei gebündelten Plattformen wie DNN sollten Sie den Header der Knockout-Datei oder Ihr Paket-Manifest direkt überprüfen, da die Bibliothek häufig bereits in der Plattform enthalten ist und nicht separat installiert wird.

Werden moderne Browser die Unterstützung für Knockout.js einstellen?

Es gibt keine angekündigte Browser-Unterstützungsgrenze, und aktuelle Browser führen Knockout problemlos aus, da es sich um reines JavaScript handelt. Auf längere Sicht könnten Änderungen an Browser-APIs oder strengere Standard-Sicherheitsrichtlinien zu Kompatibilitätsproblemen bei älteren Anwendungen führen. Das kurzfristigere Risiko besteht darin, dass die Bibliothek und der dazugehörige Stack ohne Patches veralten, nicht darin, dass Browser die Unterstützung einstellen.

Kann Knockout.js während der Migration neben einem modernen Framework laufen?

In der Regel ja. Da Knockout an bestimmte DOM-Knoten gebunden ist, können Sie React-, Vue- oder Svelte-Komponenten daneben einbinden und jeweils eine Route oder Funktion nach der anderen migrieren, solange jedes Framework einen klar abgegrenzten Teil des DOM verwaltet.

Gibt es bei Knockout.js bekannte CVEs?

Erstens: CVE-2019-14862, eine Cross-Site-Scripting-Sicherheitslücke mittlerer Schwere, die stabile Versionen bis einschließlich 3.4.2 betrifft. Version 3.5.0 und höher sind nicht betroffen. CVE-2019-14863 wird gelegentlich Knockout zugeschrieben, es handelt sich jedoch um einen Sicherheitshinweis zu AngularJS.

Zusammenfassung

Artikel Name

Ist Knockout.js nicht mehr weiterentwickelt? Status, Risiken und wie man die Sicherheit gewährleistet

Beschreibung

Knockout.js wurde nie als „End of Life“ deklariert und im März 2026 wurden zwei neue Versionen veröffentlicht. Hier sind die tatsächlichen Risiken und vier Möglichkeiten, die Sicherheit zu gewährleisten.

Autor

Rohan Timalsina

Name des Herausgebers

TuxCare

Logo des Herausgebers