ثغرات بلاك هات 2026 في منصات جافا المؤسسية: لماذا نظامك الداخلي ليس آمنا

ثغرات بلاك هات 2026 في منصات جافا المؤسسية: لماذا نظامك الداخلي ليس آمنا

في الخامس من أغسطس 2026 عرض باحثون من شركة Novee بقيادة ليدور بن شتريت، في مؤتمر بلاك هات الأمريكي، بحثا كشف اثنتي عشرة ثغرة في أربع منصات جافا مؤسسية، من بينها سلسلتان حرجتان تسمحان بتنفيذ كود على الخادم دون أي تسجيل دخول، في منصة سير العمل Bonita BPM ونظام Apache OFBiz المفتوح لتخطيط موارد المؤسسات. الخلاصة العملية لأي صاحب منشأة: النظام الذي تظنه محميا لأنه داخلي يمكن الوصول إليه بطلبين عبر المتصفح إذا كان منشورا على الإنترنت وغير محدث، والحماية الحقيقية تبدأ بجرد أنظمتك وتحديثها، لا بالثقة في جدار الشبكة.

ماذا اكتشف الباحثون بالضبط

البحث لم يبن على ثغرة واحدة مذهلة، بل على تجميع أخطاء صغيرة شائعة في الطبقة الوسيطة: اختلافات في طريقة قراءة عنوان الرابط، حماية ناقصة على مستوى معالجات الطلبات، مفاتيح تشفير مكتوبة داخل الكود، وتقييم غير آمن للقوالب. كل واحدة منها لا تبدو خطيرة وحدها، ولهذا تمر في المراجعات وتصنف منخفضة الأولوية. لكن تركيبها معا ينتج مسارا كاملا من زائر مجهول إلى صلاحية تنفيذ أوامر على الخادم. من بين الاثنتي عشرة ثغرة، أربع تعمل قبل المصادقة، وواحدة تكسر العزل داخل بيئة التنفيذ.

سلسلة BadBonita: ثلاث نقاط ضعف تصنع اختراقا كاملا

السلسلة الأولى تصيب Bonita BPM في الإصدار 10.4.3، وتبدأ بتجاوز المصادقة عبر ثلاث نقاط ضعف مترابطة: تجاوز المسار باستخدام الصيغة ..;، ومطابقة المرشح الأمني على جزء من النص بدل النص الكامل، ثم منطق إعادة توجيه الطلب داخليا. النتيجة أن الطلب يصل إلى واجهة برمجية داخلية كان يفترض ألا يراها أحد من الخارج. هذه الواجهة تستقبل XML غير موثوق وتمرره مباشرة إلى مكتبة XStream التي تفككه، وعبر سلسلة أدوات معروفة في مكتبة Commons Collections ينتهي المسار بتنفيذ أوامر Groovy على الخادم.

لاحظ أن أيا من هذه الخطوات لا يتطلب كلمة مرور مسربة ولا هندسة اجتماعية ولا وصولا سابقا. كل ما يحتاجه المهاجم هو أن يكون النظام قابلا للوصول عبر الشبكة.

OFBiz: مفتاح توقيع منشور في مستودع مفتوح

الثغرة الثانية، المسجلة تحت الرقم CVE-2026-31986 وتصنيفها حرج، تصيب Apache OFBiz في الإصدار 24.09.05 عند تفعيل الدخول الموحد. المشكلة أن مفاتيح التوقيع الافتراضية موجودة في الكود المصدري المنشور علنا، وبما أن كثيرا من عمليات التركيب تبقي القيم الافتراضية كما هي، يستطيع المهاجم توليد رمز دخول موحد صالح باسم حساب مدير. بعد ذلك يمر عبر قائمة منع كانت تحاول حجب كلمات مثل java وprocess وimport، لكنها حساسة لحالة الأحرف وتفحص أنماطا محددة، فيكفي تغيير حالة حرف أو استخدام اسم صنف بديل مستورد تلقائيا للمرور منها. النتيجة النهائية: طلبان من نوع GET بلا مصادقة يكفيان للوصول إلى تنفيذ الكود على أي تركيب يعمل فيه الدخول الموحد.

لماذا يعنيك هذا تحديدا

