7 de setembro de 2026 · Security-Advisory · Perimeter · Schwachstellenmanagement · IT-Sicherheit

NetScaler ADC e Gateway: BSI relata exploração ativa

Duas falhas no NetScaler ADC e Gateway, entre elas um bypass de autenticação; o BSI relata exploração ativa. Quem é afetado e que builds resolvem.

Em 19 de agosto de 2026, a Cloud Software Group, fabricante do NetScaler, publicou um Security Bulletin sobre duas vulnerabilidades no NetScaler ADC e no NetScaler Gateway. O CERT-Bund do BSI atualizou o seu alerta sobre o tema em 7 de setembro – com a anotação «exploração ativa relatada». Uma atualização que podia esperar pela próxima janela de manutenção passou, assim, a ser uma que tem de ser instalada agora.

O fabricante não indica nenhuma solução alternativa. Resta a atualização – e a pergunta sobre o que já aconteceu antes.

As duas vulnerabilidades

CVE-2026-19490 é um bypass de autenticação por um caminho alternativo (CWE-288), avaliado com CVSS 9,3 (versão 4.0). O CERT-Bund classifica o alerta no seu conjunto como «crítico». Um atacante não precisa para isso nem de credenciais nem da participação de um utilizador; segundo o vetor CVSS, a falha pode ser explorada através da rede sem autenticação prévia. O BSI regista a exploração ativa para o alerta no seu conjunto, sem a atribuir a uma das duas falhas.

CVE-2026-19489 é um transbordamento de memória (CWE-119) com CVSS 8,8, que pode levar a um comportamento imprevisível ou a uma negação de serviço (denial of service). Pressupõe uma configuração bastante específica: o SIP ALG tem de estar ativado num grupo de Large-Scale NAT. Para a maioria das instalações que usam o NetScaler como gateway de acesso remoto, esta é a menos urgente das duas falhas – mesmo assim, convém fechá-la, até porque é corrigida pela mesma atualização.

Quem é afetado

São afetadas as instalações operadas pelo cliente nestas versões:

  • NetScaler ADC e NetScaler Gateway 14.1 antes de 14.1-73.32
  • NetScaler ADC e NetScaler Gateway 13.1 antes de 13.1-63.21
  • NetScaler ADC FIPS antes de 14.1-73.32 FIPS
  • NetScaler ADC FIPS e NDcPP antes de 13.1-37.277

Os próprios builds 14.1-73.32 e 13.1-63.21, portanto, já estão corrigidos. Isto não é preciosismo: o registo oficial da CVE indica as versões como «through», o boletim do fabricante como «before». O que vale é o boletim.

Também são afetadas as instâncias NetScaler em ambientes híbridos de Secure Private Access. Já os serviços em nuvem operados pela própria Citrix são atualizados pelo próprio fabricante.

Decisivo para a CVE-2026-19490 é o papel do appliance. A falha só se aplica se este estiver configurado como Gateway (SSL-VPN, ICA Proxy, CVPN, RDP Proxy) ou como AAA Virtual Server. Em builds mais recentes, a condição é mais restrita: a partir do 14.1-43.56, do 14.1-66.68-FIPS e do 13.1-61.28, a falha só é explorável se, além disso, estiver configurada uma SAML Action. Em builds mais antigos e no 13.1 FIPS, basta a configuração de Gateway ou AAA por si só.

O fabricante indica as linhas de configuração pelas quais isso se reconhece: add authentication samlAction para a SAML Action, add authentication vserver ou add vpn vserver para o papel de Gateway e AAA. Para a CVE-2026-19489, é add lsn group com sipalg. Uma vista de olhos à configuração em execução responde, portanto, à pergunta de forma mais fiável do que a memória de para que o equipamento foi um dia adquirido.

Uma observação sobre a priorização: um NetScaler que não esteja configurado nem como Gateway nem como AAA Virtual Server não preenche, segundo o fabricante, os pré-requisitos para a CVE-2026-19490. Se, por outro lado, servir como gateway de acesso remoto, está exatamente no papel que importa.

