ثغرة CVE-2026-0300 في PAN-OS: ما الذي يجب على الجهات الفيدرالية والمؤسسات فعله الآن؟

خطورتها تأتي من اجتماع عدة عوامل في وقت واحد: متجه الهجوم شبكي، ولا تتطلب الثغرة صلاحيات مسبقة أو تفاعلًا من المستخدم، وتصفها Palo Alto Networks بأنها في مستوى استعجال HIGHEST وبدرجة شدة 9.3 CRITICAL، مع نضج استغلال ATTACKED ^[21]. بعبارة أبسط: إذا كانت البوابة مكشوفة على الإنترنت أو لشبكات غير موثوقة، فنافذة الخطر مفتوحة الآن.

من يجب أن يتحرك أولًا؟

الأولوية القصوى لأي جهاز PAN-OS يشغّل User-ID Authentication Portal أو Captive Portal، خصوصًا إذا كان مكشوفًا للإنترنت أو يمكن الوصول إليه من شبكة غير موثوقة. التقارير تشير تحديدًا إلى أجهزة PA-Series وVM-Series المتأثرة عند تفعيل هذه البوابة ^[3][10].

ابدأوا بحصر سريع ودقيق:

• كل جدران Palo Alto Networks التي تعمل بـ PAN-OS.
• كل الأجهزة التي فعّلت User-ID Authentication Portal أو Captive Portal.
• كل واجهة يمكن الوصول إليها من الإنترنت أو من نطاقات غير موثوقة.
• كل جهاز VM-Series منشور في بيئات سحابية أو هجينة، لأن التعرض العام قد يحدث عبر قواعد سحابية أو موازنات حمل وليس فقط عبر إعدادات الجدار الناري نفسه.

ولا توسّعوا نطاق الفحص بلا داعٍ: تشير مصادر Palo Alto إلى أن Prisma Access وCloud NGFW وPanorama ليست متأثرة بهذه الثغرة تحديدًا ^[20].

ماذا يجب فعله فورًا؟

1. قيّدوا البوابة أو عطّلوها

الإجراء الأهم قبل التصحيح هو منع الوصول غير الموثوق إلى User-ID Authentication Portal. يجب تقييد الوصول إلى شبكات داخلية موثوقة فقط، أو تعطيل Captive Portal مؤقتًا إذا لم تكن ضرورية للتشغيل ^[3][7].

إن كان الجهاز لا يمكن تقييد بوابته بسرعة أو لا يمكن التأكد من مستوى تعرضه، فتعاملوا معه كأصل عالي الخطورة: اعزلوه أو أخرجوه من الخدمة مؤقتًا حتى يمكن تطبيق التخفيف أو التحديث. هذا هو الامتداد العملي الأكثر أمانًا لتوصية تقييد أو تعطيل البوابة أثناء انتظار التصحيحات المناسبة ^[3][7].

2. طبّقوا التصحيحات الرسمية فور توفرها

لا يكفي إغلاق التعرض مؤقتًا. يجب تطبيق إصدارات PAN-OS المصححة من Palo Alto Networks بمجرد توفرها للفرع الذي تستخدمونه، ثم التحقق من أن البوابة لم تعد مكشوفة لشبكات غير موثوقة إلا عند ضرورة تشغيلية واضحة ^[1][21].

وبما أن مواعيد التصحيح والإصدارات النهائية قد تختلف بحسب فرع PAN-OS، اجعلوا استشارة Palo Alto الرسمية هي المرجع الحاسم لتحديد الإصدار المستهدف، ولا تعتمدوا فقط على جداول منشورة في تقارير ثانوية ^[7][21].

3. أضيفوا طبقات كشف ومنع مؤقتة

إذا كانت بيئتكم تدعم ذلك، فعّلوا Threat ID 510019 كطبقة إضافية للكشف أو المنع، وفق ما ورد في إرشادات الاستجابة، لكن لا تعتبروا هذا بديلًا عن تقييد البوابة أو تعطيلها أو تطبيق التصحيح ^[7].

ماذا عن الاستجابة للحوادث؟

أي جهاز كان مكشوفًا للإنترنت أو لشبكة غير موثوقة يجب أن يدخل فورًا في مسار فحص أمني، حتى لو لم تظهر مؤشرات واضحة. السبب بسيط: الثغرة قد تمنح تنفيذ أوامر بصلاحيات root، ما يعني أن المهاجم قد يحاول تغيير الإعدادات أو حذف آثار أو إنشاء وسائل بقاء داخل البيئة ^[1][10][15].

ابدأوا بالخطوات التالية:

• حفظ سجلات الجدار الناري والبوابة قبل تدويرها أو فقدانها.
• البحث عن حركة غير معتادة باتجاه User-ID Authentication Portal أو Captive Portal.
• مراجعة أي تغييرات إدارية أو إعدادات جديدة غير مفسرة.
• تدوير بيانات الاعتماد التي ربما مرّت عبر البوابة أو استُخدمت لإدارة الجهاز.
• مراقبة الاتصالات الخارجة غير المعتادة من الجدار الناري نفسه.
• افتراض أن الجهاز المكشوف ربما تعرّض لمحاولة استغلال، لا أن غياب الإنذار يعني السلامة.

ملاحظة خاصة للجهات الفيدرالية الأميركية

إدراج CVE-2026-0300 في كتالوج CISA KEV يعني أن الجهات المدنية التنفيذية الفيدرالية الأميركية مطالبة باتباع متطلبات المعالجة وفق BOD 22-01 والمواعيد المحددة في الكتالوج ^[16][18]. عمليًا، ينبغي أن تكون هذه الثغرة على رأس قائمة المخاطر اليومية: حصر، تخفيف فوري، عزل عند الحاجة، تصحيح، ثم تحقق واستجابة للحوادث.

القرار العملي

لا تنتظروا اكتمال التصحيحات لكل الفروع قبل التحرك. إذا كانت بوابة User-ID Authentication Portal مكشوفة، أغلقوا التعرض الآن. إذا تعذر ذلك، اعزلوا الجهاز. وبعد التصحيح، لا تعيدوا البوابة إلى الإنترنت كإعداد افتراضي. في هذه الحالة، تقليل سطح الهجوم بسرعة أهم من أي نقاش طويل حول احتمالية الاستغلال؛ فالاستغلال مؤكد بالفعل ^[1][21].