ثغرة حرجة في Keycloak تسمح بالاستيلاء على الحسابات عبر مسار استعادة كلمة المرور

كُشف عن ثغرة حرجة في Keycloak، نظام إدارة الهوية والدخول مفتوح المصدر، تحمل الرقم CVE-2026-18963، وتقع في المكوّن keycloak-services. وتسمح الثغرة لمهاجم لا يملك حسابًا بتغيير كلمة مرور أي مستخدم، بما في ذلك حسابات المشرفين (admin). وقيّمتها نشرات أمنية، منها نشرة CCB Belgium، بدرجة 9.1 من 10.

وتقع المشكلة في مسار reset-credentials، أي مسار “نسيت كلمة المرور”. ففي الوضع الطبيعي، يطلب المستخدم إعادة التعيين، فيرسل Keycloak إلى بريده رابطًا يحمل action token، ولا تنتقل الجلسة إلى خطوة إدخال كلمة مرور جديدة إلا بعد فتح هذا الرابط. وبسبب خلل في التحقق من حالة الجلسة، صار بالإمكان الانتقال إلى تلك الخطوة دون أن يُطلب الـ token أصلًا. أي أن رابط البريد، الذي يحمل كل الأمان في هذه العملية، أصبح اختياريًا.

وفُتح الـ issue الخاص بالثغرة على GitHub في 19 أغسطس 2026. وصدر الإصلاح في النسخة 26.7.2، ونُقل أيضًا إلى النسختين 26.6.6 و26.4.15. ولم يُرصد دليل على استغلالها حتى 24 أغسطس 2026.

ويُستخدم Keycloak عادة بديلًا مستضافًا ذاتيًا لخدمات مثل Auth0 وOkta، وهو خيار مناسب في حالات كثيرة، خاصة لمن يريد إبقاء بيانات الهوية داخل بنيته. لكن لهذا الخيار ثمنًا واضحًا. فلدى مزوّد الخدمة المُدارة، يُطبَّق الإصلاح دون تدخل من العميل. أما من يشغّل Keycloak على خوادمه، فالتحديث ينتظره حتى يطبّقه بنفسه.

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