CVE-2025-53826

File Browser’s authentication system issues long-lived JWT tokens that remain valid even after the user logs out. Please refer to the CWE's listed in this report for further reference and system standards. In summary, the main issue is:

• Tokens remain valid after logout (session replay attacks)

In this report, I used docker as the documentation instruct:

docker run \
    -v filebrowser_data:/srv \
    -v filebrowser_database:/database \
    -v filebrowser_config:/config \
    -p 8080:80 \
    filebrowser/filebrowser

Details

Issue: Tokens remain valid after logout (session replay attacks)

After logging in and receiving a JWT token, the user can explicitly "log out." However, this action does not invalidate the issued JWT. Any captured token can be replayed post-logout until it expires naturally. The backend does not track active sessions or invalidate existing tokens on logout. Login request:

POST /api/login HTTP/1.1
Host: machine.local:8090
Content-Length: 69

{"username":"admin","password":"password-here","recaptcha":""}

The check found in the code https://github.com/filebrowser/filebrowser/blob/master/http/auth.go is not enough. There is no server-side blacklist or token invalidation on logout. Token renewal and validity only depends on expiry and user store timestamps:

expired := !tk.VerifyExpiresAt(time.Now().Add(time.Hour), true)
updated := tk.IssuedAt != nil && tk.IssuedAt.Unix() < d.store.Users.LastUpdate(tk.User.ID)

PoC

Issue: Tokens remain valid after logout (session replay attacks)

• Login and capture the generate JWT. Eg. the http request:

POST /api/login HTTP/1.1
Host: machine.local:8090
Content-Length: 69

{"username":"admin","password":"password-here","recaptcha":""}

• Logout in the dashboard. And then try to use the old generated JWT to access any authenticated endpoint eg:

GET /api/resources HTTP/1.1
Host: machine.local:8090
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36
X-Auth: Old-JWT-token-here
Content-Length: 173
Accept: */*
Referer: http://machine.local:8090/files/
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Content-Length: 26

Connection: keep-alive

Recommendations

• Read all CWE's attached in this report
• Invalidate JWTs on logout via session store / token blacklist.
• Reduce JWT ExpiresAt where possible or use short-lived + refresh tokens.

• A valid JWT remains active after user logout.
• If stolen, tokens persist access indefinitely until expiry.
• Violates OWASP Top 10 A2:2021 - Broken Authentication.

Kodem intelligence

1. What is CVE-2025-53826? CVE-2025-53826 is a high-severity security vulnerability in github.com/filebrowser/filebrowser (go), affecting versions <= 2.39.0. No fixed version is listed yet.
2. Which packages are affected by CVE-2025-53826?
   • github.com/filebrowser/filebrowser (go) (versions <= 2.39.0)
   • github.com/filebrowser/filebrowser/v2 (go) (versions <= 2.39.0)
3. Is there a fix for CVE-2025-53826? No fixed version is listed for CVE-2025-53826 yet. Monitor the advisory for updates and apply mitigations in the interim.
4. Is CVE-2025-53826 exploitable, and should I be worried? Whether CVE-2025-53826 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
5. What actually determines whether CVE-2025-53826 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.

Other vulnerabilities in github.com/filebrowser/filebrowser