Skip to main content

GHSA-h6c5-mpvq-j4jc

Reported by @tonghuaroot, @Uhudsavasindankacanokcu2, @oduoke567, @szybnev, @Hann1bl3L3ct3r, @voraci0us, @everping, @4dollar4, @arthurscchan, @DavidKorczynski, @AdamKorcz, @r0hanSH, @thefoulowl, @bayramshirinov, @MayankPandey01, @DavidCarliez, @XlabAITeam, @keenanwgn, @pkuGenuine, @liangjs, @A7um, @KasperBuilds, @cipher-creator, @antigone4224, @JebeenLee, @senti-man, @Rorasaurus, @Alpastx, @code-and-covfefe, @riyandhiman14, @0xDvc-RE, @rodrigoarrelaro, @owen050724, @cy3erm, @Sn1r, @chndlrx, @moizxsec, @anthonyk2923, @isazajuancarlos

Privilege escalation via delegated group and user management​

Summary​

An account with delegated permission to manage a single group, or a single user, could grant superuser status to any account, and could assign an existing role to a group, without holding the permissions that gate those privileges.

Patches​

authentik 2026.2.7, 2026.5.7 and 2026.8.2 fix this issue.

Impact​

Only deployments that delegate group, group membership or user management to accounts which are not full administrators are affected.

Groups form a hierarchy, and superuser status is inherited from any group above, so a group can confer it without holding it itself. The checks on group membership and on the hierarchy either did not look for superuser status, or looked only at the group's own setting. Nothing checked the permission to assign a role to a group.

Workarounds​

Restrict the permissions to create and modify groups, to modify users, and to add users to groups, so that all of them are held only by accounts that are already full administrators.

For more information​

If you have any questions or comments about this advisory: