FileRise CVE-2026-69191

Exploitation requires BOTH that an administrator has explicitly disabled one of the login methods via the disableFormLogin, disableBasicAuth, or disableOIDCLogin flags in the Admin Panel, AND that the attacker possesses otherwise-valid credentials for that specific disabled method; the attacker then calls the method's backend authentication endpoint directly rather than through the client UI. Limiting factors: this is not credential-free - valid credentials are mandatory (PR:L); it only has effect on deployments that have actually disabled a method (default-all-enabled deployments are unaffected since there is no policy to bypass); and impact is confined to defeating the login-method policy, not privilege escalation. Affected versions are all FileRise prior to 3.21.0.

This is a moderate, policy-enforcement authentication flaw rather than a high-urgency remote-code or credential-free bypass. The provided CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N, base 5.4 Medium) is internally consistent with the description: network-reachable, low complexity, but requiring low privileges (PR:L) because the attacker must already hold otherwise-valid credentials for the disabled method - the description explicitly states 'The flaw does not permit credential-free authentication.' No EPSS score, SSVC decision, KEV listing, or POC was supplied. There is no public exploit identified at time of analysis and no evidence of active exploitation. The practical risk is bounded: it does not grant new accounts or bypass credential checks, it only lets a legitimately-credentialed user reach a login method the administrator intended to disable, defeating a defense-in-depth policy (e.g., an org that disabled Basic Auth or form login to force OIDC). No conflicting signals are present, though the absence of EPSS/SSVC means widespread-exploitation probability cannot be quantified from the data given.

An organization disables form login or Basic Auth in the FileRise Admin Panel to force all authentication through OIDC/SSO. A user who still possesses valid local credentials (e.g., a former password that should no longer be usable via that path) sends a direct HTTP request to the disabled method's backend authentication endpoint, which - prior to 3.21.0 - validates the credentials and issues a session despite the policy. No public exploit code was identified at time of analysis.