filebrowser EUVD-2026-58648

Exploitation requires an authenticated filebrowser session (CVSS PR:L confirmed); unauthenticated access is not possible. The bypass is only meaningful when the target user's account has Perm.Download explicitly set to false - users who have Perm.Download=true (the default for most deployments) are unaffected because no permission boundary is circumvented. Scope and path authorization are NOT bypassed; the attacker can only request checksums for files they are otherwise permitted to see within their configured scope. The attacker must know or guess the file path, as directory listing permissions (Perm.Create, etc.) are separate and not affected. What limits exploitation: the attacker receives only a hash, never the file bytes, so extraction of non-guessable high-entropy content (e.g., random cryptographic keys) is not feasible via this oracle alone.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N) scores 5.3 and accurately characterizes the risk: network-reachable, low complexity, but gated behind authenticated access (PR:L), with only partial confidentiality exposure (VC:L - hashes, not plaintext). No EPSS data was provided in the intelligence input, so exploitation probability cannot be quantified numerically; this should be noted as a gap. The vulnerability is not listed in CISA KEV, and no public exploit or POC code is identified at time of analysis. The real-world impact depends heavily on what files are within the authenticated user's scope: for high-entropy files (encrypted archives, binary blobs), the hash oracle yields little actionable information; for low-entropy files (config snippets, known templates, predictable credential files), offline dictionary attacks against the digest become feasible. This is a medium-priority finding for organizations using filebrowser with fine-grained permission models - particularly those who explicitly restrict Perm.Download for specific users under the assumption that those users cannot infer file contents. Organizations using filebrowser in a trust-everyone deployment model (all authenticated users have full permissions) are unaffected in practice. The incomplete-fix lineage (CVE-2026-35606) suggests the codebase has a history of authorization gaps in this handler, which warrants a broader audit of all resourceGetHandler branches.

An authenticated filebrowser user whose account has Perm.Download explicitly set to false (e.g., a read-audit account or a restricted contractor) sends a GET request to /api/resources/path/to/sensitive.conf?checksum=sha256 - the server reads the full file, computes the SHA256 digest, and returns it in the response without triggering the download permission check. The attacker then compares the returned hash against a precomputed dictionary of candidate configuration values (e.g., known API key formats, default passwords) to confirm or deny the file's exact content, or polls the endpoint periodically to detect when the file changes. No public exploit code is known at time of analysis.