CVE-2026-18963 — تجاوز إعادة تعيين بيانات الاعتماد في Keycloak → استيلاء غير مصادق عليه على الحساب

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

المتأثر: Keycloak 26.0.0 – 26.7.1. تم الإصلاح في الإصدار 26.7.2.

هل أنا معرّض للخطر؟

أمر واحد. لا يتطلب اسم مستخدم صالحًا، ولا آثار جانبية — لا يرسل بريدًا إلكترونيًا، ولا يكتب على أي حساب، ويتوقف قبل الخطوة القابلة للاستغلال.```bash git clone https://github.com/Snizi/CVE-2026-18963-Exploit cd CVE-2026-18963-Exploit

python3 cve_2026_18963_poc.py
--base https://sso.example.com --realm YOUR_REALM
--client-id account
--redirect-uri https://sso.example.com/realms/YOUR_REALM/account/
--safe-check

Python 3.9+، المكتبة القياسية فقط. لا شيء لتثبيته.

| الخروج | الحكم | المعنى |
|:---:|---|---|
| `0` | 🔴 **قابل للاستغلال** | تم تقديم بوابة البريد الإلكتروني المتوقفة — العيب نفسه |
| `2` | 🟢 **مُصحَّح** | انحرف التدفق إلى تسجيل الدخول وبقي هناك (الإصلاح #51844 موجود) |
| `2` | 🟡 **مُخفَّف** | إعادة تعيين بيانات الاعتماد غير قابلة للوصول — *نسيت كلمة المرور* معطّلة. **ليس تصحيحًا.** |
| `3` | ⚪ **غير حاسم** | استجابة غير معترف بها — **لا تقرأ هذا على أنه نجاح** |

شغّله لكل نطاق (realm) — *نسيت كلمة المرور* إعداد خاص بكل نطاق، و`master` يُحتسب.
التفاصيل، ولماذا لا يحتاج الفحص إلى مستخدم ولا يلمس شيئًا، في
[§4a](#4a-safe-detection---safe-check--start-here).

**هل تعرف بالفعل أنك مكشوف؟** انتقل إلى [المعالجة](#8-remediation) و
[الكشف / اصطياد التهديدات](#9-detection).

### جرّبه بدون هدف

يأتي المستودع مع مختبر يُشغّل إصدارًا قابلًا للاستغلال **26.7.1** وإصدارًا مُصحَّحًا **26.7.2**
جنبًا إلى جنب ضد نطاق متطابق، بالإضافة إلى صندوق بريد لمراقبة وصول بريد إعادة التعيين
وبقائه غير مقروء أثناء الاستيلاء على الحساب:```bash
cd lab && docker compose up -d

python3 ../cve_2026_18963_poc.py --base http://localhost:8080 \
  --realm poc --client-id poc-app --safe-check   # VULNERABLE
python3 ../cve_2026_18963_poc.py --base http://localhost:8100 \
  --realm poc --client-id poc-app --safe-check   # PATCHED

⚠️ الاختبار المصرّح به فقط

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

المراجع: keycloak#51833 · GHSA-4gv3-mc9p-5wqc · الإصلاح keycloak#51844

المحتويات

1. السبب الجذري
2. الإصدارات المتأثرة (بما في ذلك الخطوط القديمة)
3. المختبر
4. الاستخدام
5. سمات تسجيل الدخول المخصصة
6. الفجوة المعروفة — PKCE
7. التحقق الذي تم إجراؤه
8. المعالجة
9. الكشف
المؤلف

1. السبب الجذري

عيبان متسلسلان. لا يمكن استغلال أي منهما بمفرده.

العيب 1 — علامة غير محددة النطاق ولاصقة

services/src/main/java/org/keycloak/authentication/DefaultAuthenticationFlow.java