لأن هذين النظامين ليسا أدوات هامشية. OFBiz نظام ERP مفتوح المصدر تبني عليه شركات كثيرة إدارة المخزون والمشتريات والفوترة، وBonita محرك سير عمل تدار به الموافقات والإجراءات الداخلية. من يصل إلى هذين المكانين لا يقرأ بيانات فقط، بل يقف في قلب دورة الأعمال: أوامر الشراء، أسعار الموردين، بيانات الموظفين، وسجل العملاء. وقد أفاد الباحثون بأن الجهتين أصدرتا نسخا معالجة ضمن مهلة الإفصاح المعتادة البالغة تسعين يوما، أي أن التحديث متاح، والمسؤولية الآن على من يشغل النظام لا على من طوره.

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

ماذا تفعل هذا الأسبوع

• اجرد أنظمتك: قائمة مكتوبة بكل نظام تشغله، وإصداره، وهل هو مفتوح على الإنترنت أم لا، ومن المسؤول عنه اسميا.
• حدث Bonita وOFBiz فورا إلى الإصدارات المعالجة إذا كنت تشغل أيا منهما، وراجع صفحة الأمان الرسمية لأباتشي قبل التحديث.
• استبدل كل مفتاح تشفير أو مفتاح توقيع افتراضي جاء مع النظام. أي قيمة موجودة في وثائق المنتج ليست سرا.
• أغلق بوابات الإدارة أمام الإنترنت المفتوح، واجعل الوصول إليها عبر شبكة خاصة أو قائمة عناوين محددة.
• ألغ النسخ التجريبية والنطاقات الفرعية القديمة التي لم تعد تستخدم، فهي أسهل هدف وأقلها متابعة.
• فعل سجلات الوصول واحتفظ بها، فبدون سجل لن تعرف لاحقا ما إذا كان أحد قد دخل أصلا.

الدرس الهندسي: الشبكة الداخلية ليست حدا أمنيا

التوصية الأهم التي خرج بها الباحثون هي أن التوجيه الداخلي يجب أن يعامل بمستوى الحماية نفسه المطبق على الإنترنت. الفكرة القديمة القائلة إن ما خلف الجدار آمن سقطت عمليا: أي ثغرة تجاوز مصادقة واحدة تحول كل واجهة داخلية إلى واجهة عامة. ومعها ثلاث قواعد هندسية تستحق أن تدخل معايير التطوير عندك:

لا تعتمد على قوائم المنع لحماية عملية خطرة. إذا كان تنفيذ التعابير البرمجية غير ضروري في مسار ما، احذفه من الأساس بدل محاولة تصفيته.

القاعدة الثانية ألا تربط عملية حساسة بخيار إعدادات أو تفضيل مستخدم يمكن تغييره من داخل النظام. والثالثة أن تراجع منطق مرشحات المصادقة بحثا عن أي مطابقة على جزء من النص، لأنها أكثر الأخطاء تكرارا وأسهلها استغلالا. عند بناء أنظمة أعمال جديدة نعتمد في أوريجامي هذا المبدأ افتراضيا: صلاحيات صريحة عند كل واجهة، ولا اعتماد على موقع الطلب داخل الشبكة.

البعد النظامي في السعودية

إذا كان النظام المخترق يحتوي بيانات أفراد داخل المملكة، فالمسألة لم تعد تقنية فقط. نظام حماية البيانات الشخصية يلزم جهة التحكم باتخاذ التدابير اللازمة لحماية البيانات وبالإبلاغ عن الحوادث التي تمس خصوصيتها. والهيئة الوطنية للأمن السيبراني تنشر ضوابط أساسية تشمل إدارة الثغرات والتحديثات وإدارة الأصول، وهي بالضبط الضوابط التي كانت ستمنع هذه السلسلة. تشغيل إصدار قديم من نظام معروفة ثغرته ومتاح ترقيعه موقف يصعب الدفاع عنه أمام أي مراجعة.

القاعدة البسيطة: عامل التحديث الأمني كالتزام تشغيلي شهري له مالك وتاريخ، لا كمهمة طارئة تنفذ بعد وقوع الحادث.

المصادر

• Help Net Security — تفاصيل سلسلتي التنفيذ عن بعد قبل المصادقة وCVE-2026-31986: helpnetsecurity.com
• صفحة الأمان الرسمية لمشروع Apache OFBiz: ofbiz.apache.org/security.html
• الهيئة الوطنية للأمن السيبراني — الضوابط والأطر التنظيمية: nca.gov.sa
• الهيئة السعودية للبيانات والذكاء الاصطناعي — نظام حماية البيانات الشخصية: sdaia.gov.sa