Adrian Dombeck

User identity matching in the `UpdateUser()` function (located in internal/users/manager.go) resolves logins using a broker-scoped provider ID. If the provider ID is not recognized, the system falls back to matching the username without rejecting conflicting non-empty provider IDs. If an identity provider reassigns an email address (used as the username) to a new account, that new account inherits the local UID and home directory of the previous user upon login. This allows the new user to access and modify the previous user's files, including SSH keys and cloud API tokens, while silently rebinding the local account record to the new identity.

A local attacker who can register user names could spoof another user's ID and gain their privileges due to insufficient randomization of user IDs. The issue arises from the `GenerateID` method, which assigns user IDs as a pure function of the user name, and the set of UIDs is too small for pseudo-random assignment to work. This allows an adversary to register multiple users with colliding IDs or register a single user whose ID collides with a target user's. The attacker can bypass the uniqueness check by engineering a situation where the system administrator purges `/var/cache`, targeting a system account whose UID is in `authd`'s range, or targeting an account that hasn't logged into a specific system in more than 6 months.