CVE-2026-104108

Executive Summary

CVE-2026-104108 is an improper authentication vulnerability (CWE-287) in FileRise, a self-hosted web-based file manager, affecting versions prior to 3.23.0. FileRise maps an authenticated OpenID Connect (OIDC) identity to a local account using mutable preferred_username or email claims and does not require email_verified for email-based naming. An attacker able to obtain provider-issued claims that collide with an existing local username can be logged in as that account — including the built-in administrator — even when automatic provisioning is disabled, depending on the identity provider's claim configuration.

Technical Analysis

The vulnerability resides in FileRise's OIDC identity-to-local-account mapping logic. When a user authenticates via OIDC, FileRise must decide which local account (if any) the federated identity corresponds to. According to the NVD description, prior to 3.23.0 FileRise performs this mapping using the preferred_username or email claims supplied by the identity provider. Both claims are mutable and provider-controlled — they are not stable, immutable, provider-scoped identifiers such as the OIDC sub (subject) claim. Additionally, for email-based naming, FileRise does not require the email_verified claim to be true.

This design creates an identity-collision / account-takeover condition:

1. Mutable claims as identity keys. preferred_username and email can, in many identity providers, be changed by an end user (e.g., a user editing their profile email or username) or be set arbitrarily by an administrator of a federated tenant. Because FileRise resolves the local account from these mutable values rather than a stable subject identifier, any principal who can cause their provider-issued claim to equal an existing FileRise username is resolved to that local account.

2. No email_verified enforcement. When the email claim is used to derive the local account name, FileRise does not require email_verified to be asserted by the provider. This allows unverified or attacker-influenced email claims to be trusted for identity resolution, widening the set of providers/configurations under which a collision can be produced.

3. Provisioning disabled does not mitigate. The vulnerability explicitly applies "even when automatic provisioning is disabled." Disabling automatic provisioning is normally a hardening control that prevents unknown identities from creating accounts; here it does not prevent an existing account — including the built-in administrator — from being matched and assumed. The collision path is identity resolution, not account creation.

4. Administrator impersonation. Because the built-in administrator is a local account with a predictable, well-known username, an attacker who can obtain a provider-issued claim matching "admin" (or the configured administrator identifier) is logged in as administrator. The description notes the attacker must be able to authenticate to the configured identity provider ("an authenticated OIDC identity" and "an attacker who can obtain provider-issued claims").

The root cause is a failure to bind the federated authentication event to an immutable, provider-scoped subject identifier, combined with insufficient validation of the trustworthiness (email_verified) of the claim used for account naming. The CVSS vector reflects network reachability (AV:N), no required privileges (PR:N), no user interaction (UI:N), but high attack complexity (AC:H) because success depends on the configured identity provider permitting the colliding claim — the attacker cannot fully control provider-side claim policy. Confidentiality, Integrity, and Availability impacts are all High (C:H/I:H/A:H), consistent with full compromise of a file manager that handles document storage, editing, and batch operations.

Exploitation Scenarios

The attack chain is inferred from the vulnerability class (improper authentication via mutable OIDC claim mapping). No public PoC, exploit code, or Nuclei template is available at time of writing.

1. Reconnaissance / target identification. The attacker identifies an internet- or intranet-exposed FileRise instance that is configured for OIDC single sign-on (a self-hosted, web-based file manager). The attacker determines which identity provider backs the deployment and whether they can obtain an account or otherwise influence their own provider-issued claims (e.g., self-service profile editing of preferred_username or email). The attacker also needs to know or guess an existing FileRise local username — most notably the built-in administrator account name.

2. Triggering the flaw class. The attacker authenticates to the identity provider and ensures the claims issued in the resulting OIDC token (preferred_username or email) collide with the target local account. Where the provider allows the user to set or change these values, the attacker sets their username/email to match the victim's FileRise identifier. Where email-based naming is used, the provider need not assert email_verified true for FileRise to accept the claim. The attacker then completes the OIDC login flow against FileRise. FileRise maps the federated identity to the local account based on the mutable claim, and the attacker is logged in as that account — including the built-in administrator — despite automatic provisioning being disabled. This works because the match is against an existing account; no provisioning step is required.

3. Execution method (vulnerability-class level). There is no memory-corruption or injection payload; the "exploit" is the successful OIDC login carrying a colliding claim. At the implementation level the flaw is an identity-resolution failure: FileRise accepts a mutable, provider-controlled claim as the key that selects a privileged local session. Success is conditional on the configured identity provider permitting the colliding claim value — this dependency is why the CVSS vector assigns high attack complexity (AC:H).

