FileRise EUVD-2026-101637

Three concrete preconditions must all hold: (1) the administrator must have explicitly enabled the FileRise WebDAV service (a non-default, opt-in feature); (2) the target account must have a TOTP second factor configured (accounts without TOTP are unaffected by this specific bypass); and (3) the attacker must already know the account's valid primary credentials (username and password) - the flaw does not grant access without them. The limiting factor is that exploitation yields only the compromised account's own WebDAV file permissions (folderOnly/readOnly/disableUpload still apply), and the browser login path was never vulnerable since it enforced TOTP correctly; only the separate public/webdav.php AuthModel::authenticate() callback omitted the second-factor check.

This is a genuine but conditionally-gated authentication weakness (CWE-308, single-factor authentication) rated CVSS 8.1 with vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N. The network vector, low complexity, and lack of user interaction push the score high, but the PR:L metric is the crucial moderator: the attacker must ALREADY possess valid primary credentials (username + password) for a TOTP-enabled account, and the administrator must have WebDAV enabled (a non-default feature). No EPSS score is provided in the input, the CVE is NOT in CISA KEV, and no public exploit code is referenced - so there is no public exploit identified at time of analysis. This is best understood as an MFA-bypass / defense-in-depth failure rather than a wormable remote-unauthenticated flaw: TOTP was the control specifically meant to protect accounts whose passwords might be phished or leaked, and this bug nullifies that control on the separate public/webdav.php path while the browser login path still enforced it. Priority is real for organizations that run FileRise with WebDAV enabled and rely on TOTP, because a leaked/reused password alone now grants full WebDAV file access - but the required precondition chain (WebDAV on, target account TOTP-enabled, valid primary credentials known) keeps this below the tier of a blind internet-facing compromise. The fix (require TOTP for WebDAV, or use a non-TOTP account for WebDAV until an app-password flow exists) is confirmed in v3.16.0.

An administrator enables FileRise WebDAV and a user secures their account with TOTP. An attacker who has obtained that user's password (via phishing, reuse, or a prior leak) connects a standard WebDAV client to public/webdav.php and authenticates with only username and password - the TOTP second factor is never requested or validated - gaining the account's WebDAV read/write file permissions. No public exploit code is referenced; exploitation requires only a common WebDAV client and the network vector/low complexity of the CVSS vector.