O Knockout.js chegou ao fim da vida útil (EOL)? Situação atual, riscos e como manter a segurança

Principais conclusões

• O Knockout.js nunca teve seu fim de vida útil declarado oficialmente. O projeto lançou duas versões de manutenção, a v3.5.2 e a v3.5.3, em março de 2026, após mais de seis anos sem nenhuma atualização.
• “Não está descontinuado” não é o mesmo que “tem suporte”. Não há LTS, nem SLA de segurança, nem cronograma de fim de vida útil (EOL) publicado, nem política de divulgação de vulnerabilidades publicada. Não é possível planejar uma frequência de atualizações para um projeto que nunca se comprometeu com uma.
• O único CVE registrado contra o Knockout, o CVE-2019-14862, é uma vulnerabilidade XSS de gravidade média corrigida na versão 3.5.0. Seu caminho de código vulnerável só é executado no Internet Explorer 7 e versões anteriores; portanto, em um ambiente com navegadores modernos, trata-se principalmente de um problema para scanners, SBOM e auditorias, e não de um risco de exploração ativa.
• Atualmente, existe um sucessor com suporte contínuo. O TKO, da linha Knockout 4.x, atingiu sua primeira versão estável em abril de 2026 e inclui uma compilação compatível com o Knockout, mas sua adoção ainda é insignificante em comparação com o Knockout 3.x.
• Opções realistas: suporte oferecido pelo fornecedor, aplicação autônoma de patches, fortalecimento do sistema existente ou uma migração em fases. Uma reescrita radical raramente é a primeira medida correta.

O Knockout.js se encontra em uma situação delicada que pega muitas equipes de surpresa. Ele nunca foi declarado obsoleto, mas, entre o final de 2019 e o início de 2026, sua atividade de lançamento ficou praticamente inativa. Então dois novos lançamentos surgiram em março de 2026, sem nenhum roteiro ou anúncio por trás. Se você administra um site DNN (antigo DotNetNuke) ou um aplicativo .NET interno desenvolvido com base nele, essa combinação de longo silêncio e atividade repentina é exatamente o problema: você está dependendo de algo que não consegue prever.

Este artigo oferece uma visão direta sobre a situação atual do Knockout, a linha do tempo das versões, os riscos que realmente importam para sistemas de produção e caminhos práticos a seguir. A posição sincera desde o início: o perigo aqui não é uma biblioteca sem patches que cause problemas graves. É a diferença entre “ainda instalável” e “manutenção previsível”, e é nessa lacuna que se acumulam as constatações de auditorias e que as equipes descobrem que não têm um caminho confiável para uma correção.

O Knockout.js chegou oficialmente ao fim de sua vida útil?

Não, não formalmente. O Knockout.js nunca foi oficialmente declarado como tendo chegado ao fim de vida, e as versões 3.5.2 e 3.5.3 foram lançadas em março de 2026. O suporte ao Trusted Types chegou na versão 3.5.2 e foi mantido na 3.5.3, que é a versão atual. As descrições de que o Knockout foi categoricamente abandonado não correspondem mais ao seu histórico de lançamentos.

Muitos projetos de JavaScript mantidos pela comunidade nunca publicam um aviso formal de fim de vida útil (EOL). Não há um fornecedor comercial de origem nem contrato de suporte com data de validade. O que se observa, em vez disso, é um declínio gradual: menos commits no Git, uma pilha crescente de issues em aberto e intervalos cada vez maiores entre as versões. O Knockout pode ser melhor descrito como mantido de forma intermitente, em vez de estar morto.

Essa distinção é importante para a forma como você lida com isso. Formalmente O software em EOL tem uma data de descontinuação conhecida, com base na qual você pode se planejar. Uma biblioteca mantida de forma intermitente não oferece essa data, o que torna o gerenciamento mais difícil, e não mais fácil.

Análise da realidade: O Knockout registrou cerca de 158.000 downloads no npm na semana que terminou em 24 de julho de 2026. Um software amplamente utilizado, mas sem nenhum compromisso documentado de resposta a problemas de segurança, representa um risco difícil de assumir: as equipes dependem dele, mas ninguém prometeu quando — ou se — uma vulnerabilidade será corrigida.

Principais marcos e datas de lançamento do Knockout.js

Se você chegou aqui procurando uma tabela clara sobre versões LTS com datas de fim de vida útil, eis a resposta desagradável: o Knockout nunca adotou um modelo LTS e nunca publicou datas de fim de vida útil. Todas as datas de lançamento abaixo foram verificadas na página oficial de downloads do Knockout.

