CVE-2026-102631: authd: Account takeover via username fallback in identity matching after IdP email reassignment

Published Oct 15, 2026
·
Updated

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, and silently rebinds the local account record to the new identity. As a mitigation, administrators should lock or delete the previous user's local authd account when the corresponding IdP account is removed.

Affected Software

1 affected component
Canonical Authd<0.7.1

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade authd to a version that resolves this vulnerability.

    Fixed in 0.7.1
  2. Compensating control

    Lock or delete the previous user's local authd account when the corresponding identity-provider account is removed.

Event History

Oct 15, 2026
CVE Published
via MITRE·04:42 PM
Data Sourced
via MITRE·04:42 PM
DescriptionWeakness

Frequently Asked Questions

1

Which deployments are exposed?

Canonical Authd versions before 0.7.1 are affected. Exploitation requires an identity provider to reassign an email address used by authd as a username from a previous account to a new account.

2

What does an attacker need to exploit this issue?

The attacker needs to authenticate as the new identity-provider account that received the reassigned email address. On the next login, authd can associate that identity with the previous user’s local UID and home directory.

3

What can administrators do before updating?

When an IdP account is removed, lock or delete its corresponding local authd account. This prevents a later IdP account assigned the same email address from inheriting that local account.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203