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 maior parte dos riscos do jQuery provém de versões antigas que ainda estão em uso em ambientes de produção, e não de nada que tenha sido descoberto recentemente.
- O XSS lidera a lista por meio das vulnerabilidades CVE-2020-11022, CVE-2020-11023 e CVE-2015-9251, com a poluição de protótipos logo atrás.
- O jQuery 1.x e 2.x não têm suporte, o 3.x recebe apenas correções críticas e o 4.x é a versão atual.
- Se a atualização ainda não for viável, as correções fornecidas pelo fabricante evitam que uma versão antiga se torne um risco.
Um scanner de segurança sinaliza o jQuery 3.4.1 em um aplicativo que ninguém mexe há três anos e, de repente, você se vê com uma vulnerabilidade CVE que nem sabia que tinha. Essa é toda a história das vulnerabilidades do jQuery em 2026. As falhas são antigas, as correções já existem e o risco está escondido em uma versão que ninguém se lembrava que ainda estava em produção.
Este guia explica em detalhes quais são as vulnerabilidades CVE, o que elas permitem que um invasor faça, por que elas continuam passando despercebidas nas auditorias e como corrigi-las, independentemente de você poder ou não realizar uma atualização.
Visão geral das vulnerabilidades do jQuery
As vulnerabilidades do jQuery são falhas de segurança em versões específicas da biblioteca que podem permitir que um invasor execute código JavaScript não confiável no navegador, corrompa protótipos de objetos compartilhados ou cause a falha de uma página. Elas são registradas como CVEs, assim como qualquer outra falha relatada.
O problema é que o jQuery quase nunca é algo que uma equipe mantém ativamente. Ele é incluído em um pacote, fixado em uma versão que funciona e depois esquecido. É nessa lacuna entre “existe um patch” e “o patch foi aplicado” que reside o verdadeiro risco.
Tipos de vulnerabilidades do jQuery
As vulnerabilidades se enquadram em três categorias entre os cinco CVEs abaixo. O XSS predomina, embora a contaminação de protótipos e a a negação de serviço completam o que realmente aparece nos resultados da varredura.
| CVE | Tipo | Versões afetadas | Corrigido em |
| CVE-2020-11022 | XSS (htmlPrefilter) | 1,2 – 3,4.x | 3.5.0 |
| CVE-2020-11023 | XSS (select/option) | 1.0.3 – 3.4.x | 3.5.0 |
| CVE-2019-11358 | Poluição causada por protótipos | 1.1.4 – 3.3.x | 3.4.0 |
| CVE-2015-9251 | XSS (Ajax entre domínios) | Antes da versão 3.0.0 | 3.0.0 |
Cross-Site Scripting (XSS)
O XSS é o principal problema do jQuery. O CVE-2020-11022 abrange HTML não confiável em geral passado para os métodos de manipulação do DOM do jQuery, e sua origem remonta à forma como jQuery.htmlPrefilter normalizava a marcação. CVE-2020-11023 abrange HTML contendo elementos `option`. Juntas, essas vulnerabilidades afetam todas as versões da 1.0.3 até qualquer versão anterior à 3.5.0, o que inclui o jQuery 3.4.1, ainda amplamente utilizado na prática. Sob as condições de vulnerabilidade, uma marcação controlada por um invasor e passada a um desses métodos pode acabar executando um script na página, mesmo após ter sido sanitizada. Em qualquer versão anterior à 3.0.0, você também está sujeito à CVE-2015-9251, o XSS Ajax entre domínios, em que a versão 1.12.2 é a única exceção corrigida nesse intervalo.
Poluição causada por protótipos
CVE-2019-11358 afeta versões da 1.1.4 até, mas não incluindo, a 3.4.0. Um objeto malicioso passado por meio de jQuery.extend(true, {}, …) pode gravar em Object.prototype, de modo que propriedades controladas pelo invasor são herdadas por outros objetos que dependem dessa cadeia de protótipos. Por si só, isso já constitui uma técnica básica de manipulação. Dependendo de como as propriedades corrompidas forem utilizadas posteriormente, isso pode ser encadeado para resultar em XSS ou outros impactos específicos do aplicativo. A vulnerabilidade se destacou no Drupal e no Backdrop CMS, o que explica em parte por que ela é encontrada bem além do código jQuery escrito manualmente.
Negação de Serviço (DoS)
A categoria mais silenciosa. CVE-2016-10707 afeta o jQuery 3.0.0-rc.1 e nada mais. Essa versão candidata não lidava corretamente com nomes de atributos booleanos com letras maiúsculas e minúsculas misturadas, de modo que o getter afetado entrava em recursão infinita e esgotava a pilha de chamadas. Um tipo de impacto diferente do par de vulnerabilidades XSS, e chegar a esse caminho de código ainda trava a página em que é executado. A versão final 3.0.0 corrigiu o problema.
Você sabia?: O relatório OSSRA de 2026 (Black Duck) identificou quatro CVEs do jQuery entre as 10 vulnerabilidades mais comuns, afetando, juntas, de 25% a 28% das bases de código auditadas. Falhas com anos de existência, cujos patches já estão disponíveis há muito tempo, ainda aparecem em mais de um quarto dos softwares comerciais.
Riscos decorrentes da falta de correção de vulnerabilidades do jQuery
Uma vulnerabilidade CVE no jQuery não é um risco abstrato. A biblioteca está presente no front-end de uma parte enorme da web e, dependendo de qual vulnerabilidade CVE você esteja apresentando e de como seu aplicativo a utiliza, as consequências podem variar desde a execução de código nos navegadores dos usuários até uma constatação em um relatório de auditoria ou uma página que deixa de responder.
Apropriação de conta e roubo de sessão
O XSS é o principal impacto das vulnerabilidades (CVEs) mais comuns do jQuery, e XSS significa que um invasor consegue executar JavaScript no navegador do usuário. Na prática, isso significa a captura de credenciais em um formulário de login, o roubo de quaisquer dados de sessão aos quais o JavaScript tenha acesso ou a realização de ações de forma discreta, assumindo a identidade do usuário conectado.
Os cookies HttpOnly mantêm o próprio cookie fora do alcance, o que ajuda, mas não impede que um invasor atue dentro dessa sessão. Para um aplicativo SaaS menor, em que o painel de administração ainda roda no jQuery 3.4.1, basta uma única carga maliciosa armazenada para acessar a sessão de um administrador.
Falhas em conformidade e auditoria
Vulnerabilidades conhecidas nas dependências de produção surgem constantemente em avaliações da PCI DSS, varreduras de vulnerabilidades e análises de segurança corporativa, e a justificativa “é apenas a biblioteca de front-end” não basta para esclarecer o relatório. Ainda é preciso comprovar que o componente recebeu o patch ou foi corrigido de alguma outra forma. Os CVEs subjacentes, neste caso, são genuínos, e não falsos positivos, embora a detecção de um scanner específico ainda precise ser verificada em relação ao seu código real e ao status das correções. Vale a pena ter essa distinção pronta antes que um revisor a solicite.
Um raio de explosão maior do que você imagina
O jQuery quase nunca é uma instância única. Temas, plug-ins e núcleos de CMS o utilizam, de modo que uma versão em fim de vida útil (EOL) pode se repetir em dezenas de páginas ou subsistemas. Acompanhar essa disseminação exige um esforço deliberado, e a leitura de a pontuação CVSS corretamente é fundamental quando você começa a priorizar a fila.
Atenção: Muitos scanners de vulnerabilidades e conformidade inferem a exposição a partir da string da versão do jQuery que detectam. Uma correção retroativa que mantém o número da versão original ainda pode gerar um alerta; portanto, documente o patch explicitamente.
Como ocorrem as vulnerabilidades do jQuery?
Três fatores são responsáveis por quase todos esses problemas: usar uma versão antiga, herdar um jQuery que você nunca escolheu e fornecer dados não confiáveis a ele.
Versões desatualizadas do jQuery
Essa é a causa principal para a maioria das equipes. O jQuery 1.x e 2.x tiveram suas versões finais, 1.12.4 e 2.2.4, lançadas em 20 de maio de 2016, e não tiveram mais lançamentos do projeto original desde então. O ramo 3.x agora recebe apenas correções críticas de segurança e de bugs, sendo que a versão 3.7.1, de agosto de 2023, continua sendo a mais recente, e o projeto recomenda que todos migrem para a versão 4.x.
Quando uma versão deixa de receber suporte do desenvolvedor original, as falhas recém-descobertas nela não serão corrigidas pelo projeto jQuery, a menos que você atualize ou aplique patches de outra fonte que ofereça suporte. É a mesma história de qualquer software em fim de vida útil. Os mantenedores originais deixam de se dedicar a ele, e seus sistemas de produção continuam funcionando normalmente.
jQuery herdado e transitivo
Raramente se assume o risco de propósito. O WordPress, o Drupal e uma longa lista de temas e plug-ins de interface do usuário carregam o jQuery automaticamente. Ele entra na sua pilha de dependências sem que ninguém tenha decidido nada, geralmente vinculado à versão com a qual o autor do plug-in fez os testes. Encontrar essas cópias exige uma varredura completa, não basta apenas dar uma olhada no seu próprio arquivo package.json. É o mesmo problema de dependências ocultas que aparece na gestão de vulnerabilidades do PHP e em muitos outros ecossistemas.
Padrões DOM inseguros
Mesmo em uma versão atual, enviar HTML não confiável por meio de .html() ou .append() ainda pode causar um XSS no nível do aplicativo. A biblioteca faz exatamente o que você pediu. O bug está na entrada em que você confiou.
As fusões profundas de objetos não confiáveis merecem o mesmo escrutínio, embora uma versão corrigida já resolva a vulnerabilidade CVE-2019-11358 em si; portanto, o risco com $.extend é o que você passa para ela, e não a função em si. A aplicação do patch na versão corrige a falha no lado da biblioteca. A revisão de código ainda precisa identificar esse padrão.
A realidade: “Estamos usando o jQuery 3, então estamos seguros” é a suposição errada mais comum. As vulnerabilidades CVE-2020-11022 e CVE-2020-11023 só foram corrigidas a partir da versão 3.5.0; portanto, a versão 3.4.1 e todas as versões anteriores da série 3.x ainda estão vulneráveis.
Como corrigir vulnerabilidades do jQuery
Há uma ordem clara de ações. Faça a atualização, se possível; obtenha patches fornecidos pelo fabricante, se não for possível; e, de qualquer forma, implemente camadas de defesa.
1. Atualize para uma versão compatível
A solução mais elegante. Atualizar para o jQuery 3.5.0 ou posterior corrige a vulnerabilidade XSS, e atualizar para a versão mais recente da série 4.x coloca você no ramo atual, com suporte completo do desenvolvedor original. O problema são as mudanças que quebram a compatibilidade, já que a versão 4.0 removeu APIs obsoletas, como jQuery.trim e jQuery.isArray.
Comece com uma auditoria:
npm ls jquery
Se a árvore de código estiver limpa, atualize e execute a versão de desenvolvimento do plug-in jQuery Migrate para que os avisos de compatibilidade sejam detectados antes da produção, e não depois. Se um aplicativo legado apresentar falhas com a atualização, a segunda opção abaixo é o caminho mais realista.
2. Aplicação de patches com suporte do fabricante quando não é possível atualizar
Muitas equipes estão realmente em apuros. Um painel corporativo legado que depende do jQuery 1.x, ou um tema de CMS que deixa de funcionar após uma atualização de versão significativa, não vai migrar para a versão 4.x de um dia para o outro. Essa é exatamente a lacuna que o Suporte de Ciclo de Vida Ilimitado (ELS) da TuxCare para o jQuery preenche.
O ELS retroporta correções de vulnerabilidades CVE para a versão que você já está executando e as disponibiliza por meio do npm. A cobertura abrange dez versões, do jQuery 1.8.2 ao 3.4.1, todas há muito tempo fora do ciclo de vida definido pelo desenvolvedor original. A vantagem prática é a garantia de segurança sem a necessidade de uma migração e reescrita imediatas do front-end; assim, um aplicativo com dependências profundas do jQuery pode permanecer atualizado enquanto a equipe planeja a migração de forma adequada.
Essa cobertura vai além do jQuery, abrangendo os ecossistemas Java, JavaScript, Python, PHP e .NET.
3. Defesa em profundidade
Correção de vulnerabilidades é a solução. Essas camadas reduzem os danos quando algo consegue passar mesmo assim. Trate o HTML controlado por invasores como inseguro, dê preferência a APIs DOM seguras para texto sempre que possível e recorra a um sanitizador de HTML comprovado quando o aplicativo realmente precisar renderizar marcações não confiáveis. Além disso, defina uma Política de Segurança de Conteúdo (CSP) rigorosa. E gere um SBOM para que todas as cópias do jQuery conhecidas pelos metadados de dependência sejam registradas.
Dica profissional: Um grep com string de versão não detecta cópias minificadas e agrupadas, e um SBOM gerado a partir de seus manifestos e arquivos de bloqueio não detectará aquelas que nunca contiveram metadados do npm. Execute também um scanner baseado em conteúdo, como o retire.js, em seus ativos compilados, já que ele foi desenvolvido especificamente para identificar bibliotecas que foram baixadas e submetidas ao controle de versão, em vez de instaladas.
Minimize os riscos comerciais relacionados ao jQuery em fim de vida útil (EOL)
O problema do jQuery não é que a biblioteca seja obscura. É que ela está em toda parte, em sua maioria desatualizada, e raramente é algo que alguém esteja acompanhando ativamente. É assim que uma vulnerabilidade CVE divulgada em algum momento entre 2015 e 2020 acaba aparecendo na sua próxima auditoria. Atualmente, o W3Techs estima que o jQuery em cerca de 66% de todos os sites, e pouco mais de um em cada cinco desses sites ainda está na versão 1.x ou 2.x, cuja versão final do upstream remonta a 2016.
Encontre todas as instâncias. Atualize o que for possível. Para o que não for possível, obtenha cobertura oferecida pelo fornecedor em vez de deixar o sistema vulnerável. Se você estiver preso a uma versão em fim de vida útil (EOL), o Suporte de Ciclo de Vida Ilimitado da TuxCare para jQuery mantém a versão atualizada enquanto você planeja a migração, sem forçar uma reescrita antes que você esteja pronto.
