Se você modificar a sonda, não altere PROBE_PREFIXES e não varra comprimentos. 575 bytes é essencial. Outros comprimentos de PrefixList podem desestabilizar um appliance, em pelo menos um caso em uma versão que contém esta correção; portanto, uma varredura de comprimentos não é uma forma segura de explorar este bug, e mais curto não é mais seguro.

Como Funciona

Versões corrigidas rejeitam um PrefixList superdimensionado de forma limpa, com uma mensagem distintiva. Versões não corrigidas passam pelo parser e retornam um erro interno genérico. Uma solicitação idêntica, duas respostas diferentes:

Duas rotas são testadas, IdP primeiro, parando assim que uma der uma resposta. Qualquer uma é suficiente sozinha, e juntas elas cobrem os dois papéis SAML:

A rota IdP vem primeiro porque é a mais robusta das duas. Ela é insensível ao valor de Issuer, à AssertionConsumerServiceURL e ao skew de relógio — um IssueInstant bem fora da tolerância de skew do appliance ainda discrimina corretamente, porque a canonicalização precede a verificação de tempo, assim como a verificação de assinatura.

O AuthnRequest da rota 1 deve ser assinado. Um não assinado retorna 200 Malformed Assertion sent to Netscaler em versões corrigidas e não corrigidas, o que é byte-idêntico ao sinal de corrigido; portanto, uma sonda que omite o bloco de assinatura relata todos os appliances como corrigidos. A assinatura não precisa ser válida, e a desta ferramenta não é; ela só precisa estar presente, porque é o seu SignedInfo que carrega o PrefixList para o canonicalizador.

Comportamento no limite da correção

Ambos os ramos suportados mudam de comportamento exatamente na versão corrigida, em ambas as rotas:

13.1-63.16 e 63.18 são versões consecutivas, portanto a mudança é atribuível ao próprio patch, em vez de alterações entre versões intermediárias.

Essas são as versões em que esta correção apareceu pela primeira vez, e a sonda detecta exatamente essa transição. Elas não são mais as versões para as quais atualizar: boletins posteriores as substituíram, então 13.1-63.18 e 14.1-72.61 respondem PATCHED aqui, mas permanecem expostos a problemas mais novos. Veja Remediação para as versões corrigidas atuais.

Por que não fazer fingerprint da versão?

Porque é impossível que funcione para esta vulnerabilidade, nem em princípio. 13.1-63.16 e 13.1-63.18, as versões imediatamente em ambos os lados da correção, servem byte-idênticos tmindex.html, base.css e resources.js — a correção não toca nenhum ativo web. Hashes de ativos estáticos também colidem entre ramos, portanto, uma abordagem baseada em hash pode mapear um appliance vulnerável para uma versão corrigida e reportá-lo como limpo, que é o pior modo de falha que uma ferramenta de detecção pode ter. Portanto, o fingerprinting de versão é deliberadamente não implementado. O estado do patch vem da sonda, ou do comando show ns version quando você tem credenciais.

Requisitos

• Python 3.8+, apenas biblioteca padrão — nenhum pacote de terceiros.

Uso```bash

single target

./cve_2026_8452_check.py https://gateway.example.com

a specific AAA / Gateway virtual server

./cve_2026_8452_check.py https://gateway.example.com:9443

scan a list, one target per line ('#' comments allowed), compact output

./cve_2026_8452_check.py -f targets.txt --brief

machine-readable output for pipelines

./cve_2026_8452_check.py -f targets.txt --json > results.json

A linha de controle vale a pena ser lida com atenção: a solicitação de 35 bytes passa na verificação de tamanho e é então rejeitada por seu IssueInstant obsoleto, enquanto a sonda de 575 bytes nunca chegou tão longe. Essa é a ordem em que todo o método se apoia — a canonicalização é executada antes da verificação de tempo, assim como é executada antes da verificação de assinatura.

Um appliance corrigido, a mesma solicitação contra o build com a correção. Apenas a linha da sonda difere — o PrefixList superdimensionado é rejeitado pelo nome, em vez de cair no erro interno:```console

Probing patch state (64 prefixes / 575 bytes, confirmed against a 35-byte control) idp /saml/login HTTP 200 "Malformed Assertion": size check rejected the probe idp /saml/login 35-byte control: HTTP 200 "message timestamp outside the appliance's skew tolerance": a different SAML condition, not the size check [ OK ] Size check present (via the IDP route)

https://vpn.example.com via IDP [size-check-present]

