Suporte Técnico
Documentação
Entrar
Entre em contato conosco
Vá direto para um resumo gerado por IA desta postagem do blog 
Principais conclusões
- A longevidade criou o problema do ciclo de vida. O jQuery 1.x e 2.x estão no fim da vida útil (EOL), sem patches do desenvolvedor original, e todas as versões do jQuery anteriores à 3.5.0 apresentam pelo menos uma vulnerabilidade XSS (CVE) que só foi corrigida em uma versão posterior.
- Essa dependência geralmente aparece no seu gráfico de dependências. O jQuery não tem dependências próprias, mas plugins, temas e pacotes de fornecedores o incluem em versões que você nunca escolheu.
- A migração para uma versão principal não é uma simples troca de arquivos. APIs removidas, incompatibilidades com plug-ins e mudanças de comportamento geram bugs que só vêm à tona durante a interação real com o usuário, e não na integração contínua (CI).
- A escolha entre atualizar ou reescrever é uma falsa dicotomia. A OpenJS mantém um programa não exclusivo de suporte comercial para versões do projeto que não recebem suporte oficial, e a TuxCare é uma de suas parceiras.
Em janeiro de 2006, John Resig apresentou o jQuery no BarCamp em Nova York com um objetivo modesto: tornar a programação em JavaScript menos trabalhosa. Vinte anos e três dias depois, o projeto lançou a versão 4.0.0. Em algum momento entre essas duas datas, seu aplicativo passou a usar o jQuery 1.11.3, e ele ainda está no pacote que você implantou na última terça-feira.
Essa lacuna é o verdadeiro problema do fim do ciclo de vida (EOL) do jQuery. A biblioteca em si não é o problema. O problema é que o jQuery foi implantado de forma tão ampla, tão cedo e de maneira tão profunda no código de terceiros que versões inteiras ficaram sem suporte, embora ainda estivessem em execução em produção em escala enorme. As versões 1.x e 2.x do jQuery estão fora de suporte (EOL) desde 2016. A maioria dos sites que as utilizam nem percebeu.
Eis o argumento que vale a pena apresentar, pois ele deve mudar a forma como você avalia suas opções: essa não é uma história sobre equipes que agem de forma descuidada. É uma história sobre um projeto fundado por voluntários que sobreviveu à suposição de que todos fariam a atualização. A OpenJS Foundation, que hoje abriga o jQuery, afirmou isso publicamente e criou um programa especificamente para lidar com essa questão. Essa história mostra quais das suas opções são legítimas e quais são apenas procrastinação com etapas extras.
Por que o jQuery antigo ainda está em toda parte
Para entender por que essas versões persistem, lembre-se do problema que o jQuery foi criado para resolver. Em meados dos anos 2000, os navegadores implementavam o JavaScript e o DOM de maneiras tão diferentes que localizar um elemento, atribuir um manipulador ou fazer uma solicitação assíncrona podia exigir ramificações específicas para cada navegador. O código que funcionava no Firefox falhava no Internet Explorer.
O jQuery incorporou toda essa complexidade em uma única API concisa. Isso não foi apenas prático. Proporcionou às equipes uma camada de compatibilidade confiável em um momento em que a plataforma não podia oferecer uma, e tornou o trabalho interativo no front-end acessível a um grupo muito maior de desenvolvedores.
Cada linha de lançamento marca uma etapa dessa história:
jQuery 1.x (2006) oferecia suporte a navegadores desde o IE 6, o que o tornava indispensável para aplicativos corporativos e governamentais com amplos requisitos de clientes. A versão 1.12.4, lançada em maio de 2016, foi a última dessa linha.
jQuery 2.x (2013) deixou de oferecer suporte ao IE 6-8 para reduzir o tamanho da versão, mantendo uma API familiar. A versão 2.2.4 foi a última, lançada também em maio de 2016.
O jQuery 3.x (2016) unificou os dois ramos. A versão 3.7.1 (agosto de 2023) é a última versão com novidades, e a política de suporte do próprio projeto agora estabelece que a versão 3.x recebe apenas correções críticas de segurança e correções de bugs, sendo que todos os usuários são incentivados a migrar para a versão 4.x. Estar na versão 3.7.1 não é o mesmo que estar em um ramo com suporte completo.
jQuery 4.0.0 foi lançado em 17 de janeiro de 2026, sendo a primeira grande versão em quase uma década. Ele deixa de oferecer suporte ao IE 10 e versões anteriores, com a remoção do IE 11 prevista para a versão 5.0, adiciona suporte a Trusted Types e deixa de converter silenciosamente solicitações JSON entre domínios para JSONP. Essas duas últimas mudanças representam melhorias reais de segurança.
Uma coisa que as equipes não percebem: o jQuery UI, o jQuery Mobile e o Sizzle agora são projetos eméritos no OpenJS, o que significa que foram formalmente descontinuados. Se o seu plano de migração incluir “e atualizar o jQuery UI”, não há nenhuma versão com suporte disponível.
O que realmente muda no fim da vida
Quando a manutenção no servidor termina, nada para de funcionar. Os formulários são enviados. Os menus são abertos. O Ajax funciona. O aplicativo se comporta exatamente como no dia anterior.
O que muda é o modelo de segurança. Não se espera mais que o projeto lance correções para essa linha; assim, a próxima vulnerabilidade que afetar sua versão surgirá sem um patch do desenvolvedor original. Você ficará sabendo disso por meio de um scanner, e não por meio de uma nota de lançamento.
Para uma análise mais aprofundada dos riscos de segurança comuns e dos CVEs, você pode consultar nosso guia detalhado sobre vulnerabilidades do jQuery.
O histórico do CVE gira exatamente em torno dos recursos pelos quais as pessoas utilizam o jQuery:
CVE-2020-11023: XSS in HTML parsing. Passing HTML containing <option> elements from an untrusted source into .html(), .append(), or similar can execute untrusted code even after sanitization. Affects 1.0.3 through 3.4.1, fixed in 3.5.0. CISA added it to the Known Exploited Vulnerabilities catalog on January 23, 2025, giving federal civilian agencies until February 13 to remediate. Published CVSS scores for this one range from 6.1 to 6.9 depending on which scoring source you consult, which is a fair reminder that the KEV listing rather than the number is what carries the deadline.
CVE-2020-11022: A falha semelhante na mesma lógica de análise, com a mesma pontuação de divisão. Afeta as versões 1.2 a 3.4.1, portanto, seu intervalo começa um pouco depois do da CVE-2020-11023.
CVE-2019-11358 (CVSS 6.1): Contaminação de protótipos em jQuery.extend(). Um invasor capaz de influenciar o objeto mesclado pode modificar Object.prototype. Afeta todas as versões anteriores à 3.4.0, ou seja, todas as versões 1.x e 2.x.
CVE-2015-9251: XSS no tratamento de Ajax entre domínios. Enviar uma solicitação sem dataType e um servidor mal-intencionado pode responder com text/javascript, que o jQuery executa. Afeta todas as versões anteriores à 3.0.0.
CVE-2012-6708 (CVSS 6.1): jQuery(strInput) decides whether input is HTML by looking for < anywhere in the string, which gives an attacker more room to build a payload. Affects versions before 1.9.0.
Vale a pena ser preciso: uma versão afetada não significa automaticamente que o aplicativo seja vulnerável a explorações. A exposição real depende de como seu código utiliza o jQuery, se dados não confiáveis chegam ao caminho vulnerável e quais controles compensatórios você possui. O que essas CVEs demonstram é que “o aplicativo ainda funciona” e “o aplicativo ainda é mantido com segurança” são afirmações diferentes.
É nessa distinção que as auditorias se encaixam. Para um órgão estadual que opera um portal de licenciamento na versão 1.11.3, a consequência prática não é uma narrativa dramática de violação de segurança. Trata-se de uma vulnerabilidade (CVE) listada no KEV com um prazo federal, uma constatação relacionada à norma PCI DSS 6.3.3 caso haja pagamentos envolvidos e um avaliador perguntando qual é o seu plano de correção. A justificativa de que “a Upstream parou de aplicar patches” não encerra uma constatação.
A exposição está no seu gráfico de dependências
O jQuery é autônomo e não possui dependências de tempo de execução, o que o torna mais simples do que a maioria dos pacotes modernos.
Inverta essa perspectiva e você descobrirá o problema. O jQuery é uma das bibliotecas mais utilizadas na história da web, e seu próprio código é apenas uma pequena parte do todo. O restante é composto por plug-ins que dependem de uma versão específica, temas do WordPress, widgets de interface do usuário, componentes comerciais que ninguém mantém, scripts de fornecedores e plataformas mais antigas de CMS ou comércio eletrônico.
Um padrão comum: uma equipe migrou seu próprio código para fora do jQuery há anos, todos acham que ele já não existe mais, e então você abre a aba “Rede” no ambiente de produção e descobre que a versão 1.11.3 está sendo carregada de um caminho que ninguém reconhece, porque um widget de relatórios licenciado inclui sua própria cópia. Duas versões na página, uma delas fora de suporte (EOL), e nenhuma delas no arquivo package.json que alguém revisa. Em alguns ambientes, o arquivo foi copiado para a árvore de código-fonte há anos e não é gerenciado por nenhum gerenciador de pacotes.
Os scanners vão identificar muitos desses casos. Encontrar a biblioteca é a parte fácil. A equipe ainda precisa descobrir por que essa versão está lá, o que depende dela e se substituí-la altera o comportamento.
É justamente esse gráfico que dificulta a atualização. O plugin A é compatível com a versão 1.x. O plugin B chama .live(), que foi removido na versão 1.9. O plugin C é um componente comercial cujo fornecedor interrompeu o fornecimento em 2019 e cuja licença não inclui o código-fonte.
Por que a OpenJS desenvolveu um programa para isso
O jQuery é um Projeto Impact da OpenJS Foundation, a entidade independente de fornecedores na qual ele se estabeleceu após um longo percurso de governança: a Software Freedom Conservancy em 2009, a jQuery Foundation em 2012 e, em seguida, a fusão de 2019 com a Node.js Foundation, que deu origem à OpenJS.
A Fundação vem trabalhando na questão da segurança do jQuery há anos. O projeto Alpha-Omega da OpenSSF destinou US$ 350.000 em 2022 para reduzir os incidentes de segurança no jQuery, modernizando tanto seu código quanto seus usuários. A OpenJS migrou o CDN do jQuery para a Fastly, que, no final de 2024, atendia cerca de 70 bilhões de solicitações por mês relacionadas a ele. A Fundação desenvolveu o Healthy Web Checkup, uma ferramenta que leva cinco segundos e cuja única função é informar qual versão do jQuery seu site carrega. Ela encomendou a pesquisa da IDC que serviu de base para sua própria estimativa de que, de aproximadamente 1,9 bilhão de sites, cerca de 90% usam o jQuery e cerca de um terço deles precisa de uma atualização.
O que esse financiamento não garante é a manutenção indefinida do jQuery 1.8.2. Há um limite rígido para o tempo que os mantenedores podem dedicar, sem remuneração, à correção de versões lançadas na época em que o Windows 7 era o sistema operacional mais atual, e fingir que não é assim é o que leva os mantenedores ao esgotamento.
A OpenJS lançou o Programa de Sustentabilidade do Ecossistema em maio de 2024 para preencher essa lacuna. Os parceiros fornecem correções de segurança comerciais para projetos hospedados pela OpenJS que estejam arquivados, em fim de vida útil ou sejam versões mais antigas dos projetos atuais, e uma parte dessa receita empresarial é revertida para os projetos participantes. A HeroDevs foi a primeira parceira, seguida pela NodeSource, e a TuxCare ingressou na Fundação como membro Gold em 2026 e agora está listada entre os parceiros do ESP na página de parceiros da OpenJS.
Vale ressaltar que o próprio projeto jQuery considera isso uma opção válida. Sua política de suporte a versões oferece três opções para quem estiver utilizando uma versão mais antiga: atualizar, manter a versão antiga e receber correções de segurança por meio de suporte comercial, ou mantê-la sem nenhuma correção, o que o projeto sinaliza como um risco real.
Essas fronteiras ainda são importantes, porque o marketing dos fornecedores tende a esbatê-las:
- O programa não é exclusivo. O OpenJS não determina de qual provedor você deve comprar, e atualmente há três listados no nível “Foundation”.
- Os parceiros do ESP devem ser membros Gold ou Platinum e possuir uma licença de marca registrada para co-marketing, com o endosso no âmbito do projeto por parte do TSC ou da equipe principal relevante, quando for o caso. A parceria no nível Foundation e a lista de fornecedores aprovados para um projeto específico são duas coisas diferentes; portanto, verifique a página do projeto específico que você estiver conduzindo.
- Um patch de um parceiro para o jQuery 1.12.4 é um patch desse parceiro. Não se trata de uma versão oficial do desenvolvedor original e não faz com que uma versão antiga volte a ter suporte oficial.
- O programa não impede, de forma alguma, que os mantenedores ofereçam suporte público a qualquer versão que escolherem.
Os mantenedores do jQuery são os responsáveis pelo projeto e por suas versões atuais. O OpenJS oferece uma plataforma neutra. Os provedores de suporte estendido cobrem versões antigas específicas após o término do suporte do desenvolvedor original. Essa é uma divisão mais sustentável do que esperar que voluntários mantenham todas as versões históricas para sempre, ou que todas as organizações concluam uma migração complexa no momento em que o prazo de suporte termine.
Suas três opções
Atualize para uma versão compatível
Sempre que possível, essa é a solução correta a longo prazo. A versão atual do jQuery é um software melhor, e o suporte a Trusted Types e a alteração relacionada ao JSONP da versão 4.0 reduzem ativamente sua vulnerabilidade a ataques XSS.
Mas um salto da versão 1.x não é apenas um aumento de versão. O sistema de eventos foi reescrito. O Ajax e os Deferreds foram alterados. .bind(), .delegate(), .live()e .error() foram removidos ou alterados. Os casos extremos de seletores sofreram mudanças. O plug-in jQuery Migrate identificará grande parte do comportamento obsoleto, sendo a primeira ferramenta a ser utilizada. Ele não informará quais dos seus plug-ins não possuem um sucessor com manutenção.
Para uma equipe de SaaS de 40 pessoas com um aplicativo, os plug-ins atuais e cobertura de teste real, isso leva alguns sprints. Para uma suíte administrativa interna de um banco com 200 plug-ins acumulados e requisitos do cliente que ainda mencionam o IE 11, isso leva meses, e os bugs que passarem despercebidos serão do tipo dependente de interação, que só aparecem em produção.
Remover o jQuery por completo
querySelector(), fetch(), addEventListener()e classList cobrem a maior parte do que as equipes realmente utilizam no jQuery. Se o seu uso for limitado, eliminar a dependência é a solução mais limpa, e fazer isso de forma gradual é melhor do que uma reescrita completa.
Se não for leve, defina o preço com honestidade. Você está reescrevendo todas as operações do DOM, reimplementando funções auxiliares, abrindo mão da camada de normalização do jQuery e executando o sistema antigo em paralelo enquanto desenvolve o novo.
Suporte prolongado durante o processo de modernização
Alguns aplicativos não podem ser atualizados dentro do cronograma imposto por uma divulgação, mas também não podem ficar sem manutenção. O Suporte de Ciclo de Vida Ilimitado da TuxCare para o jQuery abrange versões sem suporte , incluindo 1.8.2, 1.11.3, 1.12.4, 2.2.4, 3.1.1, 3.2.1, 3.3.1, 3.4.1, fornecidos por meio do npm.
O objetivo não é mantê-lo em uma versão antiga. É separar o prazo de segurança do prazo de migração.
Três perguntas costumam esclarecer a questão:
- Gráfico de dependências limpo, cobertura de teste real, sem plug-ins comerciais abandonados? Atualize para a versão 4.0.0 e pronto.
- O jQuery só está fazendo $() e .on() em apenas alguns arquivos? Remova-o. Não pague para manter código que você não precisa.
- Plug-ins sem manutenção, a exigência de um navegador “congelado” ou uma migração que, na prática, só vai ocorrer daqui a dois trimestres? Adquira o suporte estendido e planeje a atualização adequadamente.
O custo da pressa
Quando uma listagem do KEV ou uma auditoria reprovada comprime uma grande migração em um prazo irrealista, os modos de falha são previsíveis o suficiente para serem identificados com antecedência.
A carga de suporte vem primeiro: formulários que não enviam dados, menus suspensos que não abrem, Ajax que falha silenciosamente — grande parte disso se deve a diferenças de comportamento entre versões, e não a nada no seu diff. Depois, vem a estabilidade, geralmente um caso extremo de plugin que só aparece sob a concorrência do ambiente de produção. Em seguida, a dívida técnica, porque, sob a pressão dos prazos, a refatoração é adiada e a ideia de “vamos resolver isso no próximo trimestre” se torna permanente. Depois, o orçamento: horas de prestadores de serviços, atrasos no roteiro de desenvolvimento e seus melhores engenheiros de front-end passando semanas trabalhando em compatibilidade.
Atualizações planejadas são positivas. Atualizações motivadas pelo pânico são uma atividade diferente, com uma estrutura de custos diferente, e as equipes costumam subestimá-las em um fator de dois ou mais.
Como a TuxCare corrige o jQuery que chegou ao fim da vida útil (EOL)
O suporte estendido vai além da simples republicação de um pacote antigo, e a parte mais difícil é o próprio backport. Uma correção desenvolvida para um branch atual geralmente depende de refatorações posteriores, testes diferentes ou suposições sobre navegadores que não existem na versão de destino. O patch precisa preservar a intenção de segurança da alteração do upstream sem introduzir comportamentos não relacionados nem comprometer a compatibilidade que fez com que você continuasse usando a versão antiga.
Monitoramento e análise. A TuxCare monitora o NVD, os alertas de fornecedores, os feeds de segurança do GitHub e o catálogo KEV da CISA e, em seguida, determina se um problema relatado realmente afeta uma versão coberta. Os intervalos de versões publicadas, por si só, não são suficientes; o caminho do código vulnerável precisa ser analisado.
Retroportação e validação. As correções do upstream são adaptadas à base de código mais antiga por meio de ferramentas automatizadas, com engenheiros de segurança validando o resultado; em seguida, são testadas quanto à integridade, funcionalidade e regressão antes do lançamento. Os pacotes são assinados e distribuídos a partir de repositórios hospedados pela TuxCare. Se você preferir conhecer os detalhes técnicos em vez do resumo, consulte o white paper técnico da TuxCare sobre seu Processo de Correção de Código Aberto é mais acessível do que a maioria dos documentos desse tipo.
Documentação. Cada versão registra quais CVEs foram corrigidos e quais componentes foram alterados, com contexto de SBOM e VEX, para que você possa mostrar quais falhas já foram sanadas. Esse é o artefato que um auditor deseja, e é a diferença entre uma falha encerrada e uma em aberto.
Para se ter uma ideia da magnitude: a TuxCare já disponibilizou mais de 220.000 patches e resolveu mais de 5.000 CVEs em sistemas operacionais, ambientes de execução, bibliotecas e aplicativos ao longo de cerca de 15 anos.
Comece fazendo um inventário
Antes de avaliar qualquer opção, descubra o que você está realmente executando. Verifique as árvores de código-fonte, os pacotes compilados, os manifestos de pacotes, as referências a CDNs, os plug-ins de CMS, as bibliotecas de fornecedores e as páginas de produção renderizadas. Não presuma que a versão declarada pela sua aplicação seja a única que chega aos usuários.
Para cada instância, registre a versão exata, o componente que a utiliza, se ela é carregada diretamente ou por meio de outro produto, o que depende dela, quais ambientes de clientes devem continuar funcionando e qual seria a extensão dos testes de regressão necessários para uma alteração. Com essas informações, as atualizações simples se diferenciam claramente das de alto risco.
Em seguida, verifique a cobertura para suas versões específicas usando o rastreador de CVE em tempo real, que lista o que já foi corrigido. Para versões suportadas, preços e detalhes de implementação, consulte o Suporte de Ciclo de Vida Ilimitado para jQuery da TuxCare.
O Próximo Capítulo
A persistência do jQuery não é prova de que uma biblioteca já tenha se tornado obsoleta. É prova de como ela resolveu de forma completa um problema fundamental, a ponto de a plataforma acabar incorporando grande parte do que ela fazia. A versão 4.0.0 mostra que o projeto continua em evolução.
No entanto, milhões de linhas de código de produção foram escritas nos capítulos anteriores dessa história, e elas evoluem em ritmos diferentes. Algumas podem ser atualizadas neste trimestre. Outras estão vinculadas a aplicativos essenciais para os negócios, plug-ins abandonados, navegadores de quiosques e embarcados, ou a programas de modernização que levam anos para serem concluídos.
Mude para um software com suporte técnico assim que for possível. Quando não for possível fazer isso imediatamente, saiba exatamente quais versões você está utilizando e estabeleça um plano de manutenção concreto para elas. O Programa de Sustentabilidade do Ecossistema existe para que esse plano não signifique pedir aos voluntários que apliquem correções nas versões de 2016 para sempre.
Visite o site da TuxCare Suporte de Ciclo de Vida Ilimitado para Software de Código Aberto para ver como o suporte estendido pode abranger o restante da sua pilha de código aberto pelo tempo que você precisar.
