Canonical authd CVE-2026-102631

Requires authd before 0.7.1 deployed with an OIDC broker configuration in which the IdP email address is used as the local username. The specific trigger is that the identity provider reassigns a previously-used email to a NEW account (email/username recycling) after the original IdP account is removed, AND the administrator fails to lock or delete the original user's local authd account. Exploitation then occurs only on the new user's local login to the affected host. Limiting factors: this depends on an IdP-side administrative lifecycle event the attacker does not control, it is local to the authd-managed machine (AV:L), carries a specific attack requirement (AT:P) and high complexity (AC:H), and the documented mitigation - locking/deleting the departed user's local account at IdP removal time - fully prevents it.

This is a genuine but highly conditional flaw rather than a mass-exploitation priority. The vendor CVSS 4.0 vector (AV:L/AC:H/AT:P/PR:N/UI:N) scores 5.9 (medium) and is internally consistent with the description: exploitation is local (requires a login on the authd-managed host), carries high attack complexity (AC:H), and explicitly flags an attack requirement (AT:P) - namely that an identity provider must reassign a previously-used email/username to a new account while the original user's local authd account is left in place. VC:H reflects real exposure of the prior user's SSH keys and cloud API tokens; VI:L reflects the silent rebinding and file modification. No EPSS score, no CISA KEV listing, and no public exploit code were provided, which is consistent with a logic/identity-confusion bug whose trigger (IdP email recycling) is an organizational event an external attacker cannot directly force. The PR:N metric is notable: the 'attacker' is a legitimate user authenticating with their own valid IdP credentials for the recycled email, so no prior privileges on the target are needed - but this is not remote unauthenticated code execution, and AV:L plus AT:P sharply limit practical reach. Net: a real risk for environments that recycle email addresses across IdP account lifecycles, but low likelihood of widespread opportunistic exploitation.

An organization uses authd with an OIDC broker where the IdP email is the local username. An employee departs and their email (e.g. alice@corp.com) is later reassigned by the IdP to a new hire, while the departed user's local authd account is never locked or deleted. On the new hire's first login, authd's username fallback rebinds them to the prior user's local UID and home directory, giving them read/write access to the predecessor's SSH keys and cloud API tokens. No public exploit code was identified at time of analysis.