CVE-2026-94609 — authentik 通过委派组/用户管理实现权限提升

关于 goauthentik/authentik 中一个权限提升漏洞的分析文章与概念验证， 该漏洞已在 2026.2.7 / 2026.5.7 / 2026.8.2 中修复，并被分配为 CVE-2026-94609 (GHSA-h6c5-mpvq-j4jc)。

我是该公告中受致谢的报告者之一 (@anthonyk2923 — 致谢已接受)。 本仓库记录了我独立发现并报告的特定代码路径，以及一个 PoC。已发布的公告涵盖了 更广泛、更完整的整体问题（组层级 + 角色分配），该问题由多位独立研究人员 报告并一并修复。

摘要

一个仅拥有常规、通常会被委派的权限的账户—— authentik_core.add_user_to_group（将成员添加到组）——可以通过标准的 Groups API 将自己或任何其他用户直接添加到已标记 is_superuser=True 的现有组中， 而该用户会立即成为真正的 authentik 超级用户。这一过程完全不需要持有 authentik_core.enable_group_superuser，而该权限正是专门为限制这一行为而设计的。

authentik 此前已在 User 侧修复了该漏洞的镜像版本（将超级用户组分配给某个用户）。 但在 Group 侧（将用户添加到某个超级用户组）缺少了等效的检查。

漏洞类别	权限提升 / 访问控制不当
CWE	CWE-269（权限管理不当）、CWE-863（授权不正确）
CVSS 3.1	AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H — 高
受影响版本	authentik ≤ 2026.2.6、≤ 2026.5.6、≤ 2026.8.1
修复版本	2026.2.7、2026.5.7、2026.8.2
可达路由	PATCH /api/v3/core/groups/{group_uuid}/
根本原因	GroupSerializer.validate_users() 从未检查 enable_group_superuser

---

背景

authentik 为组成员管理建模了两个有意分离的 RBAC 权限：

• authentik_core.add_user_to_group — 用于常规、委派的成员管理 （例如管理日常团队名册的“服务台”或“团队负责人”角色）。
• authentik_core.enable_group_superuser — 用于限制授予或加入某个组的 更敏感操作，该组的 is_superuser=True 标志会使每个成员都成为完整的 authentik 超级用户。

这种分离的存在正是为了让组织可以广泛委派普通组管理权限， 而无需同时授予创建超级用户的能力。

authentik 此前已修复过这一确切的混淆问题，位于该关系的 User 侧 （通过 UserSerializer.validate_groups() 的 PATCH /api/v3/core/users/{pk}/）， 跟踪编号为 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(...)

漏洞详情

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 的调用者——无论是全局持有，还是仅针对某个特定超级用户组的 对象范围持有——都可以 PATCH 该组的 users 字段以添加任何用户（包括自己）， 而该用户会立即成为真正的 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。仅限授权使用——请针对你明确获得授权测试的 实例运行此脚本。

受影响 / 已修复版本

分支	受影响	已修复
2026.2.x	≤ 2026.2.6	2026.2.7
2026.5.x	≤ 2026.5.6	2026.5.7
2026.8.x	≤ 2026.8.1	2026.8.2

升级到已修复版本。 如果无法立即升级，根据官方公告的缓解措施： 限制创建/修改组、修改用户以及将用户添加到组的权限，使只有完整 管理员持有这些权限——在修补之前，不要将其中任何权限委派给非管理员 角色。

参考资料

• 官方公告：GHSA-h6c5-mpvq-j4jc
• NVD 条目：CVE-2026-94609
• 相关、此前已修复的同类漏洞（User 侧）： GHSA-h6x7-hjjc-wjc9 / CVE-2026-40172
• authentik 源代码：goauthentik/authentik

许可证

本分析文章与 PoC 仅用于教育和防御性安全研究目的。底层项目请参见 authentik 自身的许可证 （MIT）。