O que fazer agora

  • Instalar a atualização sem esperar pela próxima janela de manutenção. O fabricante pede aos clientes afetados que instalem as versões corrigidas «o mais rapidamente possível» («as soon as possible») e, expressamente, não indica nenhuma solução alternativa. Desde a atualização do alerta do BSI, consideramos necessária uma atualização imediata.
  • Determinar o build exato, não o ramo de versão. «Estamos na 14.1» não responde à pergunta. A diferença está no número do build depois do hífen.
  • Levantar todas as instâncias, não apenas a conhecida. Pares de alta disponibilidade, sistemas de teste com ligação externa e instâncias em ambientes híbridos fazem parte disso. Basta um segundo nó sem patch.
  • Partir de um possível comprometimento anterior à atualização. A falha era do conhecimento público desde 19 de agosto. A atualização fecha-a, mas não desfaz o que possa ter acontecido entretanto. Verifique logs, alterações de configuração e contas criadas em busca de anomalias.
  • Terminar sessões e renovar credenciais. O boletim não o exige; mesmo assim, recomendamo-lo. Um bypass de autenticação proporciona sessões, e uma sessão, uma vez estabelecida, não termina pelo facto de o equipamento ser atualizado. Depois da atualização, termine as sessões existentes e renove as credenciais que possam ter passado pelo gateway – inclusive as de contas de serviço com as quais o appliance comunica com serviços de diretório ou fornecedores de identidade.
  • Esclarecer a situação de notificação. Se a sua empresa estiver sujeita à NIS-2 e uma suspeita se confirmar, começa a correr um prazo a partir do conhecimento.

Se a atualização não for possível de imediato por razões operacionais, resta apenas reduzir a janela de tempo: desativar as funções de Gateway e AAA não necessárias, restringir o acesso às interfaces de gestão a redes de origem conhecidas e monitorizar de perto os inícios de sessão no gateway. Isto expressamente não é uma solução alternativa no sentido do fabricante – um gateway que oferece acesso remoto não pode ser separado da internet de forma sensata sem abdicar da sua finalidade. Por isso, planeie a atualização em paralelo com estas medidas, não depois, e documente a partir de quando cada instância esteve em que build. Vai precisar desses momentos mais tarde, ao rever os logs em busca de anomalias.

Porque são sempre os equipamentos de perímetro

O BSI descreve o padrão no relatório de situação de 2025, na secção «Schwachstellen in Perimetersystemen» (vulnerabilidades em sistemas de perímetro): firewalls e gateways VPN de diversos fabricantes voltaram a ser alvo de ataques, e o intervalo entre a disponibilidade de um patch e a exploração estaria a ficar «cada vez mais curto nos últimos anos». No caso presente, entre o boletim e a anotação do BSI sobre a exploração ativa passaram-se pouco menos de três semanas.

A razão é a posição destes equipamentos. Um gateway está, por definição, na internet, recebe inícios de sessão e, do outro lado, tem acesso à rede interna. Quem contorna a autenticação não está à porta, mas no corredor. Ao mesmo tempo, num appliance fechado normalmente não corre nenhuma deteção de endpoint que relate comportamento suspeito – a visibilidade é menor precisamente onde a exposição é maior.

Daí decorre a frase que o BSI formula no mesmo relatório de situação: «Em caso de exploração de vulnerabilidades, aplicar apenas o patch normalmente não basta para voltar a operar os equipamentos com segurança.» Acessos estabelecidos por atacantes poderiam ainda ser usados meses ou anos depois, se o malware instalado não fosse removido e as credenciais não fossem alteradas. O BSI recomenda manter a superfície de ataque mínima, desativar funções de produto não necessárias e restringir os acessos de gestão a origens fiáveis.

Para a operação, isto significa três coisas. Os equipamentos de perímetro devem constar do inventário, com a versão do build e uma pessoa responsável. Os seus logs devem ir para um sistema central antes de serem sobrescritos no equipamento. E depois de uma falha como esta, a pergunta não é «tem o patch?», mas «o que foi possível entre a divulgação e o patch – e como o excluímos?».

Como a sector7 apoia

Verificamos a superfície de ataque acessível a partir de fora em análises de vulnerabilidades recorrentes e conduzimos as falhas encontradas, através da gestão de patches, a uma correção priorizada. Para os ambientes que acompanhamos, operamos firewalls e acessos VPN no âmbito dos nossos serviços geridos e apoiamos a sua equipa, em caso de incidente, na análise de eventos de segurança. Mais sobre isto em Cibersegurança.

Fontes

Vamos falar sobre a sua situação.

Marcar uma conversa+49 212 240915 0