كل مؤسسة لديها جهاز يقرر من أنت. تسجّل الدخول مرة واحدة، فيتحقق من الجلسة ويصدر رمزًا (token) ويخبر كل التطبيقات خلفه أن تثق بك. وفي كثير من المؤسسات، هذا الجهاز هو F5 BIG-IP Access Policy Manager (APM) بصفته خادم تخويل OAuth.
في 22 سبتمبر، أكدت شركة F5 أن المهاجمين ينفّذون شيفرتهم عليه بالفعل. من دون تسجيل دخول. الثغرة مسجلة باسم CVE-2026-94127 بتقييم 9.8 (CVSS v3.1)، ويجب أن يدخل تصحيحها في جدولك اليوم، لا في الربع القادم.
الخلاصة السريعة
- CVE-2026-94127 هي تجاوز في مخزن البيانات المؤقت على الكومة (CWE-122) في BIG-IP APM، بتقييم 9.8 وفق CVSS v3.1 و9.3 وفق v4.0.
- لا وجود لها إلا عندما يكون APM مُهيأ كـ خادم تخويل OAuth، أي سياسة وصول (Access Policy) مع ملف تعريف OAuth على الخادم الافتراضي نفسه.
- مرور حركة بيانات خبيثة موجّهة تحديدًا إلى ذلك الخادم الافتراضي يؤدي إلى تنفيذ شيفرة عن بُعد من مهاجم غير مُصادق عليه.
- أعلنت F5 الثغرة في 22 سبتمبر وأصدرت تصحيحات هندسية. وأضافتها وكالة CISA إلى كتالوج KEV في اليوم نفسه، ومنحت الوكالات الفيدرالية مهلة حتى 25 سبتمبر.
- وبصياغة F5 نفسها: «We have learned that this vulnerability has been exploited».
ثلاثة أيام بين التنبيه والمهلة الفيدرالية. هذه هي حسابات التصحيح الجديدة، وهي ليست خطأً مطبعيًا.
ما هي الثغرة بالضبط
BIG-IP APM هو الوحدة التي تدير الوصول إلى تطبيقاتك: تنفّذ سياسة الوصول، وتتحقق من حالة الجهاز، وتصدر الرموز التي تقبلها التطبيقات اللاحقة كدليل هوية.
التهيئة المعرّضة للخطر ضيقة لكنها شائعة: سياسة وصول APM مع ملف تعريف خادم تخويل OAuth على الخادم الافتراضي نفسه. وعندما يكون النظام مُهيأ بهذه الطريقة، يمكن لحركة بيانات مشوّهة موجّهة إلى الخادم الافتراضي أن تسبب تجاوزًا في الكومة وتسليم التنفيذ للمهاجم.
الفروع المتأثرة وإصلاحاتها:
- 21.1 — النسخة 21.1.0 قبل التصحيح ←
Hotfix-BIGIP-21.1.0.2.0.30.22-ENG - 17.5 — من 17.5.0 إلى 17.5.1 ←
Hotfix-BIGIP-17.5.1.9.0.160.12-ENG - 17.1 — من 17.1.0 إلى 17.1.3 ←
Hotfix-BIGIP-17.1.3.5.0.41.14-ENG
وهناك خبر جيد واحد. إذا كان APM يعمل فقط كـ عميل أو خادم موارد OAuth، أي دون ملفات تعريف خادم تخويل مُهيأة، فأنت غير متأثر. وقد حدّثت F5 سجل CVE عند الساعة 00:45 بتوقيت UTC من 23 سبتمبر لحصر الشرط تحديدًا في دور خادم التخويل، ما يعني أن الصياغات الأولى لـ CERT-EU وكتالوج KEV كانت أوسع من النطاق النهائي. لذا تحقق من الدور، لا من رقم الإصدار فقط.
لماذا لن تنقذك إغلاقات واجهة الإدارة
الغريزة بعد أي ثغرة يوم صفر في جهاز طرفي هي إخفاء واجهة الإدارة خلف خادم عبور وإنهاء الموضوع. هذا لا يفيد شيئًا هنا.
المشكلة في طبقة البيانات. الحركة الخبيثة تذهب إلى الخادم الافتراضي الذي يدير تدفقات OAuth، أي العنوان نفسه الذي يفترض أن يصل إليه مستخدموك ومستخدمو شركائك. وتؤكد F5 أنه لا يوجد تعرّض في طبقة التحكم، والأهم: أن أنظمة BIG-IP في وضع Appliance معرّضة أيضًا. ووضع Appliance هو بالضبط التحصين الذي يطبقه الناس لجعل هذه الأجهزة أصعب في الاستغلال.
إذن التعرّض ليس «من يستطيع الوصول إلى منفذ الإدارة»، بل «من يستطيع الوصول إلى نقطة الهوية». وفي معظم المعماريات، هذا يعني الإنترنت.
وهذه الأجهزة ليست نادرة. يتابع Shadowserver حاليًا أكثر من 14,700 عنوان IP يحمل بصمة BIG-IP APM. الرقم لا يخبرنا كم منها دون تصحيح أو بتهيئة خاطئة، لكنه يخبرنا بمدى جاذبية هذه الفئة من الأهداف.
كيف تعرف إن كنت قد تعرّضت للهجوم بالفعل
هنا تصبح القصة مزعجة. فقد أعلنت F5 الثغرة كيوم صفر، أي أن التفاصيل القابلة للاستغلال كانت موجودة في البرّية قبل أن يتوفر لك تصحيح تُثبّته. وكل ما يأتي كيوم صفر يستهلك وقتًا سابقًا غير معروف.
نشرت F5 مؤشرات يمكن للمدافعين البحث عنها. والنمط الذي يستحق التنبيه هو سلسلة، لا حدثًا منفردًا:
- فشل متكرر في مصادقة OAuth على الخادم الافتراضي لـ BIG-IP APM.
- أوامر مريبة تظهر بعد ذلك بوقت قصير.
- حدث TMM SIGABRT يتبعها مباشرة.
إذا رأيت هذه السلسلة في نافذة زمنية واحدة، فاعتبرها اختراقًا مؤكدًا لا فرضية. فالخطوات اللاحقة في النمط، أي أوامر ما بعد الاستغلال، لا وجود لها إلا إذا دخل شيء ما أولًا.
وإذا لم تستطع تثبيت التصحيح فورًا، فقد نشرت F5 قاعدة iRule عبر قنوات الدعم يمكن ربطها بالخادم الافتراضي المتأثر كتخفيف مؤقت. والمؤقت يعني ذلك حرفيًا: إنه يمنحك الساعات اللازمة لجدولة الإصلاح الحقيقي، ولا يغني عنه.
ما الذي سنفعله هذا الأسبوع
- دقّق في التهيئة، لا في لافتة الإصدار. لا يمكن لفحص عن بُعد أن يخبرك إن كانت ملفات تعريف خادم تخويل OAuth مُهيأة. اسحب التهيئة وحدّد كل خادم افتراضي يجمع بين سياسة وصول وملف تعريف OAuth.
- ثبّت التصحيحات المسمّاة للفروع المتأثرة، بدءًا من كل ما هو مكشوف للإنترنت. وإذا كان نافذة الصيانة أمرًا لا مفر منه، فضع قاعدة iRule أولًا وسجّل الاستثناء.
- ابحث عن سلسلة المؤشرات إلى ما قبل 22 سبتمبر. كان المهاجمون يعرفون الثغرة قبل التنبيه؛ فابدأ مراجعة السجلات من تاريخ أسبق من تاريخ الإعلان.
- دوّر المفاتيح عند الشك، لا عند اليقين. إذا ظهرت السلسلة، فافترض أن الرموز وأسرار العملاء التي أصدرها ذلك الجهاز قد تكون مخترقة. دوّر أسرار عملاء OAuth، وراجع التعامل مع مفاتيح التوقيع، وأبطل الجلسات القائمة.
- ارسم نطاق التأثير. كل تطبيق يثق بذلك الخادم كمزوّد هوية يقع بعد هذه الثغرة. والتطبيقات التي تقبل الرموز دون إعادة التحقق من المطالبات (claims) هي أول ما يجب أن تنظر إليه.
- اختبر استعادة طبقة الهوية. مدير الوصول لديك يقف أمام كل شيء تقريبًا. إذا سقط، كيف تعود إلى الداخل؟ معظم الفرق التي نتحدث إليها لم تتمرّن على ذلك أبدًا.
الخلاصة
أصبحت البنية التحتية للهوية جوهرة التاج، والمهاجمون يوافقون على ذلك. كتبنا قبل يومين عن أجهزة VPN من Check Point، واليوم يأتي دور مدير الوصول من F5. والنمط ثابت: الأجهزة التي تقرر من يدخل هي الأجهزة التي تستحق الكسر، وثغراتها لا تهتم بقيودك على واجهة الإدارة.
صحّح هذا بسرعة، لكن لا تتوقف عند التصحيح. فمهلة الثلاثة أيام إشارة إلى كم تتبع عمليات الاستغلال الإعلان بشكل سريع. الكشف وتدقيق التهيئة ومسار استعادة مُتمرَّن عليه هي ما يحملك في الأيام التي لا يتوفر فيها إصلاح.
وإذا لم تكن متأكدًا مما إذا كان نشر BIG-IP APM لديك يعمل كخادم تخويل OAuth، فهذا عدم اليقين هو المخاطرة. لنغلقه.