O controle detectou isso. Aqui o endpoint respondeu com a mensagem corrigida em ambos os comprimentos, então a verificação de tamanho nunca foi exercitada e a resposta de aparência decisiva é retirada. Este é o disparo do guarda de falso-positivo, e o motivo do disparo é declarado em vez de ficar subentendido:```console

Probing patch state (64 prefixes / 575 bytes, confirmed against a 35-byte control) idp /saml/login HTTP 200 "Malformed Assertion": size check rejected the probe idp /saml/login 35-byte control: HTTP 200 "Malformed Assertion": size check rejected the probe [WARN] Probe and control answered alike, so the size check was never exercised

https://sp-strict.example.com via IDP [flat-response]

The 575-byte probe and the 35-byte control got the same answer, so this endpoint replies the same way whatever it is sent and the size check was never exercised. Unknown, not patched.

Saída legível por máquina (--json), que registra cada rota tentada. verdict, reason e detail são os campos autoritativos; attempts é a evidência bruta, portanto uma tentativa individual pode indicar patched em um alvo cujo veredito é INCONCLUSIVE:```console $ ./cve_2026_8452_check.py https://vpn.example.com --json [ { "target": "https://vpn.example.com", "verdict": "PATCHED", "reason": "size-check-present", "route": "idp", "detail": "HTTP 200 "Malformed Assertion": size check rejected the probe", "attempts": [ { "route": "idp", "path": "/saml/login", "state": "patched", "detail": "HTTP 200 "Malformed Assertion": size check rejected the probe" }, { "route": "idp", "path": "/saml/login", "state": "control:known-error", "detail": "35-byte control: HTTP 200 "message timestamp outside the appliance's skew tolerance": a different SAML condition, not the size check" } ], "netscaler_indicators": [ "CSP contains citrixng://", "CSP contains com.citrix.nsgclient://", "CSP contains nsgcepa://", "CSP report-uri /nscsp_violation/report_uri", "/vpn/js/rdx/ present (HTTP 404)" ] } ]

Três delas são limites de tamanho — um corpo de postagem superdimensionado, um RelayState superdimensionado, um nome de usuário extraído excessivamente longo. Essas são as que mais importam, porque significam que a requisição foi rejeitada por uma verificação de tamanho diferente antes de chegar à que distingue o estado do patch. Isso geralmente significa que a sonda precisa ser apontada para um servidor virtual diferente, não que o appliance esteja ok.

Uma das 20 aparece em todas as execuções da rota IdP: o message timestamp outside the appliance's skew tolerance do controle. A sonda carrega um IssueInstant fixo, então um controle que passa na verificação de tamanho é então rejeitado pela idade — uma propriedade da sonda, não do appliance. Uma resposta fora do conjunto das 20 é impressa como sua própria primeira linha, em vez de uma condição nomeada.

Todas ainda produzem INCONCLUSIVE, marcadas como other-saml-error. Reconhecer uma resposta nunca a eleva para PATCHED: apenas uma resposta explícita de build corrigido faz isso, e toda resposta não reconhecida também cai em INCONCLUSIVE — como unrecognized-reply. O reconhecimento existe para dizer a um operador por que um alvo não pôde ser classificado, não para classificá-lo.

Códigos de saída

2 é o código de saída próprio do argparse para uma invocação inválida, então os códigos de veredito o pulam. Um script wrapper pode, portanto, distinguir "este appliance não pôde ser classificado" (3) de "eu chamei a ferramenta de forma errada" (2), o que um esquema que sobrecarregasse o 2 não conseguiria.

Em uma varredura com vários alvos, o código é escolhido por prioridade, não pelo pior status: VULNERABLE > INCONCLUSIVE > ERROR > limpo. Portanto, um host inacessível nunca mascara um achado de vulnerabilidade no código de saída.

Limitações

