File Browser CVE-2026-73611

Exploitation requires three concurrent conditions: (1) File Browser must be configured to use proxy authentication (AuthMethod set to MethodProxyAuth); (2) the logout page must be configured to a non-default custom value (the vulnerable code path is triggered only when this non-default setting is detected); and (3) the attacker must possess a JWT token that was previously valid for the target instance - obtained through legitimate prior access, network capture, log exfiltration, or browser history. The CVSS PR:L metric confirms some form of prior authentication is required. The vulnerability is not exploitable against default File Browser deployments or proxy-auth deployments using the default logout page setting. Exploitation is limited to attackers who have or had access to a token, and the custom logout page requirement further reduces the affected population.

The CVSS 4.0 score of 7.6 reflects meaningful but conditionally constrained risk: AC:H and AT:P signal that exploitation requires the specific co-occurrence of proxy authentication enabled and a non-default logout page, neither of which is the default configuration. PR:L acknowledges the attacker must already possess a previously valid token - limiting exposure to former authenticated users, insiders, or parties who obtained a token through network interception or log exposure. The VC:H and VI:H ratings are well-founded because access includes administrative endpoints and the renewal endpoint allows converting an expired token into a fresh one, escalating a single token theft into persistent access. No EPSS score was provided in the available data, and the CVE is not listed in CISA KEV, consistent with the non-default configuration prerequisite that reduces automated, mass-exploitation potential. Overall real-world priority is moderate: organizations running File Browser in proxy-auth mode with a custom logout page should treat this as urgent, but the majority of File Browser deployments using default settings are not exposed.

An attacker who previously authenticated to a File Browser instance - or who captured a JWT from network traffic, application logs, or a browser session - allows the token to expire naturally, then submits it directly to a protected API endpoint or the token renewal endpoint on a proxy-auth deployment with a non-default logout page. Because the pre-patch middleware waives expiration without validating the proxy identity header, the expired token is accepted, granting full access to protected files and administrative functions; the renewal endpoint can then be used to obtain a fresh, unexpired token, converting a time-limited exposure into persistent access. No public exploit code has been identified, but the attack requires only standard HTTP tooling and knowledge of an expired token.