authd: Account takeover via username fallback in identity matching after IdP email reassignment
In authd before 0.7.1, the user identity matching in UpdateUser (internal/users/manager.go) resolves an incoming login by the broker-scoped provider ID, but falls back to matching the username when the provider ID does not belong to any known user, and does not reject a conflicting non-empty provider ID. If an identity provider reassigns an email address, which authd uses as the username, to a new account, the new account inherits the previous user's local UID and home directory on its next login. This allows the new user to access and modify files belonging to the previous user, including credentials such as SSH keys and cloud API tokens, an
authd Denial of Service and Local Privilege Escalation
authd prior to version 0.6.4 contains a logic error in primary group ID assignment that can lead to local privilege escalation. When a user's primary group ID (GID) differs from their UID, either because the account was created with authd prior to version 0.5.4 or because the primary group was manually changed via the `authctl group set-gid` command, and the user's identity provider record is updated, authd incorrectly resets the user's primary group ID to their UID upon next login. This causes newly created files and directories to be owned by the wrong group, causing denial of service issues, and potentially granting unintended access to ot