4. Post-exploitation impact. Upon being logged in as the impersonated account — up to and including the built-in administrator — the attacker gains that account's privileges over FileRise. Given FileRise's function (multi-file upload, editing, batch operations), impact includes read, modification, upload, and deletion of managed files; potential access to other users' data; and any administrative capabilities the impersonated account holds. Full C:H/I:H/A:H impact is consistent with complete compromise of the file manager's confidentiality, integrity, and availability.

Impact Assessment

CVE-2026-104108 is rated CVSS 8.1 (High), vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. The vulnerability is network-reachable (AV:N) and requires no privileges (PR:N) and no user interaction (UI:N), but has high attack complexity (AC:H) because exploitability "depends on the configured identity provider allowing the colliding claim." Scope is unchanged (S:U) while confidentiality, integrity, and availability impacts are all High.

Business impact is significant for organizations running affected FileRise versions with OIDC configured. Because the flaw can yield access to the built-in administrator account, the blast radius spans all files and users managed by the instance, and administrative functions of the application. FileRise is a self-hosted file manager commonly used for document storage and collaboration, so compromise can expose sensitive business documents and allow tampering or destruction of stored data. The absence of any public PoC or in-the-wild evidence (EPSS not scored; not in CISA KEV) suggests current exploitation is unlikely to be opportunistic — but the class of flaw (mutable-claim account takeover) is broadly known, and administrative account impersonation is a high-value objective. Affected Version ranges are those prior to 3.23.0. No OSV packages or vendor advisories were tracked at time of writing.

Detection Guidance

Detection focuses on anomalous OIDC authentication events and identity-mapping behavior in FileRise. Because there is no exploit artifact on the network beyond a legitimate-looking OIDC login, defenses are strongest at the application logs and identity provider audit logs. The rules below are generic detections for suspicious or mismatched OIDC identity resolution and should be tuned to the environment.

Sigma Rule

title: FileRise OIDC Login with Account-Colliding or Unverified Claim
id: 8f4c1e2a-1041-08d0-9a00-filerise104108
status: experimental
description: Detects OIDC-authenticated FileRise logins where the resolved local account name matches a privileged or existing account via a mutable preferred_username/email claim, or where email_verified is absent/false (CVE-2026-104108).
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-104108
author: Threat Intelligence
logsource:
  product: filerise
  service: auth
detection:
  selection_oidc:
    event.action: 'login'
    auth.method: 'oidc'
  selection_claims:
    claim.preferred_username|exists: true
    - or -
    claim.email|exists: true
  selection_privileged:
    local_account|contains:
      - 'admin'
      - 'administrator'
      - 'root'
  selection_unverified:
    claim.email_verified:
      - false
      - 'false'
      - ''
  condition: selection_oidc and (selection_privileged or selection_unverified)
fields:
  - user.name
  - local_account
  - claim.preferred_username
  - claim.email
  - claim.email_verified
  - src_ip
level: high
tags:
  - attack.initial_access
  - attack.t1190
  - cwe.287

YARA Rule

