Soporte técnico
Documentación
Inicio de sesión
Contáctenos
Ir directamente al resumen generado por IA de esta entrada del blog 
Principales conclusiones
- Nunca se ha anunciado oficialmente el fin de la vida útil de Knockout.js. El proyecto lanzó dos versiones de mantenimiento, la v3.5.2 y la v3.5.3, en marzo de 2026, tras más de seis años sin ninguna.
- «No está muerto» no es lo mismo que «recibe soporte». No hay LTS, ni SLA de seguridad, ni calendario de fin de vida útil publicado, ni política de divulgación de vulnerabilidades publicada. No se puede planificar una periodicidad de parches en torno a un proyecto que nunca se ha comprometido a seguir una.
- El único CVE registrado contra Knockout, el CVE-2019-14862, es una vulnerabilidad XSS de gravedad media que se corrigió en la versión 3.5.0. Su ruta de código vulnerable solo se ejecuta en Internet Explorer 7 y versiones anteriores, por lo que, en un entorno con navegadores modernos, se trata principalmente de un problema para los escáneres, el SBOM y las auditorías, más que de un riesgo de explotación activa.
- Actualmente existe un sucesor que recibe mantenimiento. TKO, la línea Knockout 4.x, alcanzó su primera versión estable en abril de 2026 e incluye una versión compatible con Knockout, pero su adopción sigue siendo insignificante en comparación con la de Knockout 3.x.
- Opciones realistas: soporte técnico proporcionado por el proveedor, aplicación autónoma de parches, refuerzo de la seguridad in situ o una migración por fases. Una reescritura radical rara vez es la primera medida adecuada.
Knockout.js se encuentra en una situación delicada que pilla desprevenidos a muchos equipos. Nunca se ha declarado su fin, pero entre finales de 2019 y principios de 2026 su actividad de lanzamiento estuvo prácticamente inactiva. Entonces se lanzaron dos nuevas versiones en marzo de 2026, sin que hubiera ninguna hoja de ruta ni anuncio que las precediera. Si gestionas un sitio web de DNN (antes DotNetNuke) o una aplicación interna de .NET basada en él, esa combinación de largo silencio y actividad repentina es precisamente el problema: dependes de algo que no puedes predecir.
Este artículo te ofrece una visión clara del estado actual de Knockout, la cronología de versiones, los riesgos que realmente importan para los sistemas de producción y las vías prácticas a seguir. La verdad sin rodeos: el peligro aquí no radica en una biblioteca sin parches que suponga un problema grave. Se trata de la diferencia entre «aún instalable» y «con un mantenimiento predecible», y es en esa brecha donde se acumulan los hallazgos de las auditorías y donde los equipos descubren que no disponen de una vía fiable para aplicar una solución.
¿Se ha llegado oficialmente al fin de la vida útil de Knockout.js?
No, no oficialmente. Knockout.js nunca se ha declarado oficialmente como obsoleto, y las versiones 3.5.2 y 3.5.3 se lanzaron ambas en marzo de 2026. La compatibilidad con Trusted Types se incorporó en la versión 3.5.2 y se mantiene en la 3.5.3, que es la versión actual. Las afirmaciones de que Knockout ha sido abandonado por completo ya no se corresponden con su historial de lanzamientos.
Muchos proyectos de JavaScript mantenidos por la comunidad nunca publican un aviso formal de fin de vida útil. No hay ningún proveedor comercial «upstream» ni ningún contrato de soporte con fecha de vencimiento. Lo que se observa, en cambio, es un declive gradual: menos commits en Git, una pila cada vez mayor de incidencias pendientes y intervalos más largos entre lanzamientos. Knockout se puede describir mejor como un proyecto con mantenimiento intermitente que como uno abandonado.
Esta distinción es importante a la hora de tratarlo. Formalmente El software al final de su ciclo de vida (EOL) tiene una fecha límite conocida con la que puedes planificar. Una biblioteca que se mantiene de forma intermitente no te ofrece esa fecha, lo que dificulta su gestión, en lugar de facilitarla.
La realidad: Knockout registró aproximadamente 158 000 descargas en npm en la semana que finalizó el 24 de julio de 2026. Un software ampliamente utilizado sin un compromiso documentado de respuesta ante incidencias de seguridad supone un riesgo difícil de asumir: los equipos dependen de él, pero nadie ha prometido cuándo, o si, se solucionará una vulnerabilidad.
Hitos clave y fechas de lanzamiento de Knockout.js
Si has venido aquí buscando una tabla clara sobre las versiones LTS con fechas de fin de vida útil, esta es la respuesta, por muy incómoda que sea: Knockout nunca ha utilizado un modelo LTS y nunca ha publicado fechas de fin de vida útil. Todas las fechas de lanzamiento que aparecen a continuación se han comprobado en la página oficial de descargas de Knockout.
| Versión | Fecha de publicación | Estado de la asistencia y notas |
| 1.0.0 | Julio 5, 2010 | Primera versión pública. No se ha declarado el fin de vida útil. |
| 2.3.0 | Julio 9, 2013 | Versión final 2.x. No se ha declarado el fin de vida útil (EOL). Cubierta por el servicio ELS de TuxCare. |
| 3.0.0 | Octubre 25, 2013 | Versión principal. No se ha declarado el fin de vida útil. |
| 3.2.0 | Agosto 12, 2014 | Afectado por CVE-2019-14862. No se ha declarado el fin de vida útil (EOL). Cubierto por TuxCare ELS. |
| 3.4.2 | Marzo 6, 2017 | Última versión estable afectada por CVE-2019-14862. Cubierta por TuxCare ELS. |
| 3.5.0 | Febrero 21, 2019 | Primera versión estable no afectada por CVE-2019-14862. |
| 3.5.1 | Noviembre 5, 2019 | Último lanzamiento antes de la pausa de seis años. |
| 3.5.2 | Marzo 8, 2026 | Se ha añadido compatibilidad con «Trusted Types». Esta versión ha quedado obsoleta en npm, en favor de la 3.5.3. |
| 3.5.3 | Marzo 24, 2026 | Versión actual. No se ha declarado el fin de vida útil. |
La forma de esa línea temporal es lo realmente relevante. No se lanzó nada entre la versión 3.5.1, en noviembre de 2019, y la 3.5.2, en marzo de 2026, lo que supone un intervalo de más de seis años. Posteriormente, se lanzaron dos versiones en el mismo mes, y la 3.5.2 quedó obsoleta en npm apenas dos semanas después, con un aviso en el que se indicaba que contenía cambios incompatibles que se habían corregido en la 3.5.3. Entre esos problemas se encontraban los enlaces que fallaban por completo cuando Knockout se ejecutaba en modo estricto.
Dos lanzamientos tras un parón de seis años no establecen una periodicidad predecible en materia de seguridad. Esto no es una crítica a los responsables del mantenimiento, que han corregido una larga lista de errores reales. Es una constatación sobre aquello en lo que pueden confiar los equipos de producción: no existe ningún compromiso publicado respecto al tiempo de respuesta, por lo que no hay nada en lo que basar la planificación.
Atención: El intervalo de seis años significa que no puedes dar por hecho que la próxima corrección vaya a llegar pronto, ni siquiera que vaya a llegar. Trata cualquier problema de seguridad relacionado con Knockout como algo que quizá tengas que resolver por tu cuenta.
Riesgos de utilizar una versión de Knockout.js sin soporte técnico
El mantenimiento intermitente no es un plazo que se pueda ir posponiendo indefinidamente. Es una situación en la que ya te encuentras y que determina el perfil de riesgo de todos los sistemas que ejecutan ese componente, independientemente de si has modificado el código recientemente o no. Los riesgos que se enumeran a continuación son los que se observan en incidentes y auditorías reales.
La única vulnerabilidad CVE conocida y a qué afecta realmente
Se ha registrado un CVE relacionado con Knockout: CVE-2019-14862, un problema de cross-site scripting de gravedad media con una puntuación base CVSS 3.1 de 6,1, clasificado bajo CWE-79. Afecta a las versiones estables hasta la 3.4.2 y no está presente en la 3.5.0 ni en versiones posteriores.
Vale la pena comprender este mecanismo, ya que influye en cómo debes actuar al respecto. Knockout trataba el atributo «name» de forma especial en su enlace «attr» y pasaba los nombres de los elementos al DOM mediante la concatenación de cadenas. Esa ruta de código existe únicamente como solución provisional para Internet Explorer 6 y 7, y solo se ejecuta cuando Knockout detecta una versión de IE 7 o inferior. Los responsables del mantenimiento de Knockout no han podido reproducir el problema en ningún navegador moderno, y la puntuación de predicción de explotación de la vulnerabilidad se ha mantenido por debajo del uno por ciento.
Por lo tanto, en un parque de navegadores actual, la exposición práctica es prácticamente nula. El coste es de otra índole: cada análisis de composición de software, cada SBOM y cada cuestionario de seguridad para clientes mostrará un aviso sin resolver relacionado con tu versión, y «nuestros usuarios no utilizan Internet Explorer 7» es un argumento de control compensatorio que debes esgrimir y documentar, en lugar de una solución concreta a la que puedas remitirte. La advertencia también se mencionó en las actualizaciones de parches críticos de Oracle de julio de 2020, enero de 2021 y abril de 2022, y fue objeto de seguimiento por parte de Red Hat, por lo que aparece en muchos inventarios de productos derivados.
Una corrección que conviene señalar, ya que está circulando: a veces se atribuye el CVE-2019-14863 a Knockout. Se trata de un aviso de seguridad de AngularJS relacionado con atributos «xlink:href» no validados, y no tiene nada que ver con Knockout. Knockout tiene un único CVE, no dos.
Actualizar sigue siendo la mejor opción siempre que sea posible. El obstáculo rara vez es de carácter técnico: Knockout suele estar integrado en una instalación de DNN o en una aplicación de página única controlada por el proveedor que el cliente no puede modificar fácilmente, y nunca ha habido presión por parte de los niveles superiores que haya impulsado esta cuestión.
Conclusiones de la auditoría y revisiones de seguridad paralizadas
Las evaluaciones de cumplimiento no se centran tanto en si tu frontend funciona como en si puedes demostrar que dispones de un proceso definido para detectar y corregir vulnerabilidades en el código de terceros. Los detalles varían según el marco de trabajo, y conviene ser preciso al respecto. La versión v4.0.1 es el más concreto: exige un inventario de componentes de terceros, plazos de aplicación de parches para vulnerabilidades conocidas y, según el requisito 12.3.4, una revisión documentada y aprobada por la dirección para el software que ya no reciba correcciones de seguridad. Si Knockout se encarga de la visualización de cualquier parte de una página de pago, se aplican además los requisitos de inventario e integridad de los scripts. SOC 2 no establece una lista fija de controles; los auditores comprueban el proceso de gestión de vulnerabilidades que usted afirma aplicar. La norma de seguridad se basa en el análisis de riesgos en lugar de ser prescriptiva, y FedRAMP exige una supervisión continua con plazos definidos para la corrección de incidencias.
El software no compatible no falla automáticamente en ninguno de estos aspectos. Lo que hace es generar una observación a la que luego hay que responder, y una dependencia que carezca de un proceso de respuesta de seguridad documentado resulta difícil de justificar, incluso cuando no exista actualmente ninguna vulnerabilidad conocida relacionada con ella. Los clientes suelen plantear la misma pregunta durante el proceso de adquisición, y es ahí donde una pregunta del cuestionario que no se pueda responder puede retrasar discretamente la firma de un contrato.
Este es precisamente el tipo de laguna que pretenden subsanar los parches proporcionados por los proveedores para los componentes de código abierto. El servicio «Endless Lifecycle Support» de TuxCare para Knockout.js es una de las opciones a las que recurren los equipos cuando no se plantea una actualización.
La pila circundante suele entrañar un mayor riesgo
El paquete Knockout publicado no declara ninguna dependencia en tiempo de ejecución. Se trata de una biblioteca independiente, por lo que, a diferencia de una aplicación extensa de Node o PHP, no presenta un árbol transitivo complejo que oculte vulnerabilidades.
El riesgo radica en los componentes a los que está vinculado Knockout. En aplicaciones más antiguas, suele coexistir con jQuery 1.x, Bootstrap 3, RequireJS y un shell de DNN o SharePoint ya obsoleto. Dependiendo de las versiones que se utilicen, esos componentes pueden presentar sus propias vulnerabilidades conocidas y sus propias limitaciones de mantenimiento. Knockout se convierte entonces en el eje que mantiene todo el conjunto unido, ya que actualizarlo suele implicar modificar todo lo que lo rodea.
Así es como una biblioteca que se mantiene de forma intermitente se convierte en una restricción que afecta a toda la pila.
Tus opciones cuando Knockout.js no ofrece un soporte predecible
Tienes cuatro opciones viables. Tres de ellas te permiten seguir en Knockout y se tratan aquí; la cuarta, una migración por fases, se aborda en la sección siguiente. La elección adecuada depende de hasta qué punto puedas modificar la aplicación y de cuánto tiempo necesites mantenerla en funcionamiento. Ninguna de ellas consiste en «no hacer nada», ya que no hacer nada solo traslada el coste a tu próxima auditoría o a tu próximo incidente.
Contratar asistencia técnica con garantía del proveedor
La cuestión aquí es si se puede mantener Knockout en funcionamiento de forma segura sin modificar el código de la aplicación. Para la mayoría de los equipos que dependen de un CMS de un proveedor, sí es posible, y el soporte técnico proporcionado por el proveedor es la opción que presenta menos complicaciones.
El soporte de ciclo de vida ampliado significa que un tercero se encarga del mantenimiento de seguridad que el proyecto original no garantiza: supervisión de nuevas vulnerabilidades, adaptación de correcciones a versiones anteriores y establecimiento de un plazo de respuesta contractual. Esto convierte un componente sin compromiso de soporte en uno que puedes justificar en una auditoría.
Dado que Knockout no declara ninguna dependencia en tiempo de ejecución, la cuestión de la cobertura es más sencilla que en la mayoría de las bibliotecas. El soporte de ciclo de vida ilimitado de TuxCare cubre actualmente las versiones 2.3.0, 3.2.0 y 3.4.2 de Knockout.js, proporcionando correcciones de CVE a través de npm desde repositorios alojados por TuxCare. Si no puedes actualizar la aplicación y necesitas una fuente documentada de correcciones de seguridad, este servicio puede ayudarte en tus tareas de gestión de riesgos y cumplimiento normativo sin necesidad de una migración inmediata.
Aplicación autónoma de parches
¿Dispones de los conocimientos internos sobre seguridad en JavaScript necesarios para encargarte de esto? Si es así, puedes fijar una versión que se sepa que funciona correctamente, estar atento a posibles nuevos problemas e incorporar las correcciones a tu propia bifurcación.
La contrapartida es que te conviertes en el responsable del mantenimiento. Eso implica supervisar el NVD, la base de datos de avisos de GitHub, el repositorio original y los avisos de los proveedores derivados en busca de cualquier cosa relacionada con Knockout o los componentes que lo rodean, para luego escribir y probar parches y asumir ese coste de forma indefinida. Funciona bien para equipos con sólidos conocimientos de seguridad front-end y una huella pequeña y bien definida.
No funciona bien cuando todo el conocimiento está en la cabeza de un solo ingeniero. El día que se vaya, tu bifurcación mantenida se convertirá silenciosamente en otra dependencia sin mantenimiento.
Endurecer y fijar en su sitio
¿Se puede reducir el radio de la explosión lo suficiente como para ganar tiempo mientras se planea una salida definitiva? A menudo sí, y esta es la opción que menos se aprovecha.
En la práctica: siempre que la compatibilidad lo permita, actualiza a la versión 3.5.3, la versión actual, que no se ve afectada por CVE-2019-14862 e incluye las últimas correcciones del proyecto. A continuación, implementa una política de seguridad de contenidos (CSP) restrictiva y plantéate utilizar un cortafuegos de aplicaciones web como capa adicional de detección y filtrado. Ninguna de estas medidas sustituye a la aplicación de parches a una biblioteca vulnerable, pero, juntas, reducen significativamente la superficie de ataque mientras decides qué pasos dar a continuación.
Consejo de experto: La compatibilidad con Trusted Types llegó con Knockout 3.5.2 y se mantiene en la versión 3.5.3, que crea una política denominada «knockout» para sus operaciones internas. Si configuras «require-trusted-types-for ‘script’» en tu CSP, Knockout funcionará con ella automáticamente; pero si además utilizas la directiva «trusted-types» como lista de permitidos, incluye a Knockout en ella. De lo contrario, la política no se registrará sin que se avise de ello, y el manejo del HTML por parte de Knockout dejará de funcionar cuando se aplique la política. «Trusted Types» alcanzó la compatibilidad entre navegadores en febrero de 2026, así que comprueba su funcionamiento con clientes más antiguos. Reduce la exposición a los sumideros de XSS basados en el DOM; no elimina todas las formas de XSS.
Planificación de una estrategia de salida a largo plazo de Knockout.js
Se trata de un ejercicio de planificación, no de un tutorial sobre migración. El objetivo es ordenar las decisiones, más que escribir código de migración, y es el mismo en todos los enfoques: evitar una reescritura «big bang» innecesariamente amplia, que concentra el riesgo de entrega y retrasa todas las mejoras de seguridad incrementales hasta que se alcance un hito enorme.
Elige el objetivo y el modelo de interoperabilidad
¿A qué marco de trabajo vas a pasar y cómo coexistirán el código antiguo y el nuevo durante la transición? Hay dos respuestas generales, y vale la pena echarle un vistazo a la más reciente antes de decidirte a reescribir el código.
La primera es TKO, la línea oficial de Knockout 4.x. Alcanzó su primera versión estable en abril de 2026 y ofrece una versión compatible con Knockout, diseñada expresamente para facilitar la migración, junto con otra modular orientada a TSX, además de una ruta de actualización documentada de la versión 3.x a la 4.x. Para un equipo que quiera seguir utilizando el modelo de programación de Knockout, esa es la ruta más corta hacia un código que recibe mantenimiento activo. La salvedad es la adopción: la versión compatible de TKO registra del orden de un centenar de descargas en npm a la semana, frente a las seis cifras de Knockout, así que compruébala con tu propio conjunto de pruebas y trátala como un proyecto pequeño en lugar de como una plataforma consolidada.
El segundo es un marco de trabajo convencional. Knockout se vincula a nodos específicos del DOM, lo que resulta útil en este caso: a menudo se pueden integrar componentes de React, Vue o Svelte dentro de una página existente de Knockout y ejecutar el sistema antiguo y el nuevo en paralelo, siempre que cada marco de trabajo controle una parte claramente separada del DOM. Elige el objetivo en función de las competencias actuales de tu equipo y del mercado laboral, no basándote en comparativas. El límite de interoperabilidad, donde Knockout cede una parte del DOM al nuevo marco de trabajo, es la parte que hay que diseñar con cuidado; un límite mal definido es lo que hace que estas migraciones se estanquen durante meses.
Secuencia con el motivo de la higuera estranguladora
El modelo «strangler-fig» sustituye partes seleccionadas de un sistema de forma incremental, ruta por ruta o función por función, mientras que el resto de la aplicación heredada sigue funcionando. Empieza por los segmentos con mayor rotación o mayor riesgo: aquellos a los que accedes con frecuencia o los que gestionan datos confidenciales. De este modo, se maximiza el valor desde el principio, ya que se reduce el riesgo del código que cambia con mayor frecuencia.
Las pantallas estables y con poco tráfico son las que pueden permanecer más tiempo en Knockout, y puede que algunas nunca merezcan la pena migrarlas.
Instrumentar y medir la salida
Define en cifras qué se considera «terminado» antes de empezar: porcentaje de enlaces migrados, número de rutas que dependen de Knockout que quedan, tamaño del paquete y exposición a CVE en toda la pila de frontend. Utiliza indicadores de características para lanzar las partes migradas tras un interruptor y ejecuta un escáner de dependencias en cada compilación para que puedas ver cómo disminuye el número de riesgos.
Consejo profesional: Incluye una partida de Knockout en el informe de tu escáner de dependencias y representa gráficamente su evolución mes a mes. Una migración que, según los informes, va bien, pero cuyo uso de Knockout nunca disminuye, no va bien, y el gráfico hace que eso sea imposible de ignorar.
Mantén la seguridad de tus aplicaciones Knockout.js con TuxCare
Knockout no ha desaparecido, pero planificar en torno a un proyecto sin un calendario publicado y sin un acuerdo de nivel de servicio (SLA) en materia de seguridad te expone a un riesgo que no puedes cuantificar. Tanto si decides mantenerlo en funcionamiento como si planeas abandonarlo, la pregunta que queda sin respuesta es quién se hace cargo de la respuesta de seguridad mientras tanto.
Si no puedes reescribir el código ahora mismo, el soporte técnico ofrecido por el proveedor puede proporcionarte las correcciones de seguridad continuas de Knockout.js y la documentación que te pedirá el evaluador, sin obligarte a realizar una migración inmediata. El servicio de soporte de ciclo de vida ilimitado de TuxCare cubre las versiones 2.3.0, 3.2.0 y 3.4.2 de Knockout.js, con correcciones de CVE proporcionadas a través de npm, lo que le da margen para realizar la transición según su propio calendario, en lugar de tener que hacerlo en medio de un incidente.
Preguntas frecuentes
¿Sigue siendo seguro utilizar Knockout.js en entornos de producción en 2026?
Es posible, una vez que se haya evaluado la aplicación y se haya protegido adecuadamente. La versión 3.5.3 es la actual y no se ve afectada por CVE-2019-14862, pero Knockout no publica ningún acuerdo de nivel de servicio (SLA) en materia de seguridad ni tiene un calendario de lanzamientos predecible. Considérala una dependencia que debe gestionarse de forma explícita, en lugar de una opción predeterminada para nuevos desarrollos.
¿Cómo puedo saber qué versión de Knockout.js está utilizando mi aplicación?
Comprueba «ko.version» en la consola de tu navegador o ejecuta «npm ls knockout» si se trata de una dependencia de npm. En el caso de plataformas integradas, como DNN, revisa directamente el encabezado del archivo de Knockout o el manifiesto de tu paquete, ya que la biblioteca suele venir incluida con la plataforma en lugar de instalarse por separado.
¿Dejarán los navegadores modernos de ser compatibles con Knockout.js?
No se ha anunciado ninguna fecha límite para los navegadores, y los navegadores actuales ejecutan Knockout sin problemas, ya que se trata de JavaScript puro. A largo plazo, los cambios en las API de los navegadores o unas políticas de seguridad predeterminadas más estrictas podrían generar problemas de compatibilidad para las aplicaciones antiguas. El riesgo a corto plazo es que la biblioteca y la pila de tecnologías que la rodea queden obsoletas sin parches, no que los navegadores dejen de ofrecer soporte.
¿Puede Knockout.js coexistir con un marco de trabajo moderno durante la migración?
Por lo general, sí. Dado que Knockout se vincula a nodos específicos del DOM, puedes integrar componentes de React, Vue o Svelte junto con él y migrar una ruta o una funcionalidad cada vez, siempre y cuando cada marco de trabajo controle una parte claramente diferenciada del DOM.
¿Existen vulnerabilidades CVE conocidas en Knockout.js?
Uno: CVE-2019-14862, una vulnerabilidad de tipo «cross-site scripting» de gravedad media que afecta a las versiones estables hasta la 3.4.2. La versión 3.5.0 y posteriores no se ven afectadas. En ocasiones se atribuye CVE-2019-14863 a Knockout, pero se trata de un aviso relacionado con AngularJS.
