bishopfox/cve-2026-8452-checkDetector del estado de parche basado en comportamiento para Citrix NetScaler CVE-2026-8452. Envía solicitudes SAML diseñadas para determinar si la comprobación del tamaño de PrefixList está presente, sin explotar ni corromper la memoria.
Una comprobación segura y no destructiva del estado del parche para CVE-2026-8452, el desbordamiento de montón previo a la autenticación en el canonizador de firmas SAML de Citrix NetScaler ADC / NetScaler Gateway (CTX696604, CVSS 8.8). Un PrefixList demasiado grande de canonicalización exclusiva desborda un búfer de tamaño fijo durante la canonicalización, que NetScaler realiza antes de validar la firma que lo transporta — por lo que toda la ruta es alcanzable sin credenciales, sin sesión y sin firma válida. Reportado por Michael Tucker del equipo XOR de JPMorgan Chase; el análisis de causa raíz y de explotación se atribuye a watchTowr Labs.
Este script no explota el fallo ni corrompe memoria. Responde una única pregunta por objetivo: ¿está presente el parche en este appliance? — determinada conductualmente, observando el parche en lugar de adivinar la compilación.
Sí. Está diseñado para uso en producción y en evaluaciones:
PrefixList de 512 bytes y rechazan 513 o más. Ese límite se localizó al byte, es idéntico en ambas ramas soportadas y no cambia con la configuración del appliance ni con la forma del mensaje SAML circundante — confirmado al probar ambas rutas, que envuelven el valor en cantidades sustancialmente diferentes de XML, y comprobar que cambian de comportamiento en el mismo byte. 575 supera el límite por 63 bytes, por lo que el veredicto no depende de cómo esté configurado un objetivo concreto.PrefixList. Inflar otros campos más allá de él — URLs del servicio de consumidor de aserciones, nombres de emisor, identificadores de algoritmo, valores de resumen y de firma — no cambia nada en una compilación parcheada, por lo que aplicar el parche no debería causar que una configuración SAML que funciona empiece a fallar.Si modificas el sondeo, no cambies
PROBE_PREFIXESni barras longitudes. 575 bytes es un valor crítico. Otras longitudes dePrefixListpueden desestabilizar un appliance, en al menos un caso en una compilación que incluye este parche, por lo que un barrido de longitudes no es una forma segura de explorar este fallo, y una longitud menor no es más segura.
Las compilaciones parcheadas rechazan un PrefixList demasiado grande de forma limpia, con un mensaje distintivo. Las compilaciones sin parchear atraviesan el analizador y devuelven un error interno genérico. Una misma solicitud idéntica, dos respuestas diferentes:
PrefixList de 575 bytes | Respuesta |
|---|---|
| Sin parchear | 500 Internal Server Error 43549 |
| Parcheado | 200 Malformed Assertion sent to Netscaler |
Se prueban dos rutas, primero IdP, deteniéndose en cuanto una da una respuesta. Cualquiera de ellas es suficiente por sí sola, y juntas cubren ambos roles SAML:
| Ruta | Solicitud | Requiere |
|---|---|---|
| 1 (primera) | POST /saml/login — AuthnRequest firmada, PrefixList en ds:SignedInfo | una política SAML IdP vinculada al vserver objetivo |
| 2 (respaldo) | POST /cgi/samlauth — SAMLResponse, PrefixList en la firma de la aserción | un servicio de consumidor de aserciones SAML SP en el vserver objetivo |
La ruta IdP va primero porque es la más robusta de las dos. Es insensible al valor de Issuer, a AssertionConsumerServiceURL y a la desviación de reloj — un IssueInstant muy fuera de la tolerancia de desviación del appliance sigue discriminando correctamente, porque la canonicalización precede tanto a la comprobación de tiempo como a la de firma.
La
AuthnRequestde la ruta 1 debe estar firmada. Una sin firmar devuelve200 Malformed Assertion sent to Netscaleren compilaciones parcheadas y sin parchear, lo cual es byte-idéntico a la señal de parcheado, por lo que un sondeo que omita el bloque de firma reporta todo appliance como parcheado. La firma no necesita ser válida, y la de esta herramienta no lo es; solo tiene que estar presente, porque suSignedInfoes lo que lleva elPrefixListal canonizador.
Ambas ramas soportadas cambian su comportamiento exactamente en la compilación con el parche, en ambas rutas:
| Compilación | Veredicto | |
|---|---|---|
13.1-63.16 | última 13.1 vulnerable | VULNERABLE |
13.1-63.18 | primera 13.1 parcheada | PATCHED |
14.1-66.59 | 14.1 vulnerable | VULNERABLE |
14.1-72.61 | primera 14.1 parcheada | PATCHED |
13.1-63.16 y 63.18 son versiones consecutivas, por lo que el cambio es atribuible al propio parche y no a la deriva entre compilaciones intermedias.
Esas son las compilaciones donde este parche apareció por primera vez, y el sondeo detecta exactamente esa transición. Ya no son las compilaciones a las que actualizar: boletines posteriores las han superado, por lo que 13.1-63.18 y 14.1-72.61 responden PATCHED aquí pero siguen expuestas a problemas más recientes. Consulta Remediación para las compilaciones parcheadas actuales.
Porque no puede funcionar con este fallo, ni siquiera en principio. 13.1-63.16 y 13.1-63.18, las compilaciones a cada lado del parche, sirven archivos tmindex.html, base.css y resources.js byte-idénticos — el parche no toca ningún activo web. Los hashes de activos estáticos también coinciden entre ramas, por lo que un enfoque basado en hashes puede resolver un appliance vulnerable a una compilación parcheada y reportarlo como limpio, que es el peor modo de fallo que puede tener una herramienta de detección. Por lo tanto, la identificación por huella de la compilación está deliberadamente no implementada. El estado del parche proviene del sondeo, o de show ns version cuando se tienen credenciales.
./cve_2026_8452_check.py https://gateway.example.com
./cve_2026_8452_check.py https://gateway.example.com:9443
./cve_2026_8452_check.py -f targets.txt --brief