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
- O jQuery UI está em modo de apenas manutenção desde outubro de 2021, e apenas a versão secundária mais recente recebe correções.
- O jQuery UI 1.10.4 contém três vulnerabilidades XSS conhecidas, todas corrigidas apenas na versão 1.13.0.
- Versões do jQuery anteriores à 3.5.0 apresentam uma vulnerabilidade XSS explorada e listada pela CISA, e uma versão do jQuery UI de 2014 dificulta essa atualização.
- As opções viáveis são atualizar para a versão 1.14.x, substituir os widgets ou adquirir suporte estendido.
Muitas empresas que desenvolveram aplicativos web entre 2008 e 2018 ainda têm o jQuery UI em algum lugar. O seletor de datas em um formulário de despesas. A caixa de diálogo modal em um painel de administração. O preenchimento automático em uma caixa de pesquisa interna. Esses componentes ainda funcionam, e é exatamente por isso que ninguém os alterou há anos. O problema é que o fim do suporte ao jQuery UI ocorreu discretamente enquanto esses aplicativos continuavam em funcionamento e, para versões mais antigas, as correções de segurança do projeto original não são mais retroportadas.
Esta publicação aborda a situação atual do suporte ao jQuery UI, quais CVEs afetam as versões ainda em produção, por que sua dependência do jQuery merece mais atenção do que a própria biblioteca e quais são as suas opções a partir de agora.
Figura 1: Os widgets que você vai reconhecer.
O jQuery UI realmente chegou ao fim de sua vida útil?
Para todas as versões, exceto a mais recente, sim. Em outubro de 2021, os mantenedores do jQuery colocaram o jQuery UI no status de “apenas manutenção”, anunciando a versão 1.13.0 como a última versão planejada do projeto. Os planos mudaram um pouco e os lançamentos continuaram desde então, mas apenas para trabalhos de segurança, compatibilidade e correção de regressões, e somente na versão secundária mais recente.
Não há um calendário de fim de vida útil (EOL) publicado para o jQuery UI; portanto, as datas abaixo se baseiam na política de “apenas a versão secundária mais recente”, e não em avisos oficiais de fim de vida útil.
| Filial | Status | Notas |
|---|---|---|
| 1.14.x | Manutenção: recebe correções | A versão mais recente é a 1.14.2, lançada em janeiro de 2026. Não há suporte para o Internet Explorer nem para o Edge Legacy. |
| 1.13.x | Sem suporte desde agosto de 2024 | O suporte foi encerrado com o lançamento da versão 1.14.0, em 5 de agosto de 2024. A última versão lançada foi a 1.13.3, em abril de 2024. |
| 1.12.x | Sem suporte desde outubro de 2021 | A versão 1.12.1 foi a versão atual de setembro de 2016 até o lançamento da versão 1.13.0. |
| 1.11.x | Sem suporte desde julho de 2016 | O suporte foi encerrado com o lançamento da versão 1.12.0. A última versão lançada foi a 1.11.4, em março de 2015. |
| 1.10.x e versões anteriores | Sem suporte desde junho de 2014 | A versão 1.10.4 foi lançada em janeiro de 2014 e foi substituída pela versão 1.11.0 naquele mês de junho. |
É nas linhas inferiores que a situação fica complicada. A versão 1.12.1 foi a versão atual por cinco anos e é aquela em que muitas equipes congelaram o código, mas muitos aplicativos nunca chegaram a essa versão. A versão 1.10.4 foi lançada em janeiro de 2014 e deixou de receber correções ainda naquele ano; portanto, qualquer sistema que ainda a utilize já está há mais de uma década sem um patch de segurança do desenvolvedor original. Se seu aplicativo foi desenvolvido antes de 2014 e ninguém atualizou deliberadamente o front-end, essa é a primeira coisa que vale a pena verificar.
Figura 2: A lacuna de suporte entre as linhas de lançamento.
O que o fim da vida útil (EOL) do jQuery UI significa para suas aplicações
Uma biblioteca UI abandonada apresenta falhas diferentes das de um ambiente de execução de servidor abandonado. O código vulnerável é executado nos navegadores dos usuários, em páginas com as quais eles interagem diariamente, e as vulnerabilidades do jQuery UI discutidas a seguir são todas do tipo cross-site scripting, e não do lado do servidor.
Os CVEs já registrados
Quatro vulnerabilidades de XSS foram corrigidas na versão 1.13. Três delas afetam todas as versões desde a 1.10.4. A quarta afeta apenas a versão 1.12.0 e versões posteriores, pois o widget ao qual ela se refere não existia antes dessa versão.
CVE-2021-41182 e CVE-2021-41183 permitir a injeção de script por meio do seletor de data altField opção e sua *Text opções, respectivamente. CVE-2021-41184 faz o mesmo por meio do of opção do .position() utilitário, que widgets como o tooltip e o autocomplete utilizam nos bastidores. Todos os três foram corrigidos na versão 1.13.0; portanto, uma implantação da versão 1.10.4 contém todos eles. O quarto, CVE-2022-31160, trata-se de um XSS desencadeado pela atualização de um widget do tipo checkboxradio com um rótulo semelhante a HTML, e foi corrigido na versão 1.13.2. Esse widget foi introduzido na versão 1.12.0; portanto, o caminho de código vulnerável não existe nas versões 1.10.4 ou 1.11.x. No entanto, vale a pena saber disso antes que seu próximo relatório de varredura seja gerado, pois o aviso publicado classifica todas as versões anteriores à 1.13.2 como afetadas, sem um limite mínimo; portanto, um scanner irá sinalizar a vulnerabilidade na versão 1.10.4 de qualquer maneira.
Vale a pena observar a cronologia. Três das quatro foram corrigidas na própria versão 1.13.0 — o lançamento que acompanhou o anúncio do modo de manutenção —, com os avisos de segurança publicados algumas semanas depois. A quarta foi corrigida nove meses após a entrada no modo de manutenção. As vulnerabilidades não deixaram de surgir quando o desenvolvimento ativo foi encerrado. O que mudou foi até que ponto as correções remontam no tempo.
Figura 3: Onde as CVEs estão localizadas na interface.
O que nunca é portado para versões anteriores
A política de manutenção abrange apenas a versão secundária mais recente. Quando surge a próxima falha no seletor de data ou na caixa de diálogo, ela é avaliada em relação à versão 1.14.x; se for necessário, é corrigida nessa versão, mas não é alterada em nenhuma outra.
O aviso provavelmente informará que sua ramificação está afetada, já que os avisos do jQuery UI indicam os intervalos afetados da seguinte forma: < 1.13.0 e < 1.13.2. O que não vai acontecer é um backport. Para equipes que utilizam versões congeladas, qualquer aviso futuro que chegue ao seu branch descreve uma vulnerabilidade que ninguém no upstream vai corrigir.
Quando as estruturas de conformidade se tornam rigorosas
A lógica de auditoria é a mesma para qualquer componente sem manutenção, mas se aplica de maneira diferente dependendo da estrutura regulatória à qual você está sujeito. A norma PCI DSS 4.x exige a aplicação de patches para vulnerabilidades críticas no prazo de um mês após o lançamento, enquanto o restante deve seguir cronogramas baseados em risco definidos por você; e nenhum desses prazos é fácil de cumprir por meio da aplicação de patches quando não há correção suportada disponível. Se seus controles SOC 2 incluem gerenciamento de vulnerabilidades, um componente sem suporte torna mais difícil demonstrar que os riscos identificados estão realmente sendo tratados quando não há correção disponível no fornecedor, e é nesse momento que os auditores começam a questionar o que seu processo de gerenciamento de vulnerabilidades realmente faz. A Regra de Segurança da HIPAA exige que as entidades reguladas identifiquem os riscos às ePHI e os reduzam a um nível razoável e apropriado; portanto, um XSS conhecido e sem correção em um portal voltado para pacientes passa a fazer parte dessa análise, quer você queira ou não.
O trabalho federal sofreu mudanças recentemente, e a antiga terminologia está desatualizada. A CISA revogou a BOD 22-01 em junho de 2026 e a substituiu pela BOD 26-04, que classifica os prazos de correção para agências civis federais de acordo com a exposição dos ativos, o status KEV, a automação de exploração e o impacto técnico, sendo que os casos mais graves devem ser resolvidos em até três dias. O FedRAMP está se alinhando à mesma abordagem baseada em risco, e suas regras de Detecção e Resposta a Vulnerabilidades passarão a ser obrigatórias para provedores de serviços em nuvem a partir de 7 de dezembro de 2026, substituindo o prazo fixo de 30 dias para vulnerabilidades de alta gravidade por uma avaliação baseada em risco. Os fabricantes de produtos terão sua própria versão disso sob a Lei de Resiliência Cibernética da UE, na qual as obrigações de notificação para vulnerabilidades ativamente exploradas entram em vigor em 11 de setembro de 2026, com os requisitos completos de tratamento de vulnerabilidades a seguir em dezembro de 2027.
Nenhuma dessas estruturas transforma a mensagem “jQuery legado detectado” em uma constatação automática, já que o escopo, a exposição e os controles compensatórios são fatores importantes. No entanto, os scanners identificam rapidamente pilhas de front-end legadas e, em qualquer um desses regimes, essa identificação se torna um trabalho que você precisa justificar.
Como o jQuery UI EOL mantém o jQuery antigo em funcionamento
A árvore de dependências do jQuery UI é extremamente simples. No pacote npm atual, o jQuery é a única dependência de tempo de execução declarada, fixada como jquery >=1.12.0 <5.0.0. O código mais antigo do jQuery UI apresentava uma dependência no nível do componente do plugin jQuery Mousewheel dentro do widget spinner, que foi removida na versão 1.14.2, em janeiro de 2026, mas essa nunca foi uma segunda dependência declarada. De qualquer forma, não se trata de um componente embutido em um binário de tempo de execução. O jQuery é carregado em sua própria tag de script, geralmente na linha acima da do jQuery UI, e a maioria das equipes consegue identificar a versão do jQuery mais rapidamente do que a versão do jQuery UI. O risco aqui não está oculto. Ele está acoplado.
Comece analisando o que está em jogo nessa dependência visível. O CVE-2020-11023, uma vulnerabilidade XSS que afeta todas as versões do jQuery da 1.0.3 à 3.4.1, foi incluído no catálogo de Vulnerabilidades Exploradas Conhecidas da CISA em janeiro de 2025, após evidências de exploração em ambiente real, com um prazo federal para correção definido para 13 de fevereiro de 2025. Sua vulnerabilidade irmã, a CVE-2020-11022, abrange a mesma família de manipulação de DOM, e a CVE-2019-11358 acrescenta a poluição de protótipos nas versões anteriores à 3.4.0. A poluição de protótipos foi corrigida na versão 3.4.0 e ambas as falhas XSS na versão 3.5.0; portanto, tudo aqui já foi corrigido no código-fonte desde 2020.
Então, por que as pilhas de tecnologia ainda estão rodando o jQuery 1.x ou 2.x seis anos depois? Para algumas delas, o jQuery UI é parte do que torna a migração complicada. O jQuery UI 1.10.4 foi lançado em janeiro de 2014, mais de dois anos antes do jQuery 3.0 existir, e o projeto descreveu posteriormente o foco principal da versão 1.13.0 como “melhorar a compatibilidade com versões recentes do jQuery”. Uma versão tão antiga não pode ter sido testada com um jQuery que ainda nem existia; portanto, atualizar o jQuery em uma implantação 1.10 congelada é mais um exercício de compatibilidade do que um salto de versão. A atualização do jQuery depende da atualização do jQuery UI, que, por sua vez, depende de uma janela de controle de qualidade que parece nunca chegar. Uma biblioteca de widgets em fim de vida útil (EOL) não esconde o risco do jQuery. Ela pode ajudar a mantê-lo estagnado.
Figura 4: Como uma biblioteca de widgets em fim de vida útil (EOL) pode complicar a atualização do jQuery.
O suporte estendido é uma maneira de sair desse impasse sem forçar nenhuma das duas atualizações, e a TuxCare já fornece patches de segurança para versões selecionadas do jQuery que chegaram ao fim da vida útil (EOL), da 1.8.2 à 3.4.1, de modo que a camada do jQuery permanece atualizada exatamente onde está.
Suas opções após o fim da vida útil (EOL) do jQuery UI
A escolha do caminho certo depende da quantidade de trabalho no front-end que você consegue absorver no momento. Se você precisa manter as atualizações sem mexer em uma interface que já está funcionando, o suporte estendido para a camada do jQuery dá um tempo. Se você puder programar uma migração do jQuery e uma verificação de qualidade (QA) completa, a atualização para a versão 1.14.x é a opção mais limpa. E se o front-end já estiver precisando ser reconstruído de qualquer maneira, retirar o jQuery UI como parte desse projeto é melhor do que fazer o trabalho duas vezes.
Ganhe tempo com o suporte estendido
O Suporte de Ciclo de Vida Ilimitado (ELS) da TuxCare para versões do jQuery em fim de vida (EOL) mantém a versão que você já utiliza atualizada com os patches, e há um pacote ELS correspondente para o jQuery UI 1.10.4. As correções são adaptadas para essa versão, testadas em relação ao comportamento existente, assinadas, respaldadas por um SLA e fornecidas por meio do npm; portanto, incorporá-las envolve apenas uma alteração na configuração de dependências, em vez de uma migração de framework. A TuxCare também oferece suporte a versões selecionadas do núcleo do jQuery que chegaram ao fim da vida útil (EOL), de modo que uma equipe que utilize o jQuery UI 1.10.4 com uma versão do jQuery coberta pelo suporte possa lidar com ambas as camadas sem precisar migrar o framework em nenhum dos lados. A matriz de suporte pública lista versões específicas, em vez de ramos inteiros, e a 1.10.4 é a versão do jQuery UI atualmente documentada; portanto, verifique se a sua versão está nela antes de planejar qualquer ação.
A TuxCare realiza essa atividade como membro Gold da OpenJS Foundation e parceira estratégica do Programa de Sustentabilidade do Ecossistema, o programa não exclusivo que a Fundação utiliza para conectar seus projetos a apoio comercial para versões que ela não mantém mais. Você também pode conferir vulnerabilidades e correções em tempo real no TuxCare CVE Tracker.
O objetivo do suporte estendido não é mantê-lo em uma versão antiga para sempre. Ele elimina a pressão dos prazos, para que a atualização, quando ocorrer, seja feita de acordo com a sua programação e de maneira adequada.
Atualizar para a versão 1.14.x
Manter-se na versão secundária com suporte é a opção mais segura, embora, para um aplicativo da era 1.10, o caminho até lá seja bem mais longo do que o número da versão sugere. A versão 1.14 deixou de oferecer suporte ao jQuery 1.7 a 1.11, 2.0 a 2.1 e 3.0 a 3.5, o que, na prática, significa tudo, exceto a versão mais recente de cada linha principal do jQuery.
Isso cria uma armadilha que merece destaque. O jQuery UI 1.14.x ainda é testado com o jQuery 1.12.4 e 2.2.4; portanto, uma implantação que já esteja em uma dessas versões não precisa de uma atualização do jQuery para migrar para a 1.14. Além disso, não há ganho algum em termos de segurança, pois ambas as versões são anteriores à 3.5.0 e ainda contêm o CVE listado no KEV. É perfeitamente possível chegar a uma versão secundária compatível do jQuery UI enquanto se mantém o jQuery vulnerável.
No que diz respeito ao jQuery, a versão 4.0.0, lançada em janeiro de 2026, deixa de oferecer suporte ao Internet Explorer 10 e versões anteriores, mantendo o IE 11 por enquanto, e o jQuery UI 1.14.2 foi testado com essa versão. Se você pretende permanecer na linha 3.x, uma versão atual, como a 3.7.1, é uma opção mais recomendável do que a versão mínima que, por acaso, corrige as antigas vulnerabilidades (CVEs).
A versão 1.14 também remove totalmente o suporte ao Internet Explorer e ao Edge Legacy e desativa, por padrão, a antiga camada de compatibilidade com a API 1.11, embora a configuração jQuery.uiBackCompat para true restaura o comportamento da versão 1.13 caso você precise de uma transição mais suave. Ao atualizar diretamente da versão 1.10.4, você também terá que lidar com as mudanças incompatíveis das versões 1.11 e 1.12 ao longo do processo, incluindo as alterações na API do Button e a API de efeitos reformulada; além disso, essa camada de compatibilidade é construída com base na API da versão 1.11, e não no comportamento completo da versão 1.10. Ambos os aspectos são importantes exatamente para o tipo de aplicativo corporativo interno em que o jQuery UI ainda é utilizado. E a rotina de manutenção continua após a transição, já que a versão 1.14 só terá suporte até o lançamento da próxima versão secundária.
Migrar do jQuery UI
Os widgets têm equivalentes modernos. Controles nativos como <input type="date"> Os casos mais simples são atendidos por bibliotecas de componentes criadas para o React ou o Vue, ou por componentes web baseados em padrões, que cobrem o restante. Se o aplicativo já precisa passar por uma reformulação do front-end, incorporar a remoção do jQuery UI a esse projeto é a decisão certa. Como resposta isolada ao fim do suporte (EOL), essa costuma ser a opção mais onerosa em jogo, pois implica na reconstrução e no reteste de todas as interfaces interativas que esses widgets atualmente alimentam.
Os riscos de apressar uma atualização
Uma atualização do jQuery UI é uma mudança visível para o usuário, o que torna a pressa em implementá-la mais perceptível do que no caso de uma atualização no back-end. A migração para o jQuery 3.x pode alterar comportamentos nos quais o código da década de 2010 se baseava discretamente. A marcação dos widgets e os temas sofreram mudanças ao longo das versões, portanto, o CSS personalizado da era do ThemeRoller precisa ser revisado. E a verificação não pode se limitar à execução de testes unitários. Isso significa realizar testes de regressão visuais e funcionais em todas as páginas que contenham um seletor de data, caixa de diálogo, acordeão ou autocompletar, em todos os navegadores que seus usuários ainda utilizam.
As equipes que transformam isso em um sprint de emergência correm o risco de entregar layouts com falhas e formulários que não funcionam corretamente diretamente aos usuários, passando as semanas seguintes lidando com tickets de suporte e correções de emergência. A dívida técnica se acumula silenciosamente, pois as soluções provisórias adicionadas durante a pressa se tornam o próximo problema que ninguém ousa tocar. As atualizações de bibliotecas voltadas para o usuário recompensam o planejamento e penalizam os prazos.
Proteja front-ends legados após o fim da vida útil (EOL) com a TuxCare
A TuxCare vem há mais de uma década mantendo o software de código aberto atualizado com patches em ambientes de produção corporativos para milhares de organizações, com o apoio de um processo de aplicação de patches que combina o monitoramento automatizado de CVEs e o backporting com testes e revisão obrigatória por especialistas. Para um front-end congelado, isso significa que o código do qual sua empresa ainda depende continua recebendo correções de segurança sem que a reescrita do front-end se torne uma emergência.
Explore o ELS para jQuery ou comece pelo CVE Tracker para ver quais vulnerabilidades já têm correções disponíveis.
