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를 문서화합니다. 공개된 권고문은 더 광범위한 전체 문제 (그룹 계층 구조 + 역할 할당)를 다루며, 이는 여러 독립 연구자에 의해 신고되어 함께 수정되었습니다.

요약

일상적이고 흔히 위임되는 권한인 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 측 (UserSerializer.validate_groups()를 통한 PATCH /api/v3/core/users/{pk}/)에서 한 번 수정한 바 있으며, 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과 저권한 계정(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)를 참조하십시오.