CVE-2025-53826High▾ TwilightFile Browser’s insecure JWT handling can lead to session replay attacks after logout
▾ Twilight zone — High severity, or a signal on a lesser flaw
impact 41.3 · likelihood 0.1 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Exploit-prediction probability, daily snapshots since Sep 12.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via OSV
Last analysed / modified upstream
0.5%
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:
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
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)
Issue: Tokens remain valid after logout (session replay attacks)
POST /api/login HTTP/1.1
Host: machine.local:8090
Content-Length: 69
{"username":"admin","password":"password-here","recaptcha":""}
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
github.com/filebrowser/filebrowser <= 2.39.0github.com/filebrowser/filebrowser/v2 <= 2.39.0Refer to the advisory for the patched release.
Connected by shared product, vendor, weakness, or advisory.
CVE-2026-23849Medium· 5.3File Browser Vulnerable to Username Enumeration via Timing Attack in /api/login
CVE-2025-53893HighFile Browser's Uncontrolled Memory Consumption vulnerability can enable DoS attack due to oversized file processing
CVE-2026-25890High· 8.1File Browser has a Path-Based Access Control Bypass via Multiple Leading Slashes in URL
CVE-2025-52996Low· 3.1File Browser's password protection of links is bypassable
CVE-2026-35607High· 8.1File Browser: Proxy auth auto-provisioned users inherit Execute permission and Commands
CVE-2026-54097HighFile Browser: Cross-user unauthorized share-link deletion via unbounded prefix match in DeleteWithPathPrefix