O formato dessa linha do tempo é o que realmente importa. Nada foi lançado entre a versão 3.5.1, em novembro de 2019, e a 3.5.2, em março de 2026 — um intervalo de mais de seis anos. Então, duas versões foram lançadas no mesmo mês, e a 3.5.2 foi marcada como obsoleta no npm apenas duas semanas depois, com um aviso informando que ela continha alterações incompatíveis corrigidas na 3.5.3. Essas regressões incluíam ligações que falhavam completamente quando o Knockout era executado no modo estrito.

Dois lançamentos após um intervalo de seis anos não estabelecem um ritmo previsível de segurança. Isso não é uma crítica aos mantenedores, que corrigiram uma longa lista de bugs reais. É uma constatação sobre aquilo em que as equipes de produção podem confiar: não há nenhum compromisso publicado quanto ao tempo de resposta, portanto não há nada em que se basear para o planejamento.

Atenção: O intervalo de seis anos significa que você não pode presumir que a próxima correção será lançada em breve, ou que será lançada de fato. Trate qualquer necessidade de segurança relacionada ao Knockout como algo que talvez você precise resolver por conta própria.

Riscos de utilizar uma versão do Knockout.js sem suporte

A manutenção intermitente não é um prazo que você pode ficar adiando. É uma situação na qual você já se encontra, e ela define o perfil de risco de todos os sistemas que executam o componente, independentemente de você ter ou não mexido no código recentemente. Os riscos abaixo são aqueles que aparecem em incidentes reais e em auditorias reais.

A única vulnerabilidade CVE conhecida e o que ela realmente afeta

Foi registrado um CVE contra o Knockout: CVE-2019-14862, uma vulnerabilidade de cross-site scripting de gravidade média com pontuação base CVSS 3.1 de 6,1, classificada sob o CWE-79. Ela afeta versões estáveis até a 3.4.2 e não está presente na versão 3.5.0 ou posteriores.

Vale a pena entender esse mecanismo, pois ele muda o que você deve fazer a respeito. O Knockout tratava o atributo “name” de maneira especial em sua ligação “attr” e passava os nomes dos elementos para o DOM por meio da concatenação de strings. Esse caminho de código existe apenas como uma solução alternativa para o Internet Explorer 6 e 7, e é executado somente quando o Knockout detecta uma versão do IE 7 ou inferior. Os mantenedores do Knockout não conseguiram reproduzir o problema em nenhum navegador moderno, e a pontuação de previsão de exploração da vulnerabilidade permaneceu abaixo de 1%.

Portanto, em um parque de navegadores atual, a exposição prática é próxima de zero. O custo é de outra natureza: cada execução de análise de composição de software, SBOM e questionário de segurança do cliente exibirá um aviso não resolvido contra a sua versão, e “nossos usuários não utilizam o Internet Explorer 7” é um argumento de controle compensatório que você precisa apresentar e documentar, em vez de uma correção que possa indicar. O aviso também foi mencionado nas Atualizações Críticas de Patches da Oracle em julho de 2020, janeiro de 2021 e abril de 2022, e foi rastreado pela Red Hat, por isso aparece em muitos inventários de sistemas derivados.

Vale a pena fazer uma correção, já que essa informação está circulando: o CVE-2019-14863 às vezes é atribuído ao Knockout. Trata-se de um aviso do AngularJS sobre atributos xlink:href não sanitizados e não tem nada a ver com o Knockout. O Knockout tem um CVE, não dois.

A atualização continua sendo a melhor opção, sempre que possível. O obstáculo raramente é técnico: o Knockout costuma estar integrado a uma instalação de DNN ou a um aplicativo de página única controlado pelo fornecedor, que o cliente não consegue modificar facilmente, e nenhuma pressão vinda de níveis superiores jamais forçou essa mudança.

Conclusões da auditoria e análises de segurança paralisadas

As avaliações de conformidade se preocupam menos com o funcionamento do seu front-end e mais com a capacidade de demonstrar um processo definido para identificar e corrigir vulnerabilidades no código de terceiros. Os detalhes variam de acordo com a estrutura, e vale a pena ser preciso a respeito deles. A versão v4.0.1 é a mais concreta: exige um inventário de componentes de terceiros, cronogramas de correção para vulnerabilidades conhecidas e, de acordo com o Requisito 12.3.4, uma revisão documentada com aprovação da gerência para softwares que não recebem mais correções de segurança. Se o Knockout renderizar qualquer parte de uma página de pagamento, os requisitos de inventário e integridade de scripts se aplicam adicionalmente. O SOC 2 não prescreve uma lista fixa de controles; os auditores testam o processo de gerenciamento de vulnerabilidades que você afirma operar. A Regra de Segurança da é baseada em análise de risco, em vez de ser prescritiva, e o o FedRAMP exige monitoramento contínuo com prazos definidos para correção.

