Knockout.js End of Life: Security Risks for DNN and .NET Teams

If your organization runs DNN (formerly DotNetNuke), legacy SharePoint SPAs, or any .NET CMS that shipped with Knockout.js baked in, you have a security problem that most teams aren't talking about. Knockout.js has effectively reached end of life. Known XSS vulnerabilities remain unpatched in widely deployed versions, there is no active security maintenance process, and the platforms that embedded it haven't done much to help you move forward.

This isn't a theoretical risk. DNN versions 9.0.0 through 9.10.2 shipped vulnerable versions of Knockout.js that were later flagged in a Tenable advisory. Microsoft deprecated its Knockout-based SharePoint Framework (SPFx) web part template in v1.10 and removed it entirely in v1.11. Oracle issued multiple Critical Patch Updates referencing Knockout.js CVEs across its product line.

The framework your platform chose for you is now a liability. Here's what you need to understand, and what your options actually look like.

‍

Is Knockout.js still maintained?

In short: barely. As we covered in Knockout.js Isn't Dead, It's Just Not Alive Either, Knockout.js exists in a state of framework limbo, technically installable but functionally without active support.

Knockout.js was created by Steve Sanderson, a Microsoft employee, as a lightweight MVVM library for building reactive UIs with declarative data binding. It peaked in the early 2010s, became a standard choice for .NET-adjacent web development, and was bundled directly into platforms like DNN and the SharePoint Framework Yeoman generator.

Today, the project's maintenance picture is bleak:

• The last release with meaningful feature work was 3.5.0 in February 2019.
• Version 3.5.1 followed in November 2019, fixing regression bugs from 3.5.0.
• Version 3.5.2 landed in March 2026 after a gap of over six years, addressing bug fixes and adding Trusted Types support. While any release is a positive sign, a single maintenance release after six years does not indicate an active security program. There is no published security policy, no vulnerability disclosure process, and no commitment to future releases.
• The broader TKO (Technical Knockout) monorepo, which was intended as the path forward to Knockout 4.0+, has seen sporadic commits but no stable release.
• Snyk has classified the package's maintenance status as Inactive based on its release cadence analysis.

The npm package still receives roughly 116,000 weekly downloads, a signal that production systems continue to depend on it. But download volume does not equal active maintenance, and there is no documented security response process, no CVE monitoring team, and no SLA for vulnerability remediation.

‍

Knockout.js security: known vulnerabilities and future risk

Two CVEs are formally cataloged against Knockout.js, both cross-site scripting (XSS) vulnerabilities:

CVE-2019-14862 is an XSS vulnerability affecting all versions prior to 3.5.0-beta. Element names in the attr binding are passed directly to the DOM via string concatenation without proper sanitization. An attacker who controls input rendered through Knockout's binding system can inject and execute arbitrary JavaScript in the user's browser. This CVE carries a CVSS 3.1 base score of 6.1 (Medium) and was referenced in Oracle Critical Patch Updates in July 2020, January 2021, and April 2022.

CVE-2019-14863 is a related XSS vulnerability affecting versions 1.0.0 through 3.4.2, stemming from insufficient sanitization of user-supplied data within the data binding engine.

For any team running Knockout.js versions earlier than 3.5.0 (which is the vast majority of DNN installations running version 9.10.2 or below), these vulnerabilities are present and unpatched in production.

Beyond the cataloged CVEs, the broader concern is what happens next. With no active security response team, any future vulnerabilities discovered in Knockout.js will have no upstream fix. Your team becomes solely responsible for identifying, triaging, and patching any new issues, or you accept the risk and hope for the best.

‍

Why DNN is the highest-risk platform

DNN (DotNetNuke) is the leading open-source CMS in the Microsoft ecosystem, powering over 750,000 websites globally. It ships Knockout.js as a built-in JavaScript library alongside jQuery, jQuery UI, and jQuery Migrate. The platform uses Knockout internally for portions of its administrative interface, and the DNN module development ecosystem has long relied on Knockout for client-side MVVM data binding.

This creates a uniquely difficult problem for DNN administrators:

You didn't choose Knockout.js. The platform chose it for you. Unlike a team that explicitly selected Knockout for a greenfield project, DNN sites inherit Knockout as a platform dependency. It's loaded via DNN's JavaScript Library framework, which manages deduplication and versioning of client-side scripts across modules. Removing it isn't a matter of updating a package.json file. It's embedded in the platform's admin interface and potentially in every third-party module installed on the site.

DNN's own security advisory confirmed the risk. DNN Platform versions 9.0.0 through 9.10.2 were flagged in a Tenable Nessus plugin (ID 165701) that specifically called out Knockout.js vulnerabilities alongside issues in jQuery, jQuery UI, log4net, and Newtonsoft.Json. The advisory noted that DNN 9.11.0 updated to the latest version of Knockout, but organizations running any prior version remain exposed.

