Technical write-up · authentik
Privilege escalation via delegated group and user management
Analysis of authentik CVE-2026-94609, delegated administration, inherited group privileges, and the authorization boundary corrected by the vendor.
Delegation should bound the authority granted
authentik allows administrators to delegate management of an individual user or group. My research question was whether that delegation remained bounded when group inheritance changed the authority a user received. The account in my assessment began with limited user-management permission and could acquire effective superuser authority beyond that permission. It did not begin as a full administrator.
The distinction is part of authentik’s own access model. Object permissions allow management of a particular object; global permissions apply across an object type. Permission to edit one user therefore does not itself establish permission to grant every privilege that user might receive. Permission model.
My original investigation documented source review and controlled local validation on authentik 2026.5.6. It concerned inherited authority during delegated user management, one part of the subsequently consolidated advisory. The runtime observations below come from that investigation. The released-code comparison is a later source review; no new reproduction or patched-release runtime test was performed for this article.
Direct settings and effective privileges
A group’s immediate settings describe only part of its authority. authentik treats members of child groups as members of their parents. “Effective privileges” means the authority the system recognizes after resolving these relationships, including privileges inherited from further ancestors. The hierarchy is an intended feature. Group hierarchy.
In the assessed 2026.5.6 model, User.all_groups() includes ancestors, and User.is_superuser checks that expanded set for superuser status. The group field and the user’s resulting authority consequently answer different questions: one describes a single group; the other includes the hierarchy. Assessed membership calculation, effective superuser calculation.
Three responsibilities must agree. Object authorization determines which user or group the caller may manage. Privilege-grant authorization determines whether the caller may confer the resulting authority. Membership resolution determines which privileges actually follow the saved relationships. Passing the first check does not answer the second, and the second needs the same understanding of inheritance as the third.
The published advisory describes checks that omitted superuser status or considered only a group’s own setting. It also covers missing authorization for assigning existing roles to groups. My contribution focused on inherited authority; the consolidated advisory includes additional cases beyond this assessment.
Distinguishing escalation from intended administration
Successful administration alone would not establish a vulnerability. The decisive comparison was between the account’s starting permission and the effective authority that followed the change. The original local assessment recorded both that starting scope and comparisons that did not confer elevated authority.
| Recorded comparison | Observation at the authorization boundary | Interpretation |
|---|---|---|
| Starting account | Limited delegated management without superuser-grant permission. | The elevated authority was not part of the account’s initial delegation. |
| Non-privileged group relationship | The accepted relationship did not confer superuser authority. | A successful delegated edit alone did not demonstrate escalation. |
| Affected inherited-authority case | The resulting effective authority exceeded the starting scope. | The inheritance mismatch had a security consequence beyond accepting an edit. |
These observations distinguish the issue from an account that already possessed the claimed privilege. They also separate a successful response from a change in effective authority. The table summarizes the original controls; it is not a set of results from the patched release.
Another explanation was that inheritance worked exactly as designed. That remains compatible with an authorization failure: inheritance decides what a relationship grants, while authorization decides who may establish it. authentik explicitly separates management permission from permission to enable superuser status, providing a product-defined boundary for this analysis. Group administration requirements.
Scope of the published finding
The vendor limits affected deployments to those delegating group, membership, or user management to accounts that are not full administrators. The advisory rates the consolidated issue High 8.8 under CVSS 3.1. Vendor assessment.
My inherited-authority case depends on the relevant group relationships. It does not establish how common that configuration is. The demonstrated boundary is within authentik’s administration model; this account makes no claim about compromise of connected applications or about every case in the consolidated advisory having been reproduced in my assessment.
Authorizing the complete privilege consequence
The vendor lists 2026.2.7, 2026.5.7, and 2026.8.2 as patched and recommends restricting the relevant management permissions to full administrators until upgrading. Vendor remediation.
In the inspected 2026.5.7 release, UserSerializer.validate_groups first separates newly added groups from existing memberships. Its decisive check in authentik/core/api/users.py is:
ancestry = new_groups.with_ancestors()
if ancestry.filter(is_superuser=True).exists() and not request.user.has_perm(
"authentik_core.enable_group_superuser"
):
raise ValidationError(
_("User does not have permission to add members to a superuser group.")
)
The check evaluates inherited authority before allowing the grant. Excluding existing memberships focuses this validation on newly conferred privileges. Object authorization still has its own job: the caller must also be allowed to manage the target user. Released validation and surrounding code.
This is a focused excerpt of the vendor’s correction. The 2026.5.7 release includes the public upstream change. The inspection establishes this source-level change in 2026.5.7; independent runtime verification of the patched releases has not been recorded.
For regression coverage, I would require the following outcomes. These are proposed, unexecuted checks, not a description of upstream test coverage.
| Proposed case | Required behavior |
|---|---|
| Authorized edit without elevated authority | Preserve legitimate delegated management. |
| New direct or inherited superuser grant without grant permission | Reject the change and preserve existing membership and authority. |
| Same grant with both object and grant permissions | Permit the intended administration. |
| Grant permission without permission to manage the target | Continue rejecting the object change. |
The assessed and fixed snapshots do not identify the first affected release or independently verify every maintenance branch. The remaining runtime check is whether the released validation preserves both boundaries while leaving protected state unchanged after rejection.