CVE-2026-94609 — प्रतिनिधिक Group/User प्रबंधन के माध्यम से authentik विशेषाधिकार वृद्धि

goauthentik/authentik में एक विशेषाधिकार-वृद्धि भेद्यता के लिए राइट-अप और प्रूफ-ऑफ-कॉन्सेप्ट, जिसे 2026.2.7 / 2026.5.7 / 2026.8.2 में ठीक किया गया और CVE-2026-94609 (GHSA-h6c5-mpvq-j4jc) सौंपा गया।

मैं इस सलाह में श्रेय प्राप्त रिपोर्टरों में से एक था (@anthonyk2923 — श्रेय स्वीकृत)। यह रेपो उस विशिष्ट कोड पथ का दस्तावेज़ीकरण करता है जिसे मैंने स्वतंत्र रूप से पाया और रिपोर्ट किया, साथ ही एक PoC भी। प्रकाशित सलाह पूरे, व्यापक मुद्दे (समूह पदानुक्रम + भूमिका असाइनमेंट) को कवर करती है, जिसे कई स्वतंत्र शोधकर्ताओं ने रिपोर्ट किया और साथ में ठीक किया गया।

TL;DR

केवल एक नियमित, सामान्यतः-प्रतिनिधिक अनुमति — authentik_core.add_user_to_group (किसी समूह में सदस्य जोड़ें) — रखने वाला खाता मानक Groups API के माध्यम से स्वयं को या किसी अन्य उपयोगकर्ता को सीधे is_superuser=True के रूप में चिह्नित किसी मौजूदा समूह में जोड़ सकता था, और वह उपयोगकर्ता तुरंत एक वास्तविक authentik सुपरयूज़र बन गया। यह authentik_core.enable_group_superuser को कभी धारण किए बिना हुआ, जो विशेष रूप से इसी कार्रवाई को नियंत्रित करने के लिए डिज़ाइन की गई अनुमति है।

authentik ने इस बग के दर्पण-प्रतिबिंब संस्करण को पहले ही User पक्ष (किसी उपयोगकर्ता को सुपरयूज़र समूह असाइन करना) पर ठीक कर दिया था। समतुल्य जाँच Group पक्ष (उपयोगकर्ताओं को सुपरयूज़र समूह में असाइन करना) पर गायब थी।

पृष्ठभूमि

authentik समूह सदस्यता प्रबंधन के लिए दो जानबूझकर अलग RBAC अनुमतियों को मॉडल करता है:

• authentik_core.add_user_to_group — नियमित, प्रतिनिधिक सदस्यता प्रबंधन के लिए (जैसे एक "हेल्पडेस्क" या "टीम लीड" भूमिका जो रोज़मर्रा की टीम सूचियों का प्रबंधन करती है)।
• authentik_core.enable_group_superuser — किसी ऐसे समूह को देने या उसमें शामिल होने के कहीं अधिक संवेदनशील कार्य को नियंत्रित करने के लिए जिसका is_superuser=True ध्वज प्रत्येक सदस्य को पूर्ण authentik सुपरयूज़र बना देता है।

यह अलगाव ठीक इसलिए मौजूद है ताकि कोई संगठन सामान्य समूह प्रबंधन को व्यापक रूप से प्रतिनिधि बना सके, बिना सुपरयूज़र बनाने की क्षमता भी सौंपे।

authentik ने इस सटीक भ्रम को पहले ही एक बार ठीक किया था, संबंध के User पक्ष पर (PATCH /api/v3/core/users/{pk}/ के माध्यम से UserSerializer.validate_groups()), जिसे GHSA-h6x7-hjjc-wjc9 / CVE-2026-40172 (CVSS 8.1, High) के रूप में ट्रैक किया गया। फिक्स ने जोड़ा:

# 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(...)

भेद्यता

Group पक्ष पर सममित कोड पथ — किसी समूह में सदस्य जोड़ना, बजाय किसी उपयोगकर्ता में समूह जोड़ने के — को कभी समतुल्य जाँच नहीं मिली।

authentik/core/api/groups.py में GroupSerializer.validate_users() ने केवल 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 रखता है — या तो विश्व स्तर पर, या केवल एक विशिष्ट सुपरयूज़र समूह पर ऑब्जेक्ट-स्कोप्ड — उस समूह के users फ़ील्ड को PATCH करके किसी भी उपयोगकर्ता (स्वयं सहित) को जोड़ सकता है, और वह उपयोगकर्ता तुरंत एक वास्तविक authentik सुपरयूज़र बन जाता है।

add_user_to_group ठीक उसी प्रकार की अनुमति है जिसे authentik का स्वयं का सूक्ष्म-कणिक RBAC मॉडल 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 क्लाइंट-शैली PoC। यह एक लक्ष्य 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
• संबंधित, पहले ठीक किया गया सहोदर बग (User-पक्ष): GHSA-h6x7-hjjc-wjc9 / CVE-2026-40172
• authentik स्रोत: goauthentik/authentik

लाइसेंस

यह राइट-अप और PoC शैक्षिक और रक्षात्मक सुरक्षा अनुसंधान उद्देश्यों के लिए प्रदान किए गए हैं। अंतर्निहित प्रोजेक्ट के लिए authentik का स्वयं का लाइसेंस (MIT) देखें।