Softwares não suportados não são automaticamente reprovados em nenhum desses itens. O que acontece é que eles geram uma observação à qual você precisa responder, e uma dependência sem um processo documentado de resposta à segurança é difícil de justificar, mesmo quando não há nenhuma vulnerabilidade aberta relacionada a ela no momento. A mesma pergunta costuma surgir por parte dos clientes durante o processo de aquisição, e é nesse momento que um item do questionário sem resposta pode, discretamente, atrasar a assinatura de um contrato.

Esse é exatamente o tipo de lacuna que as correções oferecidas pelos fornecedores para componentes de código aberto se destinam a preencher. O Suporte de Ciclo de Vida Ilimitado da TuxCare para o Knockout.js é uma opção à qual as equipes recorrem quando uma atualização não está nos planos.

A pilha circundante geralmente apresenta maior risco

O pacote Knockout publicado não declara nenhuma dependência de tempo de execução. Trata-se de uma biblioteca autônoma; portanto, ao contrário de uma aplicação extensa em Node ou PHP, ela não possui uma árvore transitiva complexa que possa ocultar vulnerabilidades.

O risco está no que o Knockout está integrado. Em aplicações mais antigas, ele costuma coexistir com o jQuery 1.x, o Bootstrap 3, o RequireJS e um shell DNN ou SharePoint já ultrapassado. Dependendo das versões em uso, esses componentes podem apresentar suas próprias vulnerabilidades conhecidas e suas próprias restrições de manutenção. O Knockout passa então a ser o pino que mantém toda a estrutura no lugar, pois atualizá-lo muitas vezes significa mexer em tudo ao seu redor.

É assim que uma biblioteca mantida de forma intermitente se transforma em uma restrição que afeta toda a pilha.

Suas opções quando o Knockout.js não oferece suporte previsível

Você tem quatro opções viáveis. Três delas mantêm você no Knockout e são abordadas aqui; a quarta, uma migração em fases, é o tema da seção a seguir. A escolha certa depende do quanto você pode alterar o aplicativo e por quanto tempo precisa mantê-lo em funcionamento. Nenhuma delas é “não fazer nada”, pois não agir apenas transfere o custo para sua próxima auditoria ou seu próximo incidente.

Adquira suporte oferecido pelo fornecedor

A questão aqui é se é possível manter o Knockout em funcionamento com segurança sem alterar o código do aplicativo. Para a maioria das equipes que dependem de um CMS de fornecedor, isso é possível, e o suporte oferecido pelo próprio fornecedor é o caminho que apresenta menos dificuldades.

O suporte de ciclo de vida estendido significa que um terceiro assume a manutenção de segurança que o projeto original não garante: monitoramento de novas vulnerabilidades, adaptação de correções para versões anteriores e o compromisso de um prazo de resposta previsto no contrato. Isso transforma um componente sem compromisso de suporte em um que você pode comprovar em uma auditoria.

Como o Knockout não declara dependências de tempo de execução, a questão da cobertura é mais simples do que na maioria das bibliotecas. O Suporte de Ciclo de Vida Ilimitado da TuxCare atualmente abrange as versões 2.3.0, 3.2.0 e 3.4.2 do Knockout.js, fornecendo correções de CVE por meio do npm a partir de repositórios hospedados pela TuxCare. Se você não puder atualizar o aplicativo e precisar de uma fonte documentada de correções de segurança, esse serviço pode apoiar seu trabalho de gestão de riscos e conformidade sem a necessidade de uma migração imediata.

Aplicação autogerenciada de patches

Vocês contam com especialistas internos em segurança de JavaScript para assumir essa responsabilidade? Se sim, vocês podem fixar uma versão comprovadamente estável, monitorar novos problemas e aplicar as correções em seu próprio fork.

A contrapartida é que você se torna o mantenedor. Isso significa monitorar o NVD, o GitHub Advisory Database, o repositório upstream e os alertas dos fornecedores downstream em busca de qualquer coisa relacionada ao Knockout ou aos componentes associados a ele; em seguida, escrever e testar patches e arcar com esse custo indefinidamente. Isso funciona bem para equipes com sólidos conhecimentos em segurança de front-end e uma área de atuação pequena e bem compreendida.

