FileBrowser Quantum EUVD-2026-111279

A symlink that resolves to a target outside the user's source root/scope must already exist and be reachable inside the served directory - and, for the unauthenticated vector, inside a directory that has been published as a public share. This condition commonly arises when host directories are bind-mounted into the container (the typical Docker deployment) or when user scopes overlap shared storage, so such symlinks appear without the attacker creating them. The affected read flows (download, preview, media/subtitle, OnlyOffice, and public-share download) must have FollowSymlinks enabled, which the vulnerable versions do by default on these paths. Limiting factors that reduce realistic risk: the authenticated vector still requires an account with download access; the unauthenticated vector additionally requires that an owner has created a public share covering a directory containing the qualifying symlink; the attacker cannot read a target for which no reachable in-scope symlink exists. Affected versions: filebrowser < 1.5.2-stable, and 2.0.0-beta through < 2.0.1-beta; the only complete fix per the vendor is upgrading to 1.5.2-stable or 2.0.1-beta, which add a containment check verifying the resolved path stays within the user's scope.

Signals are mostly aligned toward a genuine, time-bounded priority rather than an inflated high-CVSS artifact. The CVSS 3.1 base score of 8.6 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N) reflects a network-reachable, unauthenticated information-disclosure flaw whose scope-change (S:C) is justified because a reachable symlink lets the app serve files belonging to the host OS or other tenants, outside its authorization boundary. The PR:N is specifically driven by the public-share vector, where only a share hash - no account - authorizes the read; the authenticated download vector works for any scoped user with download access. A full, step-by-step proof-of-concept is published inside the vendor's own GHSA advisory and was confirmed live against gtstef/filebrowser:1.3.3-stable (observed output includes /etc/passwd and a secret file), so exploitation is low-effort for anyone who can reach a qualifying deployment. The vuln.today decision label is 'this_week' (not act_now/emergency), consistent with a serious but not mass-exploited issue. Tempering the raw score: exploitation is NOT universal because it REQUIRES a pre-existing symlink that points outside scope to already be reachable in the served (or publicly shared) directory - a precondition that is common in bind-mounted Docker setups and overlapping shared storage but is not guaranteed in every install. Missing/conflicting data to note explicitly: no EPSS score was provided, so statistical exploitation probability cannot be stated; the CVE is NOT listed in CISA KEV, so there is no confirmed active exploitation despite a working PoC - do not conflate the two.

In a typical Docker deployment where a host directory is bind-mounted into FileBrowser, a symlink inside the served tree points at an out-of-scope target (e.g. /etc/passwd, another tenant's files, or container secrets). An authenticated user with download access - or, if the directory is exposed via a public share, anyone holding only the share link with no account - requests that symlink through the download, preview, media, OnlyOffice, or public-share read endpoint and receives the out-of-scope file's contents. A working proof-of-concept demonstrating both the authenticated and unauthenticated-share vectors is published in the vendor GHSA advisory and was confirmed live.