إذا عدّلت المسبار، فلا تغيّر PROBE_PREFIXES ولا تمسح الأطوال. 575 بايتًا أمر جوهري. يمكن لأطوال PrefixList الأخرى أن تزعزع استقرار الجهاز، في حالة واحدة على الأقل على إصدار يحمل هذا الإصلاح، لذا فإن مسح الأطوال ليس طريقة آمنة لاستكشاف هذه الثغرة، والأقصر ليس أكثر أمانًا.

كيف يعمل

الإصدارات المصلّحة ترفض PrefixList كبير الحجم بشكل نظيف، مع رسالة مميزة. الإصدارات غير المصلّحة تعبر عبر المحلل وتُرجع خطأ داخليًا عامًا. طلب واحد متطابق، إجابتان مختلفتان:

يتم تجريب مسارين، مسار IdP أولاً، ويتوقفان بمجرد أن يعطي أحدهما إجابة. أي منهما كافٍ بمفرده، ويغطيان معًا دورَي SAML:

مسار IdP يأتي أولاً لأنه الأكثر متانة من الاثنين. إنه غير حساس لقيمة Issuer ولـ AssertionConsumerServiceURL، ولانحراف الساعة — فقيمة IssueInstant خارج نطاق تحمّل الجهاز لانحراف الساعة ما زالت تميّز بشكل صحيح، لأن التطبيع يسبق فحص الوقت وكذلك فحص التوقيع.

يجب أن يكون طلب AuthnRequest في المسار 1 موقّعًا. الطلب غير الموقّع يُرجع 200 Malformed Assertion sent to Netscaler على الإصدارات المصلّحة وغير المصلّحة، وهو ما يطابق إشارة المصلّح بايتًا ببايت، لذا فإن المسبار الذي يحذف كتلة التوقيع يبلّغ عن كل جهاز على أنه مصلّح. لا يلزم أن يكون التوقيع صالحًا، وتوقيع هذه الأداة ليس صالحًا؛ يكفي فقط أن يكون موجودًا، لأن SignedInfo الخاص به هو ما يحمل PrefixList إلى المُطبيع.

السلوك عند حد الإصلاح

يغيّر فرعا الدعم سلوكهما تمامًا عند إصدار الإصلاح، على كلا المسارين:

13.1-63.16 و63.18 إصداران متتاليان، لذا يُعزى التغيير إلى التصحيح نفسه وليس إلى الانجراف عبر الإصدارات الوسيطة.

تلك هي الإصدارات التي ظهر فيها هذا الإصلاح بالذات أولاً، ويكتشف المسبار هذا الانتقال بدقة. لم تعُد هي الإصدارات التي يُنصح بالترقية إليها: فالنشرات اللاحقة استبدلتها، لذا فإن 13.1-63.18 و 14.1-72.61 يُجيبان بـ PATCHED هنا بينما يظلان معرّضين لمشكلات أحدث. انظر الإصلاح لمعرفة الإصدارات المصلّحة الحالية.

لماذا لا نأخذ بصمة الإصدار؟

لأنها لا يمكن أن تعمل مع هذه الثغرة، حتى من حيث المبدأ. 13.1-63.16 و13.1-63.18، الإصداران اللذان يقعان مباشرة على جانبي الإصلاح، يخدمان tmindex.html وbase.css و resources.js متطابقة بايتًا ببايت — فالإصلاح لا يمس أي أصل ويب. كما تتطابق تجزئات الأصول الثابتة عبر الفروع، لذا يمكن لنهج قائم على التجزئة أن يحل جهازًا معرّضًا للثغرة إلى إصدار مصلّح ويُبلغ عنه كنظيف، وهو أسوأ نمط فشل يمكن أن تتعرض له أداة كشف. لذلك، فإن أخذ بصمة الإصدار غير مُطبَّق عمدًا. تأتي حالة التصحيح من المسبار، أو من show ns version حيث تتوفر لديك بيانات اعتماد.

المتطلبات

• Python 3.8+، المكتبة القياسية فقط — لا حزم خارجية.

الاستخدام```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

سطر التحكم جدير بالقراءة عن كثب: طلب الـ35 بايت يتجاوز فحص الحجم ثم يُرفض بسبب IssueInstant القديم، بينما مسبار الـ575 بايت لم يبلغ تلك المرحلة أصلًا. هذا هو الترتيب الذي يستند إليه المنهج بأكمله — التطبيع يُنفَّذ قبل فحص الوقت، تمامًا كما يُنفَّذ قبل فحص التوقيع.

جهاز مصحح، نفس الطلب ضد البناء المُصحَّح. فقط سطر المسبار يختلف — PrefixList الضخم يُرفض بالاسم بدلًا من الوصول إلى الخطأ الداخلي:```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]