• Isto verifica um CVE, não o nível de patch do appliance. PATCHED e o código de saída 0 significam que a verificação de tamanho do CVE-2026-8452 está presente no caminho alcançado pela sonda. Eles não dizem nada sobre qualquer outra vulnerabilidade do NetScaler, incluindo aquelas divulgadas depois deste bug e corrigidas em builds posteriores. Não interprete o código de saída 0 desta ferramenta como um atestado de saúde para um appliance.
• Um veredito não vulnerável é limitado ao endpoint que você sondou. A pré-condição é por servidor virtual. UNAFFECTED significa "não alcançável aqui", não "este appliance está seguro".
• A correspondência de política condiciona o parser. /saml/login abrange todo o appliance, mas em um servidor virtual sem nenhuma política IdP vinculada, ele responde Matching policy not found e interrompe o processamento antes do canonicalizador. Um IdP cuja política usa uma regra de expressão que a requisição da sonda não satisfaz cairá em INCONCLUSIVE em vez de dar uma resposta.
• INCONCLUSIVE não é um atestado de saúde. Ele é deliberadamente distinguido de PATCHED com um código de saída separado, para que o silêncio nunca seja confundido com um resultado de aprovação.
• Implantações nFactor com SAML atrás de um primeiro fator reportam INCONCLUSIVE. Quando a política SAML está em um rótulo de política alcançado por nextFactor, em vez de vinculada diretamente ao servidor virtual, uma asserção não solicitada não encontra política correspondente e interrompe o processamento antes do canonicalizador. Verificado em um build vulnerável, que reportou INCONCLUSIVE. Como SAML atrás de um primeiro fator de postura de dispositivo ou schema de login é um padrão comum, trate INCONCLUSIVE em um gateway nFactor como "provavelmente alcançável, confirme com show ns version", não como uma curiosidade.
• Não é uma verificação de exploração. Um veredito VULNERABLE confirma a ausência da verificação de tamanho, que é o estado do patch. Ele não mede até onde um atacante poderia levar a corrupção no seu build.
• Apenas alcançabilidade. Um resultado reflete o que o appliance expõe à posição de rede a partir da qual você o executa. Um WAF na frente do appliance pode mascarar a resposta.

Remediação

Atualize para 13.1-63.21 ou posterior, ou 14.1-73.32 ou posterior (FIPS e NDcPP: 14.1-73.32 FIPS, ou 13.1-37.277 para 13.1-FIPS e 13.1-NDcPP).

A correção para o CVE-2026-8452 em si foi distribuída pela primeira vez em 13.1-63.18 / 14.1-72.61, conforme CTX696604, e é essa transição que esta ferramenta detecta. Esses builds foram desde então substituídos por CTX696939 (2026-08-19), que adiciona CVE-2026-19489 e CVE-2026-19490, sendo o último um bypass de autenticação pré-autenticação com CVSS 9.3. A pré-condição dele em builds a partir de 14.1-43.56 / 13.1-61.28 é uma ação SAML configurada — então um appliance no escopo do bug que esta ferramenta verifica provavelmente também está no escopo daquele, e um veredito PATCHED aqui não é motivo para adiar a atualização. Ambos os boletins são resolvidos pelos builds acima.

Appliances em 12.1 ou 13.0 não têm correção e não receberão uma — esses ramos estão em fim de vida e devem ser tratados como permanentemente vulneráveis e migrados para um ramo suportado.

Duas notas adicionais:

• Aplique o patch em ambos os nós de um par HA. Um secundário sem patch é um appliance totalmente exposto no momento em que assume.

• Escope seu inventário pela configuração SAML, não pelo tipo de servidor virtual. A redação do aviso do fornecedor (servidor virtual Gateway ou AAA) é mais ampla do que a condição de gatilho. Verifique a configuração em execução para add authentication samlAction e add authentication samlIdPProfile juntamente com add authentication vserver e add vpn vserver.

  Isto é testado, não inferido. Em um appliance confirmadamente vulnerável, removemos todos os objetos SAML, vinculamos um fator de autenticação não-SAML em seu lugar e deixamos os servidores virtuais AAA ativos e atendendo: os endpoints SAML então retornaram 404 para todas as requisições. Eles não são meramente bloqueados por política sem configuração SAML — eles não existem. Então, um servidor virtual sem SAML está genuinamente fora do escopo deste bug, e UNAFFECTED em tal alvo é uma resposta real, não um ponto cego. A ressalva que ainda se aplica é a do escopo acima: ela é por servidor virtual, então confirme cada VIP em vez de concluir qualquer coisa sobre o appliance.

O CVE-2026-8452 foi lançado junto com cinco irmãos no mesmo boletim. O que vale a pena acompanhar ao lado dele é o CVE-2026-8451, um overread de memória pré-autenticação no caminho SAML IdP que tem sido ativamente explorado no mundo real. Os dois compartilham a mesma superfície de ataque, então a mesma auditoria de configuração cobre ambos.

Licença

Este código é distribuído sob uma licença MIT.

Aviso Legal

O uso desta ferramenta para atacar alvos sem consentimento mútuo prévio é ilegal. É responsabilidade do usuário final obedecer a todas as leis locais, estaduais e federais aplicáveis. Os desenvolvedores não assumem nenhuma responsabilidade e não são responsáveis por qualquer uso indevido ou dano causado por este programa.

Veja Também

• Citrix CTX696604 — boletim de segurança do NetScaler
• Citrix CTX696939 — boletim NetScaler posterior que substitui esses builds corrigidos
• watchTowr Labs — análise técnica do CVE-2026-8452
• NVD — CVE-2026-8452