CVE-2026-94609 — تصعيد الصلاحيات في authentik عبر إدارة المجموعات/المستخدمين المفوّضة

تحليل وإثبات مفهوم لثغرة تصعيد صلاحيات في goauthentik/authentik، تم إصلاحها في 2026.2.7 / 2026.5.7 / 2026.8.2 وتم تعيين CVE-2026-94609 لها (GHSA-h6c5-mpvq-j4jc).

كنت أحد المُبلّغين المُعترف بهم في هذا التنبيه (@anthonyk2923 — تم قبول الإسناد). يوثّق هذا المستودع مسار الكود المحدد الذي اكتشفته وأبلغت عنه بشكل مستقل، بالإضافة إلى إثبات مفهوم. يغطي التنبيه المنشور المشكلة الكاملة والأوسع (التسلسل الهرمي للمجموعات + إسناد الأدوار)، والتي أبلغ عنها عدة باحثين مستقلين وتم إصلاحها معًا.

باختصار

حساب يمتلك فقط صلاحية روتينية وشائعة التفويد — authentik_core.add_user_to_group (إضافة أعضاء إلى مجموعة) — كان بإمكانه إضافة نفسه أو أي مستخدم آخر مباشرةً إلى مجموعة موجودة تحمل علامة is_superuser=True عبر واجهة Groups API القياسية، ويصبح ذلك المستخدم فورًا مستخدمًا خارقًا حقيقيًا في authentik. حدث هذا دون امتلاك authentik_core.enable_group_superuser إطلاقًا، وهي الصلاحية المصممة تحديدًا للبوابة على هذا الإجراء بالذات.

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

الخلفية

تُنمذج authentik صلاحيتين منفصلتين عمدًا في RBAC لإدارة عضوية المجموعات:

• authentik_core.add_user_to_group — مخصصة لإدارة العضوية الروتينية المفوّضة (مثل دور "مكتب المساعدة" أو "قائد الفريق" الذي يدير قوائم الفريق اليومية).
• authentik_core.enable_group_superuser — مخصصة للبوابة على الفعل الأكثر حساسية المتمثل في منح أو الانضمام إلى مجموعة تجعل علامة is_superuser=True فيها كل عضو مستخدمًا خارقًا كاملًا في authentik.

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

كانت authentik قد أصلحت هذا الالتباس بالذات مرة واحدة، على جانب المستخدم من العلاقة (PATCH /api/v3/core/users/{pk}/ عبر UserSerializer.validate_groups())، والمتتبَّع باسم GHSA-h6x7-hjjc-wjc9 / CVE-2026-40172 (CVSS 8.1، عالية). أضاف الإصلاح:

# authentik/core/api/users.py (fixed)
def validate_groups(self, groups: list) -> list:
    """Require enable_group_superuser permission when adding a user to a superuser group."""
    ...
    for group in groups:
        if not group.is_superuser:
            continue
        if group in current_groups:
            continue
        if not request.user.has_perm("authentik_core.enable_group_superuser"):
            raise ValidationError(...)

الثغرة

مسار الكود المتماثل على جانب المجموعة — إضافة أعضاء إلى مجموعة، بدلًا من إضافة مجموعات إلى مستخدم — لم يتلقَّ الفحص المكافئ أبدًا.

GroupSerializer.validate_users() في authentik/core/api/groups.py تحقق فقط من add_user_to_group، ولم يفحص self.instance.is_superuser إطلاقًا:

# authentik/core/api/groups.py (vulnerable)
def validate_users(self, users: list) -> list:
    """Require add_user_to_group permission when adding new members via group PATCH."""
    request: Request = self.context.get("request", None)
    if not request:
        return users
    if not self.instance:
        return users
    current_user_pks = set(self.instance.users.values_list("pk", flat=True))
    new_users = [u for u in users if u not in current_user_pks]
    if not new_users:
        return users
    has_perm = request.user.has_perm(
        "authentik_core.add_user_to_group"
    ) or request.user.has_perm("authentik_core.add_user_to_group", self.instance)
    if not has_perm:
        raise ValidationError(_("User does not have permission to add members to this group."))
    return users

لا يوجد أي حارس if self.instance.is_superuser: require enable_group_superuser في أي مكان في هذه الدالة. ونتيجة لذلك:

أي مستدعٍ يمتلك add_user_to_group — سواء على المستوى العام، أو مقيّدًا بكائن مجموعة مستخدم خارق واحدة محددة — يمكنه إرسال PATCH إلى حقل users لتلك المجموعة لإضافة أي مستخدم (بما في ذلك نفسه)، ويصبح ذلك المستخدم مستخدمًا خارقًا حقيقيًا في authentik فورًا.

add_user_to_group هي بالضبط نوع الصلاحية التي يشجّع نموذج RBAC دقيق التفاصيل الخاص بـ authentik على تفويضها على نطاق واسع وبشكل مستقل عن enable_group_superuser — مثلًا لدور مخصص "مدير مستخدمين" أو "مكتب مساعدة". الاختبار الموجود authentik/core/tests/test_groups_api.py::test_patch_users_with_global_perm أظهر بالفعل أن منحًا عامًا لـ add_user_to_group (بدون أي تقييد بكائن إطلاقًا) كافٍ لإرسال PATCH لإضافة أعضاء إلى أي مجموعة في النظام — لكن ذلك الاختبار لم يجرّب أبدًا مجموعة تحمل is_superuser=True، فمرّت الفجوة دون اكتشاف.

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

التأثير

تصعيد صلاحيات كامل من "أي حساب يمتلك صلاحية روتينية شائعة التفويد لعضوية المجموعات" إلى "مستخدم خارق كامل في authentik" — وهو ما يتحكم بكل مستأجر، وبالدخول الموحّد SSO لكل تطبيق لاحق، وبكل حساب مستخدم، وبكل الأسرار/الشهادات التي تديرها authentik، وبإعدادات النظام بالكامل.

إثبات المفهوم

CVE-2026-94609.py إثبات مفهوم مستقل بأسلوب عميل HTTP مباشر. يأخذ عنوان URL هدفًا ورمز API لحساب منخفض الصلاحيات (يمتلك فقط add_user_to_group)، واختياريًا مجموعة هدف/ضحية، ثم يحاول نفس التصعيد عبر الـ API الحقيقي:

# Check your own deployment for the bug, no mutation:
python3 exploit_CVE-2026-94609.py --url https://authentik.example.com \
    --token <low-priv-api-token> --group "superadmins" --check-only

# List superuser groups reachable to this token:
python3 exploit_CVE-2026-94609.py --url https://authentik.example.com \
    --token <low-priv-api-token> --list-groups

# Attempt the actual escalation (self, or a named/PK victim):
python3 exploit_CVE-2026-94609.py --url https://authentik.example.com \
    --token <low-priv-api-token> --group "superadmins" --victim jdoe

يتطلب فقط pip install requests. للاستخدام المصرّح به فقط — شغّل هذا ضد الأنظمة التي لديك تصريح صريح باختبارها.

الإصدارات المتأثرة / المُرقّعة

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

المراجع

• التنبيه الرسمي: GHSA-h6c5-mpvq-j4jc
• مدخل NVD: CVE-2026-94609
• خطأ شقيق ذو صلة، تم إصلاحه سابقًا (جانب المستخدم): GHSA-h6x7-hjjc-wjc9 / CVE-2026-40172
• مصدر authentik: goauthentik/authentik

الترخيص

يُقدَّم هذا التحليل وإثبات المفهوم لأغراض تعليمية وبحثية في الأمن الدفاعي. راجع ترخيص authentik نفسه (MIT) للمشروع الأساسي.