Um aviso privado vindo dos Países Baixos, depois a pressa pública
A agência neerlandesa de cibersegurança NCSC-NL pediu a um pequeno grupo de operadores de NetScaler que desligassem os seus equipamentos antes de a Citrix dizer o que quer que fosse em público. Foi assim que começou, no sábado, dia 26 de setembro de 2026, a terceira emergência da NetScaler do trimestre, um dia inteiro antes do próprio boletim de segurança da Citrix, o CTX697096.
Até domingo, a Citrix já tinha confirmado a exploração ativa de duas novas vulnerabilidades, CVE-2026-88771 e CVE-2026-88772, e publicado versões corrigidas. A agência norte-americana CISA acrescentou ambas nesse mesmo dia ao seu catálogo de vulnerabilidades exploradas ativamente e deu às suas próprias agências federais até terça-feira, dia 30 de setembro, para corrigirem cada equipamento exposto.
Não é a primeira emergência da NetScaler em 2026. É a terceira em noventa dias.
O que fazem realmente as CVE-2026-88771 e CVE-2026-88772
A CVE-2026-88771 é uma falha de validação de entradas que permite a um atacante sem quaisquer credenciais executar comandos arbitrários no equipamento, e a própria Citrix classifica-a com 9,5 em 10 na escala CVSS. Funciona já na configuração predefinida, sem ser preciso ativar antes qualquer função opcional.
A CVE-2026-88772 é um transbordo de memória que pode fazer o equipamento avariar-se ou dar a um atacante execução remota de código, mas só em sistemas com o DTLS ativado, uma predefinição em qualquer NetScaler Gateway usada como porta de acesso VPN. Juntas, as duas falhas cobrem quase todos os padrões habituais de utilização da NetScaler.
Investigadores de segurança da watchTowr, autores da análise técnica publicada, confirmaram que ambas as falhas foram exploradas como verdadeiros dias zero: os atacantes já tinham exploits a funcionar antes sequer de existir uma versão corrigida para instalar.
Noventa dias, três emergências
| CVE | Conhecida desde | Tipo de falha | Explorada antes da correção |
|---|---|---|---|
| CVE-2026-8451 (CitrixBleed 3) | 7 de julho de 2026 | Fuga de tokens de sessão através do interpretador de início de sessão SAML | Sim, cerca de um dia depois de a correção ser publicada |
| CVE-2026-8452 | Corrigida a 30 de junho, prova de conceito pública em agosto | Execução remota de código sem credenciais | Sim, assim que a prova de conceito se tornou pública |
| CVE-2026-88771 / CVE-2026-88772 | 27 de setembro de 2026 | Execução de código / transbordo de memória | Sim, como verdadeiro dia zero, antes de existir qualquer correção |
A Citrix NetScaler precisou já de três ciclos de correção de emergência distintos num único trimestre, e nenhum dos dois partilha a mesma causa de raiz.
Cada linha desta tabela acaba da mesma forma: atacantes mais rápidos do que a correção. Um fabricante cujo equipamento principal produz este padrão três vezes seguidas não tem azar, está a gerir uma linha de produtos sob ataque ativo prolongado.
Vinte e três mil equipamentos, dois avisos já ignorados
A pesquisa mundial da Shadowserver continua a contar cerca de 23.000 instâncias de NetScaler ADC e Gateway acessíveis a partir da internet, das quais cerca de 22.000 são equipamentos ADC e mais de 1.500 instâncias Gateway.
É, em grande parte, o mesmo grupo a quem a CISA e a Citrix já tinham pedido para corrigir em julho e novamente em agosto. Uma parte considerável não reagiu a tempo em nenhuma das duas ocasiões, e essa é a verdadeira razão pela qual um terceiro dia zero atinge com tanta força: a superfície exposta nunca chegou a diminuir de facto entre emergências.
O que fazer se utiliza NetScaler
Corrija primeiro para as versões corrigidas: 14.1-73.37 ou posterior, 13.1-64.23 ou posterior, ou a versão FIPS ou NDcPP correspondente, caso as utilize. O próprio boletim da Citrix, o CTX697096, indica os números de versão exatos para cada ramo.
Se o seu equipamento estava acessível a partir da internet antes da correção, trate-o como comprometido até prova em contrário. A orientação da CISA para este incidente sai do habitual para um aviso de rotina: recolha registos, uma fotografia do sistema, um pacote de suporte e um core dump antes de aplicar a atualização, porque a própria atualização pode apagar exatamente a prova forense de que precisaria para saber se já tinha sido comprometido.
Depois, coloque a si próprio a pergunta mais difícil que as duas últimas emergências já deveriam ter levantado, a de saber se um único equipamento de perímetro ainda merece um lugar sem vigilância entre a sua rede e a internet, ou se precisa por trás dele de um segundo controlo que não dependa de a Citrix entregar uma correção a tempo.
Leia a seguir: A maioria dos servidores Artifactory ainda está exposta | A Falha Pior Classificada do GitLab Só Precisa de Um Projeto Público