لقد التقطه التحكم. هنا استجابت نقطة النهاية بالرسالة المرقّعة عند كلا الطولين، لذلك لم يتم تفعيل فحص الحجم أبدًا، ويُسحَب الجواب الذي يبدو حاسمًا. هذا هو انطلاق حارس الإيجابية الكاذبة، والسبب في انطلاقه مذكور بدلًا من تركه للاستنتاج:```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.

مخرجات قابلة للقراءة آليًا (--json)، والتي تسجّل كل مسار تمت محاولته. verdict و reason و detail هي الحقول المعتمدة؛ بينما attempts هي الأدلة الخام، لذا قد يقرأ المسار الفردي patched على هدفٍ حكمُه 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)" ] } ]

ثلاثة منها قيود على الطول — جسم طلب POST ضخم الحجم، وقيمة RelayState ضخمة، واسم مستخدم مستخرج طويل جدًا. هذه هي الأكثر أهمية، لأنها تعني أن الطلب رُفض بفحص مختلف للطول قبل الوصول إلى الفحص الذي يميّز حالة التصحيح. وهذا يعني عادةً أن المسبار يحتاج إلى توجيهه إلى خادم افتراضي مختلف، لا أن الجهاز سليم.

أحد العشرين يظهر في كل تشغيل عبر مسار IdP: حالة الاختبار الضابط message timestamp outside the appliance's skew tolerance. يحمل المسبار IssueInstant ثابتًا، لذا فإن اختبارًا ضابطًا يتجاوز فحص الحجم يُرفض بعد ذلك بسبب عمره — وهي خاصية للمسبار، لا للجهاز. أي رد خارج مجموعة العشرين يُطبع كسطر أول خاص به بدلًا من شرط مُسمّى.

كلها ما زالت تُنتج INCONCLUSIVE، موسومة بـ other-saml-error. إن التعرّف على استجابة لا يرقّيها أبدًا إلى PATCHED: فقط إجابة صريحة من إصدار مُصحَّح تفعل ذلك، وكل رد غير معروف يقع أيضًا في INCONCLUSIVE — باعتباره unrecognized-reply. الغرض من التعرّف هو إخبار المشغّل لماذا لم يمكن تصنيف الهدف، وليس تصنيفه.

رموز الخروج

2 هو رمز خروج argparse نفسه للاستدعاء الخاطئ، لذلك تتخطاه رموز الحكم. وبناءً عليه، يمكن لسكربت غلاف أن يميّز بين "تعذّر تصنيف هذا الجهاز" (3) و"استدعيت الأداة بشكل خاطئ" (2)، وهو ما لا يستطيع مخطط يفرط في تحميل الرمز 2 فعله.

عبر مسح متعدد الأهداف، يُختار الرمز وفقًا للأولوية، وليس وفقًا لأسوأ حالة: VULNERABLE > INCONCLUSIVE > ERROR > نظيف. لذلك فإن المضيف غير القابل للوصول لا يخفي أبدًا نتيجة ثغرة في رمز الخروج.

القيود

• هذا يفحص ثغرة CVE واحدة، وليس مستوى تصحيح الجهاز. PATCHED ورمز الخروج 0 يعنيان أن فحص الحجم الخاص بـ CVE-2026-8452 موجود على المسار الذي بلغه المسبار. وهما لا يقولان شيئًا عن أي ثغرة أخرى في NetScaler، بما في ذلك تلك التي أُعلنت بعد هذا الخطأ وصُحِّحت في إصدارات لاحقة. لا تعتبر الخروج 0 من هذه الأداة شهادة سلامة كاملة للجهاز.
• الحكم بعدم وجود ثغرة يقتصر على نقطة النهاية التي فحصتها. الشرط المسبق هو لكل خادم افتراضي. UNAFFECTED تعني "غير قابل للوصول من هنا"، وليس "هذا الجهاز آمن".
• مطابقة السياسة تتحكم في المحلِّل (parser). المسار /saml/login على مستوى الجهاز بالكامل، لكن على خادم افتراضي لا توجد عليه سياسة IdP مرتبطة، يستجيب بـ Matching policy not found ويختصر الإجراء قبل الـ canonicalizer. أي IdP تستخدم سياسته قاعدة تعبير لا يلبيها طلب المسبار سيقع في INCONCLUSIVE بدلًا من إعطاء إجابة.
• INCONCLUSIVE ليست شهادة سلامة كاملة. هي مُميَّزة عمدًا عن PATCHED برمز خروج منفصل بحيث لا يُخلَط أبدًا بين الصمت ونتيجة ناجحة.
• نشر nFactor مع SAML خلف عامل أول يُبلِّغ عن INCONCLUSIVE. عندما تكون سياسة SAML في تسمية سياسة يُوصَل إليها عبر nextFactor بدلًا من ربطها مباشرة بالخادم الافتراضي، فإن تأكيدًا غير مطلوب لا يجد سياسة مطابقة ويختصر الإجراء قبل الـ canonicalizer. تم التحقق من ذلك على إصدار ثغرة، وقد أبلغ عن INCONCLUSIVE. وبما أن SAML خلف عامل أول مثل device-posture أو login-schema نمط شائع، تعامل مع INCONCLUSIVE على بوابة nFactor على أنها "على الأرجح قابلة للوصول، تأكد باستخدام show ns version"، وليس أمرًا غريبًا.
• ليس فحص استغلال. حكم VULNERABLE يؤكد غياب فحص الحجم، وهو حالة التصحيح. وهو لا يقيس إلى أي مدى يمكن لمهاجم أن يستغل التلف في إصدارك.
• الوصول فقط. النتيجة تعكس ما يكشفه الجهاز لموقع الشبكة الذي تشغّل منه الأداة. ووجود WAF أمام الجهاز يمكن أن يُخفي الاستجابة.

المعالجة

قم بالترقية إلى 13.1-63.21 أو أحدث، أو 14.1-73.32 أو أحدث (FIPS وNDcPP: 14.1-73.32 FIPS، أو 13.1-37.277 لـ 13.1-FIPS و13.1-NDcPP).

الإصلاح الخاص بـ CVE-2026-8452 نفسه شُحن لأول مرة في 13.1-63.18 / 14.1-72.61 وفقًا CTX696604، وهذا هو الانتقال الذي تكشفه هذه الأداة. وقد استُبدلت هذه الإصدارات منذ ذلك الحين بـ CTX696939 (2026-08-19)، الذي يضيف CVE-2026-19489 وCVE-2026-19490، الأخيرة منها عبارة عن تجاوز للمصادقة قبل المصادقة، بتقييم CVSS 9.3. شرطها المسبق على إصدارات من 14.1-43.56 / 13.1-61.28 فصاعدًا هو وجود إجراء SAML مُهيأ — لذا فإن الجهاز الذي يقع ضمن نطاق هذا الخطأ الذي تفحصه الأداة من المرجح أن يقع أيضًا في نطاق تلك الثغرة، وحكم PATCHED هنا ليس سببًا لتأجيل الترقية. كلا النشرتين تُعالجان بالإصدارات المذكورة أعلاه.

أجهزة 12.1 أو 13.0 لا تملك إصلاحًا ولن تحصل على واحد — هذه الفروع منتهية الدعم ويجب التعامل معها على أنها ثغرة دائمة وترحيلها إلى فرع مدعوم.

ملاحظتان إضافيتان:

• طبّق التصحيح على عقدتي زوج HA معًا. العقدة الثانوية غير المُصحَّحة هي جهاز مكشوف بالكامل في اللحظة التي تتولى فيها العمل.

• حدّد نطاق مخزونك بناءً على إعداد SAML، وليس على نوع الخادم الافتراضي. صياغة نشرة البائع (خادم Gateway أو AAA الافتراضي) أوسع من شرط التشغيل. افحص الإعداد الحالي بحثًا عن add authentication samlAction وadd authentication samlIdPProfile بالإضافة إلى add authentication vserver وadd vpn vserver.

  هذا مُختبر، وليس مستنتَجًا. على جهاز مؤكَّد إصابته بالثغرة، أزلنا كل كائنات SAML، وربطنا عامل مصادقة غير SAML مكانها، وتركنا خوادم AAA الافتراضية تعمل وتقدّم الخدمة: بعدها أعادت نقاط نهاية SAML 404 لكل طلب. ليست هذه النقاط مجرد مقيّدة بسياسة دون إعداد SAML — بل إنها غير موجودة. لذا فإن الخادم الافتراضي الذي لا يحتوي على SAML خارج نطاق هذا الخطأ فعلًا، وUNAFFECTED على مثل هذا الهدف إجابة حقيقية وليست نقطة عمياء. الملاحظة التحذيرية التي ما تزال سارية هي تحديد النطاق أعلاه: فهو لكل خادم افتراضي، لذا أكّد كل VIP بدلًا من استنتاج أي شيء بشأن الجهاز.

CVE-2026-8452 صدر جنبًا إلى جنب مع خمس ثغرات شقيقة في نفس النشرة. الثغرة التي تستحق التتبع بجانبه هي CVE-2026-8451، وهي قراءة زائدة للذاكرة قبل المصادقة في مسار SAML IdP شهدت استغلالًا نشطًا في البرية. تشترك الثغرتان في سطح هجوم واحد، لذا فإن نفس مراجعة الإعداد تغطيهما معًا.

الترخيص

يُوزَّع هذا الكود بموجب رخصة MIT.

إخلاء المسؤولية القانوني

استخدام هذه الأداة لمهاجمة أهداف دون موافقة مسبقة متبادلة غير قانوني. وتقع على عاتق المستخدم النهائي مسؤولية الامتثال لجميع القوانين المحلية والولائية والاتحادية المعمول بها. لا يتحمل المطوّرون أي مسؤولية ولا يُعتبرون مسؤولين عن أي إساءة استخدام أو ضرر يسببه هذا البرنامج.

انظر أيضًا

• Citrix CTX696604 — نشرة أمان NetScaler
• Citrix CTX696939 — نشرة NetScaler لاحقة تستبدل تلك الإصدارات المُصحَّحة
• watchTowr Labs — تحليل تقني لـ CVE-2026-8452
• NVD — CVE-2026-8452