Isso não funciona bem quando o conhecimento fica restrito à cabeça de um único engenheiro. No dia em que ele sair, seu fork mantido acaba se tornando, sem que ninguém perceba, mais uma dependência sem manutenção.

Endurecer e fixar no lugar

É possível reduzir o raio da explosão o suficiente para ganhar tempo enquanto se planeja uma saída de verdade? Muitas vezes sim, e essa é a opção mais subutilizada.

Na prática: sempre que a compatibilidade permitir, atualize para a versão 3.5.3, a versão atual, que não é afetada pela vulnerabilidade CVE-2019-14862 e inclui as correções mais recentes do projeto. Em seguida, implemente uma Política de Segurança de Conteúdo (CSP) restritiva e considere o uso de um firewall de aplicativos web como uma camada adicional de detecção e filtragem. Nenhum desses controles substitui a aplicação de patches em uma biblioteca vulnerável, mas, juntos, eles reduzem significativamente a superfície de ataque enquanto você decide quais serão os próximos passos.

Dica de especialista: O suporte a Trusted Types chegou no Knockout 3.5.2 e se estende até a versão 3.5.3, que cria uma política chamada “knockout” para suas operações internas. Se você definir “require-trusted-types-for ‘script’” em sua CSP, o Knockout funcionará com ela automaticamente — mas, se você também usar a diretiva “trusted-types” como uma lista de permissões, inclua o Knockout nela. Caso contrário, a política falhará silenciosamente ao ser registrada, e o processamento de HTML do Knockout deixará de funcionar quando a política for aplicada. O Trusted Types alcançou compatibilidade entre navegadores em fevereiro de 2026; portanto, teste com clientes mais antigos. Ele reduz a exposição a pontos de entrada de XSS baseados em DOM, mas não elimina todas as formas de XSS.

Planejando uma estratégia de saída de longo prazo do Knockout.js

Este é um exercício de planejamento, não um tutorial de migração. O objetivo é definir a sequência das decisões, e não escrever código de migração, e isso se aplica a todas as abordagens: evitar uma reescrita radical e desnecessariamente ampla, que concentra os riscos de entrega e atrasa todas as melhorias incrementais de segurança, vinculando-as a um único marco de grande porte.

Escolha o alvo e o modelo de interoperabilidade

Para qual framework você vai migrar, e como o código antigo e o novo vão coexistir durante a transição? Há duas respostas gerais, e a mais recente merece ser analisada antes de você se comprometer com uma reescrita.

A primeira é a TKO, a linha oficial do Knockout 4.x. Ela atingiu sua primeira versão estável em abril de 2026 e disponibiliza uma compilação compatível com o Knockout, deliberadamente projetada para facilitar a migração, juntamente com uma versão modular orientada para o TSX, além de um caminho de atualização documentado da versão 3.x para a 4.x. Para uma equipe que deseja permanecer no modelo de programação do Knockout, esse é o caminho mais curto para um código mantido ativamente. A ressalva é a adoção: a versão compatível do TKO está registrando cerca de cem downloads no npm por semana, contra os seis dígitos do Knockout; portanto, valide-a com seu próprio conjunto de testes e trate-a como um projeto pequeno, em vez de uma plataforma consolidada.

A segunda é uma estrutura convencional. O Knockout se vincula a nós específicos do DOM, o que ajuda nesse caso: muitas vezes é possível integrar componentes do React, Vue ou Svelte dentro de uma página existente do Knockout e executar o antigo e o novo lado a lado, desde que cada estrutura possua uma parte claramente separada do DOM. Escolha o destino com base nas habilidades existentes da sua equipe e no mercado de trabalho, e não em benchmarks. O limite de interoperabilidade, onde o Knockout repassa uma parte do DOM para a nova estrutura, é o ponto que deve ser projetado com cuidado; um limite mal definido é o que faz com que essas migrações fiquem paralisadas por meses.

Sequência com o padrão da figueira-estranguladora

O padrão “figueira estranguladora” substitui partes selecionadas de um sistema de forma incremental, rota por rota ou recurso por recurso, enquanto o aplicativo legado restante continua em execução. Comece pelas fatias com maior rotatividade ou maior risco: aquelas que você acessa com frequência ou que lidam com dados confidenciais. Isso antecipa o valor, pois você está reduzindo os riscos do código que sofre alterações com mais frequência.

