kyos-public/keycloak-cve-2026-18963-huntابحث عن آثار استغلال CVE-2026-18963 (الاستيلاء على الحساب دون مصادقة في Keycloak) في قاعدة بيانات Keycloak
سكربت psql يبحث في قاعدة بيانات Keycloak PostgreSQL عن آثار استغلال
CVE-2026-18963 (الاستيلاء غير المصادق عليه على الحساب عبر تدفق
إعادة تعيين بيانات الاعتماد).
نُشر بواسطة KYOS. كتبناه أثناء تحديث نشرات Keycloak التي نديرها، للتحقق من عدم تعرض أي حساب للاستيلاء خلال نافذة التعرض.
CVE-2026-18963 هي خلل في تدفق إعادة تعيين بيانات الاعتماد في
keycloak-services
(keycloak#51833). يمكن
لمهاجم غير مصادق عليه إكمال عملية إعادة تعيين كلمة المرور لأي مستخدم
دون النقر على رابط التحقق عبر البريد الإلكتروني، ثم تعيين كلمة مرور جديدة على
الحساب. لا يتطلب أي تفاعل من المستخدم.
الخطورة: حرجة، CVSS v3.1 9.1 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N)،
وفقًا لـ Red Hat و
NVD. السبب الجذري هو
التحقق غير السليم من الحالة في تدفق المصادقة، تم إصلاحه في
keycloak#51844.
| المسار | مُصلح في |
|---|---|
| 26.7.x | 26.7.2 (ملاحظات الإصدار) |
| 26.6.x | 26.6.6 |
| 26.4.x (LTS) | 26.4.15 |
| 26.8 | 26.8.0 |
كل الإصدارات الأقدم من تلك في المسارات المدعومة معرضة للخطر. الإصدارات خارج الدعم (26.5.x، 26.3 والأقدم) لا تحصل على إصلاح: افترض التعرض وقم بالترقية إلى مسار مُصلح. تذكر Red Hat أن RH-SSO 7 القديم غير متأثر؛ إصدار Red Hat من Keycloak 26.4/26.6 مُصلح في 26.4.15-1 / 26.6.6-1.
تعطيل إعادة تعيين كلمة المرور الذاتية يزيل نقطة الدخول المعرضة:
وحدة تحكم المشرف > إعدادات المجال > تسجيل الدخول > إيقاف "كلمة المرور المنسية"، لكل
مجال. عبر واجهة برمجة تطبيقات المشرف: PUT /admin/realms/{realm} مع
{"resetPasswordAllowed": false}.
يمنع هذا نقطة النهاية login-actions/reset-credentials ولكنه يمنع أيضًا
المستخدمين الشرعيين من إعادة تعيين كلمة المرور الخاصة بهم، لذا تعامل معه كإجراء مؤقت
حتى تقوم بالترقية. لاحظ أن Red Hat لا تدرج تخفيفًا معتمدًا لهذه
الثغرة؛ الترقية هي الحل الحقيقي الوحيد.
cve-2026-18963-keycloak-hunt.sql ينفذ أربعة استعلامات للقراءة فقط:
| الاستعلام | ما يجده |
|---|---|
| Q0 | ما إذا كان المجال يخزن أحداث تسجيل الدخول/المشرف على الإطلاق، ومدة صلاحيتها (TTL). إذا كانت الأحداث معطلة أو منتهية الصلاحية، فإن النتائج الفارغة في Q2/Q3 لا تثبت شيئًا. |
| Q1 | كل بيانات اعتماد كلمة المرور التي تم تعيينها داخل نافذة التعرض (credential.created_date). هذا هو الاستيلاء نفسه ويعمل حتى لو كان تسجيل الأحداث معطلاً. |
| Q2 | أحداث تسجيل الدخول لإعادة التعيين/بيانات الاعتماد، مع وضع علامة على أي إعادة تعيين مكتملة بدون SEND_RESET_PASSWORD في الـ 24 ساعة السابقة (no_email_before = t). هذه العلامة هي توقيع الثغرة: المهاجم لم يطلق البريد أبدًا. |
| Q3 | عمليات إعادة تعيين بيانات الاعتماد وعمليات تنفيذ الإجراءات عبر واجهة برمجة تطبيقات المشرف، لاستبعاد المسار الذي يقوده المشرف. |
# الافتراضي: المجال 'master'، النافذة منذ 2026-06-01
psql -U keycloak -d keycloak -f cve-2026-18963-keycloak-hunt.sql
# مجال ونافذة صريحان (نفّذ مرة واحدة لكل مجال، اقتبس القيم تمامًا هكذا)
psql -U keycloak -d keycloak \
-v realm="'myrealm'" -v since="'2026-05-01'" \
-f cve-2026-18963-keycloak-hunt.sql
اضبط since على وقت ما قبل نشر إصدارك المعرض مباشرة. على Kubernetes:
kubectl exec -it my-postgres-pod -- \
psql -U keycloak -d keycloak -v realm="'myrealm'" -v since="'2026-05-01'" \
-f - < cve-2026-18963-keycloak-hunt.sql
الصفوف في Q1 ليست تلقائيًا عمليات اختراق. طابق كلًا منها مع سبب شرعي معروف (إعادة تعيين ذاتية، إجراء من مكتب المساعدة، تسجيل جديد) و تعامل مع أي شيء غير مفسر كمرشح للاستيلاء.
صفوف Q2 التي تحتوي على no_email_before = t على RESET_PASSWORD أو UPDATE_CREDENTIAL
أو UPDATE_PASSWORD هي أقوى مؤشر على استغلال هذه الثغرة.
اربط عمود ip_address بسجلات الوصول الخاصة بك.
تحقق من Q0 أولاً: أحداث تسجيل الدخول تنتهي صلاحيتها (events_expiration) وقد تكون معطلة
تمامًا. Q1 لا تنتهي صلاحيته، لذا فهو الفحص الأكثر موثوقية.
MIT، انظر LICENSE. مُقدم كما هو، بدون ضمان.