CVE-2026-73611

The vulnerability in File Browser versions 2.50.0 through 2.63.21 creates a perverse security dynamic: the more you hardened your deployment, the more exposed you became. When running in proxy-auth mode with a custom logout page configured, the application stopped validating JWT token expiration entirely. Tokens never expired. This occurs because File Browser in proxy-auth mode expects the reverse proxy to handle authentication, yet internally performed its own expiration validation only for the default logout page configuration. When administrators customized the logout page—typically a deliberate security or compliance choice—they inadvertently disabled that validation layer while leaving the renewal endpoint functional. The result is a token that remains valid indefinitely, regardless of its original expiration timestamp. The renewal endpoint is the critical amplifier. An attacker with any token that was valid during the vulnerable window can exchange it for a fresh one after your organization patches and rotates credentials. This breaks standard incident response: you cannot remediate by rotating tokens, because the renewal endpoint accepts the expired token as valid and issues a new session. The attack surface includes every token issued during the 18-month exposure window. If you run File Browser behind a reverse proxy in proxy-auth mode, audit your current version immediately. The fix in 2.64.0 restores expiration validation, but patching alone is insufficient—you must invalidate all tokens issued during the vulnerable version range. Organizations with sophisticated proxy deployments should also audit whether similar conditional-validation patterns exist in other applications receiving pre-validated tokens from upstream proxies.

Reviewed through automated stages and approved by a human before publication.