CVE-2026-94609 — 委任されたグループ/ユーザー管理を介した authentik の権限昇格

goauthentik/authentik の権限昇格脆弱性に関する 解説記事と概念実証（PoC）。本脆弱性は 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 は、グループメンバーシップ管理のために、意図的に 分離された 2 つの 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 を持つ呼び出し元 — グローバルに、または特定の 1 つのスーパーユーザーグループにオブジェクトスコープで — は、そのグループの 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 と 低権限アカウント (add_user_to_group のみを持つ) の API トークン、 オプションでターゲットグループ/被害者を受け取り、実際の 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) を参照してください。