rule CVE_2026_104108_FileRise_OIDC_Claim_Mapping
{
    meta:
        description = "Detects FileRise source/build artifacts referencing vulnerable OIDC claim-to-local-account mapping using preferred_username/email without email_verified (CVE-2026-104108)"
        author = "Threat Intelligence"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-104108"
        date = "2026-01-01"
        severity = "high"

    strings:
        $s1 = "preferred_username" ascii wide nocase
        $s2 = "email_verified" ascii wide nocase
        $s3 = "OIDC" ascii wide nocase
        $s4 = "email" ascii wide nocase
        $s5 = "FileRise" ascii wide nocase
        $ver = /3\.(1[0-9]|2[0-2])\.[0-9]+/ ascii

    condition:
        (uint16(0) == 0x5A4D or uint32(0) == 0x7F454C46 or $s5)
        and $s1 and $s3 and ($s4 or $s2)
        and filesize < 20MB
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-104108 FileRise OIDC Login with Mutable Claim - Possible Account Takeover"; flow:to_server,established; http.method; content:"POST"; http.uri; content:"oidc"; nocase; http.header; content:"application/x-www-form-urlencoded"; http.request_body; content:"preferred_username"; nocase; reference:cve,2026-104108; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-104108; classtype:attempted-user; sid:1041080; rev:1;)

alert http any any -> any any (msg:"CVE-2026-104108 FileRise OIDC Callback Claim Manipulation"; flow:to_server,established; http.uri; content:"/callback"; nocase; http.header; content:"Cookie"; reference:cve,2026-104108; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-104108; classtype:attempted-user; sid:1041081; rev:1;)

Note: Exact FileRise OIDC endpoint paths are not specified in the NVD description; operators should map these generic OIDC//callback detections to the deployment's actual authentication routes.

Elastic Detection

sequence by source.ip with maxspan=5m
  [ authentication where event.action == "login" and
      auth.method == "oidc" and
      winlog.event_data.claim_preferred_username != null ]
  [ authentication where event.action == "login" and
      event.outcome == "success" and
      user.name : ("admin", "administrator", "root") ]

Detection intent: an OIDC login carrying a mutable claim (preferred_username) followed by a successful session as a privileged local account, consistent with the claim-collision takeover described in CVE-2026-104108.

Splunk SPL Query

index=filerise sourcetype=filerise:auth action=login auth.method=oidc
| eval resolved=coalesce(local_account, user)
| where match(resolved, "(?i)admin|administrator|root") OR email_verified IN ("false","0","")
| stats count min(_time) as first_seen max(_time) as last_seen
        values(preferred_username) as pref_user
        values(email) as email
        values(email_verified) as email_verified
        by src_ip resolved
| where count > 0
| convert ctime(first_seen) ctime(last_seen)
| sort - count

Alerting logic: flag OIDC logins that resolve to a privileged/local account via preferred_username/email where email_verified is false, empty, or absent — the conditions enabling CVE-2026-104108.

Wazuh OSSEC Rule

<group name="filerise,authentication,">
  <rule id="104108" level="12">
    <decoded_as>json</decoded_as>
    <field name="event.action">login</field>
    <field name="auth.method">oidc</field>
    <field name="claim.preferred_username">\.+</field>
    <field name="local_account">^(admin|administrator|root)$</field>
    <description>CVE-2026-104108: FileRise OIDC login resolving to privileged account via mutable claim - possible account takeover</description>
    <mitre>
      <id>T1190</id>
    </mitre>
    <group>authentication_failed,pci_dss_10.2.4,</group>
  </rule>

  <rule id="104109" level="10">
    <decoded_as>json</decoded_as>
    <field name="auth.method">oidc</field>
    <field name="claim.email_verified">^(false|0|)$</field>
    <description>CVE-2026-104108: FileRise OIDC login with unverified email claim used for account naming</description>
    <group>authentication_anomaly,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). The NVD description states the issue is fixed in version 3.23.0, but no patch source is currently tracked.

1. Immediate mitigations (until upgrade is verified):

   • Restrict network exposure of the FileRise instance (VPN/allowlist) so unauthenticated or untrusted principals cannot reach the OIDC login flow.
   • In the identity provider, prevent users from self-editing preferred_username/email, and enforce that email_verified is true. Where the provider supports it, configure FileRise to map to an immutable identifier rather than mutable claims — if the deployed version supports such configuration; otherwise treat the deployment as at risk.
   • Audit existing local accounts, especially the built-in administrator, for names that could be produced as a colliding claim; where feasible, rename the administrator's local account to a non-guessable value to reduce collision likelihood (note: this does not fully remediate the root cause).
   • Monitor identity provider audit logs for changes to users' preferred_username/email values that match known FileRise account names.

2. Patch / upgrade steps:

   • Upgrade FileRise to version 3.23.0 or later, which the NVD description identifies as the fixed release.
   • Verify the running version after upgrade and re-test OIDC login behavior with a non-privileged OIDC identity to confirm collision-based mapping no longer occurs.
   • Because no patch source is tracked (confidence 0/4), independently validate the fix against the vendor's release notes/advisory before considering the issue closed.

3. Long-term hardening:

   • Bind federated identities to immutable, provider-scoped subject identifiers (e.g., the OIDC sub claim) rather than mutable preferred_username/email.
   • Require email_verified (or equivalent provider assurance) before using an email claim for account resolution.
   • Keep automatic provisioning disabled as defense-in-depth, and enforce least privilege on local accounts, particularly the built-in administrator.
   • Maintain an inventory of OIDC-federated applications and review claim-mapping logic for mutable-claim dependence during security reviews.
   • Subscribe to FileRise release/advisory channels and re-issue this assessment once a vendor advisory or patch source becomes available.

References

• NVD — CVE-2026-104108: https://nvd.nist.gov/vuln/detail/CVE-2026-104108
• CWE-287 — Improper Authentication: https://cwe.mitre.org/data/definitions/287.html
• MITRE ATT&CK T1190 — Exploit Public-Facing Application: https://attack.mitre.org/techniques/T1190/
• OpenID Connect Core 1.0 (claims: sub, preferred_username, email, email_verified): https://openid.net/specs/openid-connect-core-1_0.html
• CISA Known Exploited Vulnerabilities Catalog (entry not present at time of writing): https://www.cisa.gov/known-exploited-vulnerabilities-catalog

No public PoC, exploit code, Nuclei template, or in-the-wild exploitation evidence was identified for CVE-2026-104108 at the time of writing. The vulnerability is not listed in CISA KEV, and EPSS has not yet scored it. No threat actor campaigns tied to this CVE were identified.