Notepad++ < 8.8.9 WinGUp Updater Lacks Update Integrity Verification

O updater WinGUp do Notepad++, em versões anteriores à 8.8.9, baixava metadados de atualização e o instalador sem qualquer verificação criptográfica de assinatura ou certificado antes de executá-lo. Isso não é uma falha explorável por um atacante de rede qualquer: exige controle sobre o canal de distribuição (DNS, CDN, infraestrutura de hospedagem) — exatamente o que aconteceu no incidente real, quando o provedor de hospedagem do projeto foi comprometido por um grupo atribuído a ataque patrocinado por estado, que filtrou vítimas de alto valor em vez de atacar usuários ao acaso. A CISA confirmou exploração ativa (KEV) e existe PoC pública.

A falha é uma ausência de verificação de integridade/autenticidade de código baixado (CWE-345 / CWE-494). Nas versões vulneráveis, o Notepad++ invocava o processo do WinGUp (GUP.exe) passando apenas os parâmetros '-i' (infoUrl) e '-d' (forceDomain) — nenhum deles verificava assinatura digital, certificado ou hash do arquivo baixado. O updater confiava ciegamente no conteúdo servido pelo domínio de download, seja o descritor XML de atualização, seja o instalador final.

A correção (commits bcf2aa6 no repositório principal e ce00375 no WinGup) introduz checagem de assinatura Authenticode via a classe SecurityGuard, com o método renomeado de verifySignedLibrary para verifySignedBinary. O updater agora passa parâmetros adicionais ao processo GUP: -chkCertSig=yes, -chkCertRevoc, -chkCertTrustChain, -chkCertName, -chkCertSubject e -chkCertAuthorityKeyId. Esses valores incluem um distinguished name esperado (CN/O='Notepad++', C=FR) e IDs de chave de certificado hardcoded no binário (signer key ID e, novo, authority key ID), usados para validar a cadeia de confiança e revogação do certificado do instalador antes de executá-lo.

O atacante não controla nenhuma variável do código do Notepad++ em si — ele controla o que é entregue pelo canal de rede/distribuição no momento da atualização. Como não havia pinning de certificado nem verificação de hash do artefato final, qualquer binário entregue nesse canal era executado como se fosse legítimo, com plenos privilégios do processo que disparou a atualização.

O vetor exige posição de interceptação ou redirecionamento do tráfego de atualização: hijack de DNS, manipulação de rota, MITM on-path, ou — como ocorreu no incidente real documentado pelo próprio projeto — comprometimento da infraestrutura de hospedagem que servia os artefatos de atualização do WinGUp. Não é uma exploração client-side direta contra o parser ou contra a aplicação; é abuso da cadeia de confiança de distribuição de software. Isso explica o AC:H no vetor CVSS 4.0: a complexidade não está em craftar um payload complexo, mas em obter esse ponto de controle na rede/infraestrutura.

Uma vez nessa posição, o atacante substitui o metadado de atualização e/ou o instalador por uma versão maliciosa. Como o WinGUp pré-8.8.9 não valida assinatura, certificado nem hash do artefato, ele baixa e executa o arquivo malicioso com os privilégios do usuário que disparou (ou aceitou) a atualização — na prática, geralmente o usuário logado, que em ambientes corporativos frequentemente tem privilégios elevados na própria estação. O UI:P no vetor reflete que a atualização passa por um prompt/ação do usuário, mas trata-se de fricção mínima, já que o fluxo de auto-update é comportamento esperado e confiado pelo usuário.

Há exploração ativa confirmada: o projeto publicou dois comunicados ('Notepad++ Hijacked by State-Sponsored Hackers' e a clarificação subsequente) relatando que o WinGup foi comprometido via infraestrutura do antigo provedor de hospedagem, num ataque seletivo e não massivo, com IoCs disponibilizados pelo provedor, pela Rapid7 e pela Kaspersky. A CVE está no catálogo KEV da CISA e há PoC pública.

Atualizar para 8.8.9 ou posterior — o projeto recomenda diretamente a 8.9.1 como versão corrente pós-incidente. Atenção: houve um MSI 8.8.9 com número de versão de produto incorreto (ainda reportado como 8.8.8 pelo instalador), o que impedia upgrade automático via ferramentas como Intune; o projeto reemitiu o MSI corrigido com nova assinatura GPG e novo hash SHA-256 publicados na página de download — vale confirmar que o pacote instalado corresponde ao hash/assinatura atuais, não apenas ao número de versão exibido.

Se a atualização imediata não for viável, o paliativo real é desabilitar o auto-updater: no MSI, usar a opção NOUPDATER=1 (msiexec /i npp..Installer.x64.msi NOUPDATER=1), ou desmarcar a opção de auto-atualização durante a instalação/nas configurações. O custo é óbvio: a instância para de receber atualizações automáticas e passa a depender de processo manual de atualização, com verificação manual de hash SHA-256 e assinatura GPG do instalador contra os valores publicados oficialmente.

Não funciona como mitigação: assumir que HTTPS no transporte é suficiente. Se a origem/infraestrutura que serve o artefato está comprometida — como ocorreu no incidente real — o TLS entre cliente e servidor não impede a entrega de um arquivo malicioso servido legitimamente por aquele endpoint; só a verificação de assinatura/certificado do próprio artefato no lado do cliente (o que a correção implementa) mitiga esse cenário.

Verificar a versão instalada do Notepad++ (< 8.8.9 é vulnerável) e se o auto-update foi executado durante a janela do incidente relatado pelo projeto. Em ambientes corporativos, cruzar com os Indicadores de Comprometimento (IoCs) publicados pelo antigo provedor de hospedagem do projeto, pela Rapid7 e pela Kaspersky, referenciados nos comunicados oficiais — não há, nas fontes apuradas, uma assinatura de rede ou de log única e confiável para detectar a exploração isoladamente, já que ela dependeu de comprometimento de infraestrutura de distribuição, não de um payload ou requisição padronizada. Como sinal complementar, comparar o hash SHA-256 e a assinatura GPG de qualquer instalador do Notepad++ baixado no período contra os valores oficiais publicados na página de download do projeto.