Páginas estáveis e com baixo tráfego podem permanecer no Knockout por mais tempo, e algumas talvez nunca valham a pena serem migradas.

Instrumento e medição da saída

Defina o que significa “concluído” em termos numéricos antes de começar: porcentagem de ligações migradas, número de rotas dependentes do Knockout restantes, tamanho do pacote e exposição a CVEs em toda a pilha do front-end. Use sinalizadores de recurso para lançar as partes migradas por meio de um botão de ativação/desativação e execute um verificador de dependências em cada compilação para acompanhar a redução do número de riscos.

Dica profissional: Inclua um item específico sobre o Knockout no relatório do seu verificador de dependências e represente-o graficamente mês a mês. Uma migração que, segundo os relatos, está indo bem, mas cujo uso do Knockout nunca diminui, não está indo bem, e o gráfico torna isso impossível de ignorar.

Mantenha seus aplicativos Knockout.js seguros com a TuxCare

O Knockout não está morto, mas planejar um projeto sem cronograma publicado e sem SLA de segurança faz com que você assuma um risco que não é possível avaliar. Quer você mantenha o sistema em funcionamento ou planeje sua saída dele, a questão que permanece em aberto é: quem é responsável pela resposta de segurança nesse meio tempo?

Caso não seja possível reescrever o código neste momento, o suporte oferecido pelo fornecedor pode fornecer correções de segurança contínuas para o Knockout.js e a documentação que um avaliador solicitará, sem exigir uma migração imediata. O Suporte de Ciclo de Vida Ilimitado da TuxCare abrange as versões 2.3.0, 3.2.0 e 3.4.2 do Knockout.js, com correções de CVE fornecidas por meio do npm, o que lhe dá margem para fazer a transição no seu próprio ritmo, em vez de no meio de um incidente.

Perguntas frequentes

O Knockout.js ainda será seguro para uso em produção em 2026?

Isso é possível, desde que a aplicação tenha sido avaliada e devidamente protegida. A versão 3.5.3 é a atual e não é afetada pela vulnerabilidade CVE-2019-14862; no entanto, o Knockout não publica nenhum SLA de segurança nem segue um cronograma previsível de lançamentos. Trate-o como uma dependência gerenciada explicitamente, em vez de uma opção padrão para novos desenvolvimentos.

Como posso saber qual versão do Knockout.js meu aplicativo está executando?

Verifique `ko.version` no console do seu navegador ou execute `npm ls knockout`, caso se trate de uma dependência do npm. Para plataformas integradas, como o DNN, verifique diretamente o cabeçalho do arquivo do Knockout ou o manifesto do seu pacote, já que a biblioteca geralmente vem incluída na plataforma, em vez de ser instalada.

Os navegadores modernos deixarão de oferecer suporte ao Knockout.js?

Não há nenhuma data limite anunciada para os navegadores, e os navegadores atuais executam o Knockout sem problemas, já que se trata de JavaScript puro. A longo prazo, mudanças nas APIs dos navegadores ou políticas de segurança padrão mais rígidas poderiam causar problemas de compatibilidade para aplicativos antigos. O risco no curto prazo é o envelhecimento da biblioteca e da pilha de tecnologias associadas sem a disponibilização de correções, e não a interrupção do suporte por parte dos navegadores.

O Knockout.js pode coexistir com um framework moderno durante a migração?

Normalmente, sim. Como o Knockout se vincula a nós específicos do DOM, é possível montar componentes do React, Vue ou Svelte junto com ele e migrar uma rota ou um recurso por vez, desde que cada framework seja responsável por uma parte claramente separada do DOM.

O Knockout.js possui vulnerabilidades CVE conhecidas?

Primeiro: CVE-2019-14862, uma vulnerabilidade de cross-site scripting de gravidade média que afeta versões estáveis até a 3.4.2. A versão 3.5.0 e as posteriores não são afetadas. O CVE-2019-14863 é ocasionalmente atribuído ao Knockout, mas trata-se de um aviso relacionado ao AngularJS.

Resumo

Nome do artigo

O Knockout.js chegou ao fim da vida útil (EOL)? Situação atual, riscos e como manter a segurança

Descrição

O Knockout.js nunca teve seu ciclo de vida encerrado e lançou duas versões em março de 2026. Aqui estão os riscos reais e quatro maneiras de mantê-lo seguro.

Autor

Rohan Timalsina

Nome da editora

TuxCare

Logotipo da editora