Summary
FileRise versions before 3.23.0 may incorrectly associate an authenticated OIDC identity with an existing local account based on mutable preferred_username or email claims. If the identity provider permits claims that collide with a local username, an attacker could access that account, potentially including the built-in administrator account.
FileRise versions before 3.23.0 may incorrectly associate an authenticated OIDC identity with an existing local account based on mutable preferred_username or email claims. If the identity provider permits claims that collide with a local username, an attacker could access that account, potentially including the built-in administrator account.
Affected context
The issue occurs in FileRise deployments using OIDC authentication and account mapping based on provider-supplied preferred_username or email claims. Risk is higher when the configured identity provider allows users or tokens to obtain claims matching existing local usernames, or when email claims are accepted without requiring email_verified. Automatic account provisioning does not necessarily prevent the account-mapping condition.
The issue occurs in FileRise deployments using OIDC authentication and account mapping based on provider-supplied preferred_username or email claims. Risk is higher when the configured identity provider allows users or tokens to obtain claims matching existing local usernames, or when email claims are accepted without requiring email_verified. Automatic account provisioning does not necessarily prevent the account-mapping condition.
Exploit preconditions
- Attack surface: FileRise's OIDC authentication and local-account mapping
- Required access: An identity that can authenticate through the configured
OIDC provider, plus the ability to obtain or influence a colliding claim
- Trigger point: FileRise maps the authenticated OIDC claims to a local
account during login
- Why exploitation is possible: Account identity is derived from mutable
provider claims without sufficiently binding the identity to a verified,
immutable identifier
- Attack surface: FileRise's OIDC authentication and local-account mapping
- Required access: An identity that can authenticate through the configured
OIDC provider, plus the ability to obtain or influence a colliding claim
- Trigger point: FileRise maps the authenticated OIDC claims to a local
account during login
- Why exploitation is possible: Account identity is derived from mutable
provider claims without sufficiently binding the identity to a verified,
immutable identifier
Why this happens
The underlying bug is an authentication-account-linking flaw. FileRise uses mutable preferred_username or email claims to select a local account and does not consistently require email verification when email is used for naming. This maps primarily to CWE-287, Improper Authentication, with related characteristics of CWE-290, Authentication Bypass by Spoofing, and CWE-345, Insufficient Verification of Data Authenticity. The insecure pattern is treating provider-controlled naming attributes as authoritative account identities instead of validating a stable subject identifier and verified account-binding information.
The underlying bug is an authentication-account-linking flaw. FileRise uses mutable preferred_username or email claims to select a local account and does not consistently require email verification when email is used for naming. This maps primarily to CWE-287, Improper Authentication, with related characteristics of CWE-290, Authentication Bypass by Spoofing, and CWE-345, Insufficient Verification of Data Authenticity. The insecure pattern is treating provider-controlled naming attributes as authoritative account identities instead of validating a stable subject identifier and verified account-binding information.
Potential impact
- An attacker may be authenticated as another local user.
- An attacker could gain access to files and operations belonging to the
matched account.
- A collision with the built-in administrator account could enable administrative
control of the FileRise instance.
- Compromised administrative access may allow data exposure, modification, or
deletion.
- The incident could affect other users and connected storage depending on
the administrator account's permissions.
- An attacker may be authenticated as another local user.
- An attacker could gain access to files and operations belonging to the
matched account.
- A collision with the built-in administrator account could enable administrative
control of the FileRise instance.
- Compromised administrative access may allow data exposure, modification, or
deletion.
- The incident could affect other users and connected storage depending on
the administrator account's permissions.
General mitigation guidance
Mitigation generally focuses on strengthening OIDC identity binding and
reducing trust in mutable claims.
Common defensive patterns include:
- Bind local accounts to a stable, issuer-scoped OIDC subject identifier
rather than preferred_username or an unverified email address.
- Require email_verified and validate the claim issuer, audience, and token
signature before using email-based account mapping.
- Prevent automatic matching to privileged local accounts unless an explicit,
verified administrative association exists.
- Use secure-by-default settings that require deliberate account linking and
reject ambiguous or colliding identities.
- Apply least privilege to local accounts and limit administrative sessions
and connected storage permissions.
- Review existing OIDC-to-local account mappings for duplicate, stale, or
unexpectedly privileged associations.
Mitigation generally focuses on strengthening OIDC identity binding and
reducing trust in mutable claims.
Common defensive patterns include:
- Bind local accounts to a stable, issuer-scoped OIDC subject identifier
rather than preferred_username or an unverified email address.
- Require email_verified and validate the claim issuer, audience, and token
signature before using email-based account mapping.
- Prevent automatic matching to privileged local accounts unless an explicit,
verified administrative association exists.
- Use secure-by-default settings that require deliberate account linking and
reject ambiguous or colliding identities.
- Apply least privilege to local accounts and limit administrative sessions
and connected storage permissions.
- Review existing OIDC-to-local account mappings for duplicate, stale, or
unexpectedly privileged associations.
How teams detect issues like this
Detection approaches may include:
- Static analysis and code review for account lookup logic using
preferred_username or email without stable subject binding or verification.
- Checks for OIDC implementations that omit issuer, audience, signature, or
email_verified validation.
- Tests covering claim collisions with ordinary and privileged local
usernames, including cases where automatic provisioning is disabled.
- Authentication logging that records the issuer, subject, mapped local
account, and account-linking decision without exposing sensitive tokens.
- Policy enforcement requiring explicit approval for external-identity links
to existing or privileged accounts.
- Automated security review tools can help identify weak claim validation and
account-mapping patterns.
Detection approaches may include:
- Static analysis and code review for account lookup logic using
preferred_username or email without stable subject binding or verification.
- Checks for OIDC implementations that omit issuer, audience, signature, or
email_verified validation.
- Tests covering claim collisions with ordinary and privileged local
usernames, including cases where automatic provisioning is disabled.
- Authentication logging that records the issuer, subject, mapped local
account, and account-linking decision without exposing sensitive tokens.
- Policy enforcement requiring explicit approval for external-identity links
to existing or privileged accounts.
- Automated security review tools can help identify weak claim validation and
account-mapping patterns.