DNN itself still runs on .NET Framework 4.8. While the platform continues to receive updates (version 10.2.x is current), DNN has not yet migrated to the cross-platform .NET runtime. This means DNN sites often exist within broader infrastructure that carries its own set of legacy and end-of-life dependencies. A Knockout.js vulnerability is rarely the only EOL component in a DNN environment.

Third-party DNN modules compound the exposure. The DNN ecosystem includes thousands of commercial and community modules, many of which were built during the peak Knockout.js era and depend on specific versions of the library. Updating Knockout at the platform level can break modules that rely on older API behavior, version-specific bindings, or undocumented internal features.

‍

Legacy SharePoint SPAs and the SPFx Knockout template

Microsoft's SharePoint Framework (SPFx) originally offered Knockout.js as a first-class template option in its Yeoman generator, making it easy for SharePoint developers to build client-side web parts using familiar MVVM patterns. Organizations that adopted this template during SPFx's early versions (v1.0 through v1.9) may still have Knockout-based web parts in production.

Microsoft deprecated the Knockout-based web part template in SPFx v1.10 (released January 2020), citing low usage, and removed it entirely in v1.11. The official SPFx documentation now lists React as the primary recommended framework, with "No JavaScript Framework" as the alternative. Knockout is still mentioned as a supported option in broader SPFx overview documentation, but there are no templates, no updated guidance, and no active samples.

For organizations with existing Knockout-based SharePoint web parts, the situation is similar to DNN: the web parts continue to function, but they rely on a library with no active security maintenance. SharePoint Online's content security policies and iframe sandboxing provide some mitigation, but on-premises SharePoint Server deployments (2016, 2019) lack these protections and may be running older versions of the web parts with older Knockout builds.

‍

Compliance and audit exposure

Running unsupported JavaScript libraries in production creates measurable compliance risk across multiple regulatory frameworks:

SOC 2 Type II audits evaluate the effectiveness of controls around vulnerability management and patch cadence. An unmaintained client-side library with known CVEs and no remediation path is a finding waiting to happen, particularly when it's embedded in an administrative interface (as with DNN) where privileged users interact with it regularly.

PCI DSS v4.0 requires organizations to identify and address vulnerabilities in a timely manner, including vulnerabilities in third-party and open-source components. Requirement 6.3.2 specifically calls for maintaining an inventory of bespoke and custom software and third-party software components incorporated into bespoke and custom software, along with a process for identifying known security vulnerabilities.

The EU Cyber Resilience Act (CRA), which entered into force in 2024, imposes obligations on manufacturers and developers to ensure that products with digital elements are designed and developed with security in mind throughout the product lifecycle. Organizations distributing software (including web applications) that incorporates unmaintained open-source components will face increasing scrutiny.

FedRAMP continuous monitoring requirements mandate that federal agencies and their vendors maintain current, supported software components. Knockout.js in a FedRAMP boundary is a Plan of Action and Milestones (POA&M) item at minimum, and potentially a finding that blocks authorization.

For organizations running DNN in regulated industries (government, healthcare, financial services, higher education), the combination of an unmaintained JavaScript library embedded in the CMS's administrative interface creates audit exposure that is both real and difficult to explain away.

‍

Knockout.js alternatives: migration path analysis

If you need to move off Knockout.js, the right alternative depends on your platform, your team's capabilities, and how much time you have before your next audit. Here are the three most viable Knockout.js alternatives for .NET and DNN teams, along with a realistic assessment of each.

Option 1: Migrate to React

React is the most natural successor to Knockout.js for teams that need a component-based UI framework with a large ecosystem and strong hiring market. It's the default recommendation from Microsoft for SPFx web parts, and it has extensive tooling support across the .NET ecosystem.

Best for: Teams building new SPFx web parts, organizations with JavaScript/TypeScript expertise, and projects where the existing Knockout.js usage is confined to isolated components that can be replaced incrementally.

Challenges: React's component model and unidirectional data flow are conceptually different from Knockout's two-way MVVM bindings. Teams accustomed to Knockout's declarative data-bind syntax and observable patterns will need to learn hooks, state management, and JSX. For DNN modules, React integration requires additional build tooling that DNN's traditional module development workflow doesn't natively support.

Timeline: 3 to 12 months per module or web part, depending on complexity. A simple data-display component might take a few weeks. A complex multi-step workflow with extensive observable chains and custom binding handlers could take several months.

Option 2: Migrate to Vue

Vue's reactivity system and template syntax are the closest modern analog to Knockout.js. Teams that valued Knockout's simplicity, two-way data binding, and HTML-template-driven approach will find Vue's learning curve significantly shorter than React's.

Best for: Teams that want the shortest migration path from Knockout.js patterns, organizations that need progressive adoption (Vue can be incrementally integrated alongside existing code), and DNN module developers who want to avoid heavyweight build tooling.