processAction() — أي طلب POST يحمل مفتاح النموذج tryAnotherWay:```java processor.getAuthenticationSession().setAuthNote( AuthenticationProcessor.AUTHENTICATION_SELECTOR_SCREEN_DISPLAYED, "true"); return createSelectAuthenticatorsScreen(model);

الملاحظة هي **قيمة منطقية بسيطة بدون أي سجل لأي مجموعة تنفيذ تنتمي إليها**. يتم مسحها فقط في الفرع الذي يعالج معامل `authenticationExecution` المُرسل. احذف هذا المعامل — كما يفعل هذا الإثبات المفاهيمي (PoC) طوال الوقت — وستبقى العلامة مضبوطة طوال عمر جلسة المصادقة.

`processFlow()` — بينما تكون العلامة صحيحة (truthy)، يتم تخطي تقييم التدفق الطبيعي:```java
if (Boolean.parseBoolean(authSession.getAuthNote(AUTHENTICATION_SELECTOR_SCREEN_DISPLAYED))) {
    String lastExecutionId = authSession.getAuthNote(CURRENT_AUTHENTICATION_EXECUTION);
    if (lastExecutionId != null) {
        AuthenticationExecutionModel executionModel =
            realm.getAuthenticationExecutionById(lastExecutionId);
        if (executionModel != null)
            return createSelectAuthenticatorsScreen(executionModel);   // <-- attacker-usable form
    }
}

يقدّم نموذجًا قابلًا للإرسال يستهدف أي تنفيذ متوقف حاليًا، بدلًا من إبقاء الجلسة مثبّتة على "انتظار البريد الإلكتروني".

الرابط هو processResult() case FORK: — عندما يتم تشغيل إرسال بريد إعادة التعيين، فإنه يختم CURRENT_AUTHENTICATION_EXECUTION = <reset-credential-email execution id> ويُفرّع المتصفح إلى صفحة تسجيل الدخول. التنفيذ المتوقف هو تحديدًا بوابة البريد الإلكتروني.

العيب 2 — بوابة البريد الإلكتروني لا تتحقق أبدًا من رمز الإجراء

`services/src/main/java/org/keycloak/authentication/authenticators/resetcred/ResetCredentialEmail.java````java @Override public void action(AuthenticationFlowContext context) { context.getUser().setEmailVerified(true); context.success(); }

Unconditional. لا شيء يتحقق من أن التدفق استُؤنف بواسطة رمز إجراء صالح،
لذا فإن *الوصول* إلى `action()` يُعتبر مكافئًا لإثبات السيطرة على صندوق البريد.

### السلسلة```
tryAnotherWay POST            → sticky AUTHENTICATION_SELECTOR_SCREEN_DISPLAYED="true"
submit victim identifier      → mail sent to victim, e-mail execution parked (FORK)
re-enter reset-credentials    → sticky flag serves a form targeting the parked e-mail execution
POST that form                → ResetCredentialEmail.action() → success() → gate bypassed
                              → flow advances to UPDATE_PASSWORD → attacker sets the password

ستة طلبات HTTP، بدون مصادقة، وبدون معامل authenticationExecution في أي نقطة.

الإصلاح (PR #51844)

الملاحظة الآن تخزّن model.getId()، وprocessFlow() تحترمها فقط عندما تساوي CURRENT_AUTHENTICATION_EXECUTION، وإلا تزيلها. في الهجوم يختلف الاثنان (معرّف اختيار المستخدم مقابل معرّف بوابة البريد الإلكتروني) — وهذا بالضبط ما يكتشفه التصحيح، وبالضبط الإشارة التي يعتمد عليها --safe-check.
ResetCredentialEmail.action() يتطلب الآن context.getUser().getId().equals(authNote(ACTION_TOKEN_USER_ID)) وإلا يفشل مع INVALID_USER.

2. الإصدارات المتأثرة (بما في ذلك الخطوط القديمة)

الخط	قابل للاستغلال	إصلاح المجتمع
القديم (Keycloak القائم على WildFly، ≤ 17)	غير متأثر	—
Quarkus 17 – 25.x	غير متأثر	—
26.0	26.0.0 – 26.0.17	لا يوجد
26.1	26.1.0 – 26.1.5	لا يوجد
26.2	26.2.0 – 26.2.16	لا يوجد
26.3	26.3.0 – 26.3.5	لا يوجد
26.4	26.4.0 – 26.4.14	26.4.15 (وسم النقل الخلفي من المورّد)
26.5	26.5.0 – 26.5.7	لا يوجد
26.6	26.6.0 – 26.6.5	26.6.6 (وسم النقل الخلفي من المورّد)
26.7	26.7.0 – 26.7.1	26.7.2

CVE-2026-18963-Exploit

الأكثر شعبية