Potential XSS vulnerability in jQuery

Falha em jQuery permite execução de código arbitrário no navegador quando HTML contendo elementos vindo de fonte não confiável é passado para métodos de manipulação de DOM como .html() ou .append(). O ponto crítico é que a sanitização convencional não protege contra ela: mesmo HTML previamente sanitizado pode disparar o problema, o que torna a falha mais perigosa do que um XSS comum onde escapar a entrada resolve.

O defeito está na função interna htmlPrefilter do jQuery, usada por métodos de manipulação de DOM (.html(), .append(), .prepend(), .after(), .before(), entre outros) para normalizar a string HTML antes de inserção. Quando essa string contém elementos , o prefilter processa e reestrutura o markup de um jeito que pode gerar contexto de execução de script — efetivamente um XSS (execução de código não confiável no contexto da página), sem CWE atribuído pelo GitHub Security Advisory.

O ponto central da falha é que ela ocorre mesmo depois de sanitização prévia da string HTML. Isso quebra a expectativa comum de que 'sanitizei antes de inserir, logo estou seguro' — a transformação interna do próprio jQuery ao processar o é o que introduz o vetor, não a ausência de sanitização por parte do desenvolvedor.

O atacante controla o conteúdo HTML que a aplicação vulnerável passa para um desses métodos DOM do jQuery. Isso normalmente significa dados de usuário, resposta de API, ou conteúdo de terceiros incorporado na página — qualquer fluxo onde HTML de origem não confiável termina em .html()/.append()/similares.

O vetor CVSS (AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:L/A:N, score 6.9) reflete alta complexidade de ataque e exigência de interação do usuário — não é um XSS trivial de disparar, precisa que a aplicação efetivamente encaminhe HTML controlado pelo atacante para o método vulnerável e que a vítima interaja com a página.

A exploração exige que a aplicação alvo use uma versão vulnerável de jQuery (1.0.3 até antes de 3.5.0) e que, em algum ponto do código, HTML proveniente de fonte não confiável — parâmetro de URL, campo de formulário, resposta de API externa, conteúdo gerado por outro usuário — seja passado para .html(), .append() ou método equivalente contendo um elemento malicioso. Não basta a biblioteca estar presente: é preciso um sink de manipulação de DOM alimentado por dados não confiáveis, o que restringe o universo de aplicações realmente exploráveis mesmo com jQuery vulnerável carregado.

A CISA lista esta CVE em seu catálogo KEV, indicando exploração confirmada em ambiente real, e há PoC pública disponível (referenciada, por exemplo, em análises no PacketStorm). Isso eleva a prioridade de correção mesmo com a complexidade de ataque classificada como alta pelo CVSS — a combinação de PoC pública e presença massiva do jQuery em aplicações web legadas cria superfície de ataque relevante.

O resultado da exploração bem-sucedida é execução de JavaScript arbitrário no contexto da origem da página vítima — impacto típico de XSS: roubo de sessão, ações em nome do usuário, exfiltração de dados renderizados na página. Não há indício nas fontes de que a falha permita algo além disso (não afeta confidencialidade/integridade do servidor, é client-side).

A correção definitiva é atualizar para jQuery 3.5.0 ou superior, onde o htmlPrefilter foi corrigido. Isso exige testar a aplicação após a atualização, já que a série 3.5.0 também trouxe outras mudanças de comportamento no manuseio de HTML.

Se a atualização não for viável no curto prazo, o próprio advisory do jQuery indica um paliativo específico: sanitizar a string HTML com DOMPurify usando a opção SAFE_FOR_JQUERY antes de passá-la a qualquer método de manipulação de DOM do jQuery. Sanitização genérica (sem essa opção) não é suficiente, porque a falha reside no processamento interno do jQuery após a sanitização, não na ausência dela — esse é o mito a descartar: 'já sanitizo o HTML, então estou protegido' não vale para esta CVE especificamente.

Como controle compensatório adicional, revisar o código em busca de todos os pontos onde HTML de origem externa chega a .html(), .append(), .prepend(), .after(), .before() ou métodos similares, e tratar esses sinks como prioritários para a correção ou o workaround do DOMPurify. Diversos produtos que empacotam jQuery como dependência de terceiros (bundlers, CMS, appliances) precisaram de atualização própria do componente — vale verificar changelogs de dependências, não só o código próprio.

Não há um padrão de log de servidor confiável para detectar tentativas de exploração, já que o ataque ocorre no processamento client-side dentro do navegador via DOM. Sinais indiretos incluem: presença de elementos com atributos ou conteúdo anômalos em payloads de entrada capturados por WAF ou logging de aplicação, especialmente em campos que alimentam áreas de renderização HTML dinâmica; e telemetria de navegador (CSP violation reports, se Content-Security-Policy estiver configurada) mostrando execução de script inesperada em páginas que usam jQuery vulnerável. Como há PoC pública e listagem no catálogo KEV da CISA, times de threat intel podem monitorar assinaturas associadas a essas PoCs, mas não existe um IOC de rede canônico para esta falha específica.