Challenges: Vue's ecosystem is smaller than React's, and Microsoft's official SPFx tooling doesn't provide Vue templates (though community solutions exist). For DNN, Vue integration is well-supported via CDN includes or npm builds, but the DNN marketplace and community have less Vue content compared to React or jQuery.

Timeline: 2 to 8 months per module. Vue's similarity to Knockout's patterns typically results in faster migration than React, particularly for data-binding-heavy interfaces.

Option 3: Migrate to Blazor (.NET native)

For organizations deeply invested in the .NET ecosystem, Blazor offers a path that keeps the entire stack in C# and .NET. Blazor Server renders UI on the server and uses SignalR for real-time updates. Blazor WebAssembly runs .NET code directly in the browser. Both eliminate the need for a separate JavaScript framework entirely.

Best for: Teams with strong C# skills and limited JavaScript expertise, organizations already planning a broader migration from .NET Framework to modern .NET (6+/8+), and projects where consolidating the technology stack is a strategic priority.

Challenges: Blazor requires modern .NET, which means DNN Platform (still on .NET Framework 4.8) cannot natively host Blazor components. Organizations would need to either migrate their CMS to a different platform or run Blazor components alongside DNN as separate services. Blazor WebAssembly also has larger initial payload sizes than lightweight JavaScript frameworks, which can affect page load performance.

Timeline: 6 to 18 months, factoring in the broader .NET modernization work required to support Blazor. This is rarely a Knockout-only migration; it's typically part of a larger platform shift.

The common problem with all three options

Every migration path requires engineering time, testing, and risk. For large DNN installations with dozens of modules, or SharePoint environments with multiple Knockout-based web parts deployed across site collections, a full migration is a multi-quarter (or multi-year) initiative. During that time, your existing Knockout.js code remains in production, continues to serve users, and continues to carry the unpatched vulnerability exposure described above.

This is the gap that Never-Ending Support is designed to fill.

‍

Option 4: Never-Ending Support for Knockout.js

HeroDevs Never-Ending Support (NES) for Knockout.js is a drop-in replacement for Knockout.js that provides ongoing security patches, CVE remediation, and compliance documentation for versions that the original project no longer maintains. NES covers Knockout.js versions 3.5.1, 3.4.2, and 2.3.0, the versions most commonly found in DNN, SharePoint, and legacy .NET CMS deployments.

Here's what NES provides:

Security patches with SLA-backed response times. When a vulnerability is discovered in Knockout.js, HeroDevs' security engineering team validates and remediates the issue, often before it's publicly announced. This is a fundamentally different security posture than relying on a dormant open-source project to respond. You can review the full list of CVEs addressed across all NES products in the HeroDevs vulnerability directory.

Compliance documentation for SOC 2, PCI DSS, FedRAMP, and HIPAA. NES subscriptions include the SLA and remediation commitments that auditors require. Instead of explaining why you're running an unmaintained library, you can demonstrate that the library is actively supported and patched.

Drop-in compatibility. NES for Knockout.js is designed to be a direct replacement, not a fork with breaking changes. For DNN deployments, this means swapping the library without modifying module code. For SPFx web parts, it means updating the package reference and rebuilding.

Time to migrate on your terms. NES isn't an alternative to migration; it's the safety net that lets you migrate on a realistic timeline instead of a panicked one. You get the security coverage you need today while your team plans and executes the migration that makes sense for your architecture.

For DNN administrators specifically, NES for Knockout.js can be combined with NES for jQuery to address the two most common client-side library vulnerabilities flagged in DNN security audits simultaneously.

‍

Taking action

If Knockout.js is running in your environment (and if you're on DNN, it almost certainly is), start with these steps:

Identify your exposure. Determine which version of Knockout.js is loaded in your application. In DNN, check the JavaScript Library extensions in the admin panel. For SPFx web parts, inspect your package.json or the bundled output. Any version below 3.5.0 is confirmed vulnerable to CVE-2019-14862 and CVE-2019-14863.

Assess your module and web part inventory. Catalog every DNN module or SharePoint web part that depends on Knockout.js, including third-party and commercial modules. This inventory is essential for both migration planning and NES deployment scoping.

Evaluate your compliance timeline. If your next SOC 2 audit, PCI assessment, or FedRAMP continuous monitoring review is within 6 months, a full migration is unlikely to be complete in time. NES provides the immediate coverage you need to pass the audit while migration proceeds in parallel.

Talk to HeroDevs. Contact our team to scope NES for Knockout.js for your environment, whether that's a single DNN installation or a fleet of .NET CMS sites across your organization. We'll help you understand the deployment process, timeline, and how NES fits alongside your migration roadmap.

Knockout.js served the .NET ecosystem well for over a decade. But in 2026, running it without active security support isn't a technical decision. It's a risk decision. Make sure your organization is making that decision deliberately, with the right information and the right options on the table.