CVE-2025-52996: Github.com/filebrowser/filebrowser/v2 File Browser's Password Protection Of Vulnerability

LOW
Advisory Identifier: GHSA-3v48-283x-f2w4
CVSS 3.1
CWE-305
Published
Advisory Summary

CVE-2025-52996 is a LOW (CVSS 3.1) file browser's password protection of vulnerability (CWE-305: Authentication Bypass by Primary Weakness) affecting Github.com/filebrowser/filebrowser/v2 libraries in the Go ecosystem. The issue involves file browser's password protection of links is bypassable. Remediation is available in the latest vendor maintenance releases.

CVE-2025-52996 at a Glance

CVE Identifier CVE-2025-52996
GHSA Identifier GHSA-3v48-283x-f2w4
Severity LOW
CVSS v3.1 Base Score 3.1
CWE Classification CWE-305: Authentication Bypass by Primary Weakness
Affected Product Github.com/filebrowser/filebrowser/v2
Package Ecosystem Go
Published Date
Last Updated

Security Impact

CVSS: 3.1

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N).

Attack Vector Network (AV:N)
Attack Complexity High (AC:H)
Privileges Required None (PR:N)
User Interaction Required (UI:R)
Scope Unchanged (S:U)
Confidentiality Low (C:L)
Integrity None (I:N)
Availability None (A:N)

How to Fix CVE-2025-52996

To remediate this vulnerability, upgrade all affected Github.com/filebrowser/filebrowser/v2 dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

github.com/filebrowser/filebrowser/v2 fixed: Latest secure release
Upgrade github.com/filebrowser/filebrowser/v2 to Latest secure release
github.com/filebrowser/filebrowser fixed: Latest secure release
Upgrade github.com/filebrowser/filebrowser to Latest secure release
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for github.com/filebrowser/filebrowser/v2

How to Check if You Are Affected

To determine whether your application is affected by CVE-2025-52996, inspect your project dependencies for Github.com/filebrowser/filebrowser/v2:

inspect dependencies for github.com/filebrowser/filebrowser/v2

Analyze the terminal output to locate any version of Github.com/filebrowser/filebrowser/v2 in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than the patched release), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-305: Authentication Bypass by Primary Weakness, where the authentication algorithm is sound, but the implemented mechanism can be bypassed as the result of a separate weakness that is primary to the authentication error. In Github.com/filebrowser/filebrowser/v2, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

## Summary ## Files managed by the *File Browser* can be shared with a link to external persons. While the application allows protecting those links with a password, the implementation is error-prone, making an incidental unprotected sharing of a file possible. ## Impact ## File owners might rest in the assumption that their shared files are only accessible to persons knowing the defined password, giving them a false sense of security. Meanwhile, attackers gaining access to the unprotected link can use this information alone to download the possibly sensitive file. ## Vulnerability Description ## When sharing a file, the user is presented with a dialog asking for an optional password to protect the file share. The assumption of the user at this point would be, that the shared file won't be accessible without knowledge of the password. After clicking on `SHARE` the following dialog opens allowing the file's owner to copy the share-link: ![image](https://github.com/user-attachments/assets/f3add074-40ac-4367-a538-ede5bb526916) In fact, there is not one, but two links offered: A `Download Link` and an unnamed second one. They have the following format: * http://filebrowser.local:8080/share/6Gtw0xAw * http://filebrowser.local:8080/api/public/dl/6Gtw0xAw/dummy1.pdf?token=voDK6j[...] Apparently, the first of the two share links is that one that users are supposed to actually share, while the second one is a direct download link not protected by the password. This behavior is not documented anywhere or explained in the GUI, though. There are multiple scenarios how an attacker might gain access to the unprotected link and, in consequence, to the shared file: * The file owner might incidentally share the second link instead of the first one, making it accessible to anyone having read access to the messaging system used (e.g., a mailserver). * After the legitimate receiver of the share has used the password, the unprotected link will get linked in multiple locations like the browser history or the log of a proxy server used. ## Proof of Concept ## Using the first link results in an authorization error if no password is provided, as expected: ```http hl:9 GET /api/public/share/6Gtw0xAw HTTP/1.1 Host: filebrowser.local:8080 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0 Accept: */* Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate, br Referer: http://filebrowser.local:8080/share/6Gtw0xAw X-Auth: X-SHARE-PASSWORD: DNT: 1 Sec-GPC: 1 Connection: keep-alive Priority: u=4 HTTP/1.1 401 Unauthorized Cache-Control: no-cache, no-store, must-revalidate Content-Security-Policy: default-src 'self'; style-src 'unsafe-inline'; Content-Type: text/plain; charset=utf-8 X-Content-Type-Options: nosniff Date: Thu, 27 Mar 2025 10:59:12 GMT Content-Length: 17 401 Unauthorized ``` Only if the password is provided (via the `X-SHARE-PASSWORD` header), a proper response is given: ```http hl:9 GET /api/public/share/6Gtw0xAw HTTP/1.1 Host: filebrowser.local:8080 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0 Accept: */* Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate, br Referer: http://filebrowser.local:8080/share/6Gtw0xAw X-Auth: X-SHARE-PASSWORD: 1234 DNT: 1 Sec-GPC: 1 Connection: keep-alive Priority: u=0 HTTP/1.1 200 OK Cache-Control: no-cache, no-store, must-revalidate Content-Security-Policy: default-src 'self'; style-src 'unsafe-inline'; Content-Type: application/json; charset=utf-8 Date: Thu, 27 Mar 2025 10:59:15 GMT Content-Length: 301 {"path":"","name":"dummy1.pdf","size":7703,"extension":".pdf","modified":"2025-03-27T15:11:45.101242449Z","mode":420,"isDir":false,"isSymlink":false,"type":"pdf","token":"voDK6j[...]"} ``` But it does not return the actual file content but rather an access token. This is the very same token that is already part of the second share URL and is used by the web application to recreate the actual download URL. If you are in possession of that one, no further password check is performed, and the content of the file is returned: ```http GET /api/public/dl/6Gtw0xAw?inline=true&token=voDK6j[...] HTTP/1.1 Host: filebrowser.local:8080 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate, br DNT: 1 Sec-GPC: 1 Connection: keep-alive Referer: http://filebrowser.local:8080/share/6Gtw0xAw Upgrade-Insecure-Requests: 1 Priority: u=0, i HTTP/1.1 200 OK Accept-Ranges: bytes Cache-Control: private Content-Disposition: inline Content-Length: 7703 Content-Security-Policy: default-src 'self'; style-src 'unsafe-inline'; Content-Security-Policy: script-src 'none'; Content-Type: application/pdf Last-Modified: Mon, 03 Mar 2025 15:11:45 GMT Date: Thu, 27 Mar 2025 10:59:18 GMT %PDF-1.4 %Ç쏢 %%Invocation: path/gs -P- -dSAFER -dCompatibilityLevel=1.4 -q -P- -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sstdout=? -sOutputFile=? -P- -dSAFER -dCompatibilityLevel=1.4 - 5 0 obj [...] ``` ## Recommended Countermeasures ## A short time solution would be to simple remove the second link from the GUI when a password protected share is created. Doing so will be a proper defense against user errors, but it will still leave unprotected links in various logs. A thorough fix has to eliminate the unprotected links completely, access to the file must only be given to requests containing the share password. ## Timeline ## * `2025-03-27` Identified the vulnerability in version 2.32.0 * `2025-04-11` Contacted the project * `2025-04-29` Vulnerability disclosed to the project * `2025-06-25` Uploaded advisories to the project's GitHub repository * `2025-06-25` CVE ID assigned by GitHub * `2025-06-29` Mitigation of user error released in version 2.34.2 * `2025-06-29` Issue [#5239](https://github.com/filebrowser/filebrowser/issues/5239) opened to track a more thorough fix of the feature ## References ## * [CWE-305: Authentication Bypass by Primary Weakness](https://cwe.mitre.org/data/definitions/305.html) * [Original Advisory](https://github.com/sbaresearch/advisories/tree/public/2025/SBA-ADV-20250327-02_Filebrowser_Password_Protection_Of_Links_Bypassable) ## Credits ## * Mathias Tausig ([SBA Research](https://www.sba-research.org/))

CVE-2025-52996 Affected Github.com/filebrowser/filebrowser/v2 Versions

2 component(s)
Product / Package Ecosystem Affected Versions Fixed Version
github.com/filebrowser/filebrowser/v2
Go
≤ 2.42.1
github.com/filebrowser/filebrowser
Go
≤ 1.11.0

References

Frequently Asked Questions

What is CVE-2025-52996?
CVE-2025-52996 is a security vulnerability in Github.com/filebrowser/filebrowser/v2 involving File Browser's password protection of links is bypassable under CWE-305: Authentication Bypass by Primary Weakness.
Which Github.com/filebrowser/filebrowser/v2 versions are affected?
Affected versions include releases prior to current release patches across affected packages: github.com/filebrowser/filebrowser/v2, github.com/filebrowser/filebrowser.
What version fixes CVE-2025-52996?
Upgrading to current release patches (or the latest patched release for your respective branch) resolves the vulnerability.
Is github.com/filebrowser/filebrowser/v2 affected?
Yes, github.com/filebrowser/filebrowser/v2 is affected in releases prior to Latest secure release. Upgrade your dependency to Latest secure release or later.
Is github.com/filebrowser/filebrowser affected?
Yes, github.com/filebrowser/filebrowser is affected in releases prior to Latest secure release. Upgrade your dependency to Latest secure release or later.
What is the CVSS score of CVE-2025-52996?
CVE-2025-52996 has a CVSS v3.1 base score of 3.1 (LOW) with vector string CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N.
What CWE is associated with CVE-2025-52996?
CVE-2025-52996 is classified under CWE-305: Authentication Bypass by Primary Weakness (The authentication algorithm is sound, but the implemented mechanism can be bypassed as the result of a separate weakness that is primary to the authentication error.).
How can I check Go dependencies for CVE-2025-52996?
Run the dependency tree command: 'inspect dependencies for github.com/filebrowser/filebrowser/v2'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-3v48-283x-f2w4",
  "modified" : "2025-08-04T17:36:08Z",
  "published" : "2025-06-30T17:49:27Z",
  "aliases" : [ "CVE-2025-52996" ],
  "summary" : "File Browser's password protection of links is bypassable",
  "details" : "## Summary ##\n\nFiles managed by the *File Browser* can be shared with a link to external persons. While the application allows protecting those links with a password, the implementation is error-prone, making an incidental unprotected sharing of a file possible.\n\n## Impact ##\n\nFile owners might rest in the assumption that their shared files are only accessible to persons knowing the defined password, giving them a false sense of security. Meanwhile, attackers gaining access to the unprotected link can use this information alone to download the possibly sensitive file.\n\n## Vulnerability Description ##\n\nWhen sharing a file, the user is presented with a dialog asking for an optional password to protect the file share. The assumption of the user at this point would be, that the shared file won't be accessible without knowledge of the password. After clicking on `SHARE` the following dialog opens allowing the file's owner to copy the share-link:\n\n![image](https://github.com/user-attachments/assets/f3add074-40ac-4367-a538-ede5bb526916)\n\nIn fact, there is not one, but two links offered: A `Download Link` and an unnamed second one. They have the following format:\n\n* http://filebrowser.local:8080/share/6Gtw0xAw\n* http://filebrowser.local:8080/api/public/dl/6Gtw0xAw/dummy1.pdf?token=voDK6j[...]\n\nApparently, the first of the two share links is that one that users are supposed to actually share, while the second one is a direct download link not protected by the password. This behavior is not documented anywhere or explained in the GUI, though.\n\nThere are multiple scenarios how an attacker might gain access to the unprotected link and, in consequence, to the shared file:\n\n* The file owner might incidentally share the second link instead of the first one, making it accessible to anyone having read access to the messaging system used (e.g., a mailserver).\n* After the legitimate receiver of the share has used the password, the unprotected link will get linked in multiple locations like the browser history or the log of a proxy server used.\n\n## Proof of Concept ##\n\nUsing the first link results in an authorization error if no password is provided, as expected:\n\n```http hl:9\nGET /api/public/share/6Gtw0xAw HTTP/1.1\nHost: filebrowser.local:8080\nUser-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0\nAccept: */*\nAccept-Language: en-US,en;q=0.5\nAccept-Encoding: gzip, deflate, br\nReferer: http://filebrowser.local:8080/share/6Gtw0xAw\nX-Auth: \nX-SHARE-PASSWORD: \nDNT: 1\nSec-GPC: 1\nConnection: keep-alive\nPriority: u=4\n\nHTTP/1.1 401 Unauthorized\nCache-Control: no-cache, no-store, must-revalidate\nContent-Security-Policy: default-src 'self'; style-src 'unsafe-inline';\nContent-Type: text/plain; charset=utf-8\nX-Content-Type-Options: nosniff\nDate: Thu, 27 Mar 2025 10:59:12 GMT\nContent-Length: 17\n\n401 Unauthorized\n```\n\nOnly if the password is provided (via the `X-SHARE-PASSWORD` header), a proper response is given:\n\n```http hl:9\nGET /api/public/share/6Gtw0xAw HTTP/1.1\nHost: filebrowser.local:8080\nUser-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0\nAccept: */*\nAccept-Language: en-US,en;q=0.5\nAccept-Encoding: gzip, deflate, br\nReferer: http://filebrowser.local:8080/share/6Gtw0xAw\nX-Auth: \nX-SHARE-PASSWORD: 1234\nDNT: 1\nSec-GPC: 1\nConnection: keep-alive\nPriority: u=0\n\nHTTP/1.1 200 OK\nCache-Control: no-cache, no-store, must-revalidate\nContent-Security-Policy: default-src 'self'; style-src 'unsafe-inline';\nContent-Type: application/json; charset=utf-8\nDate: Thu, 27 Mar 2025 10:59:15 GMT\nContent-Length: 301\n\n{\"path\":\"\",\"name\":\"dummy1.pdf\",\"size\":7703,\"extension\":\".pdf\",\"modified\":\"2025-03-27T15:11:45.101242449Z\",\"mode\":420,\"isDir\":false,\"isSymlink\":false,\"type\":\"pdf\",\"token\":\"voDK6j[...]\"}\n```\n\nBut it does not return the actual file content but rather an access token.\nThis is the very same token that is already part of the second share URL and is used by the web application to recreate the actual download URL.\nIf you are in possession of that one, no further password check is performed, and the content of the file is returned:\n\n```http\nGET /api/public/dl/6Gtw0xAw?inline=true&token=voDK6j[...] HTTP/1.1\nHost: filebrowser.local:8080\nUser-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0\nAccept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\nAccept-Language: en-US,en;q=0.5\nAccept-Encoding: gzip, deflate, br\nDNT: 1\nSec-GPC: 1\nConnection: keep-alive\nReferer: http://filebrowser.local:8080/share/6Gtw0xAw\nUpgrade-Insecure-Requests: 1\nPriority: u=0, i\n\nHTTP/1.1 200 OK\nAccept-Ranges: bytes\nCache-Control: private\nContent-Disposition: inline\nContent-Length: 7703\nContent-Security-Policy: default-src 'self'; style-src 'unsafe-inline';\nContent-Security-Policy: script-src 'none';\nContent-Type: application/pdf\nLast-Modified: Mon, 03 Mar 2025 15:11:45 GMT\nDate: Thu, 27 Mar 2025 10:59:18 GMT\n\n%PDF-1.4\n%Ç쏢\n%%Invocation: path/gs -P- -dSAFER -dCompatibilityLevel=1.4 -q -P- -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sstdout=? -sOutputFile=? -P- -dSAFER -dCompatibilityLevel=1.4 -\n5 0 obj\n[...]\n```\n\n## Recommended Countermeasures ##\n\nA short time solution would be to simple remove the second link from the GUI when a password protected share is created.\nDoing so will be a proper defense against user errors, but it will still leave unprotected links in various logs.\nA thorough fix has to eliminate the unprotected links completely, access to the file must only be given to requests containing the share password.\n\n## Timeline ##\n\n* `2025-03-27` Identified the vulnerability in version 2.32.0\n* `2025-04-11` Contacted the project\n* `2025-04-29` Vulnerability disclosed to the project\n* `2025-06-25` Uploaded advisories to the project's GitHub repository\n* `2025-06-25` CVE ID assigned by GitHub\n* `2025-06-29` Mitigation of user error released in version 2.34.2\n* `2025-06-29` Issue [#5239](https://github.com/filebrowser/filebrowser/issues/5239) opened to track a more thorough fix of the feature\n\n## References ##\n\n* [CWE-305: Authentication Bypass by Primary Weakness](https://cwe.mitre.org/data/definitions/305.html)\n* [Original Advisory](https://github.com/sbaresearch/advisories/tree/public/2025/SBA-ADV-20250327-02_Filebrowser_Password_Protection_Of_Links_Bypassable)\n\n## Credits ##\n\n* Mathias Tausig ([SBA Research](https://www.sba-research.org/))",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "Go",
      "name" : "github.com/filebrowser/filebrowser/v2"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "last_affected" : "2.42.1"
      } ]
    } ]
  }, {
    "package" : {
      "ecosystem" : "Go",
      "name" : "github.com/filebrowser/filebrowser"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "last_affected" : "1.11.0"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/filebrowser/filebrowser/security/advisories/GHSA-3v48-283x-f2w4"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2025-52996"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/filebrowser/filebrowser/issues/5239"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/filebrowser/filebrowser"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/sbaresearch/advisories/tree/public/2025/SBA-ADV-20250327-02_Filebrowser_Password_Protection_Of_Links_Bypassable"
  }, {
    "type" : "WEB",
    "url" : "https://pkg.go.dev/vuln/GO-2025-3790"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-305" ],
    "severity" : "LOW",
    "github_reviewed" : true,
    "github_reviewed_at" : "2025-06-30T17:49:27Z",
    "nvd_published_at" : "2025-06-30T20:15:25Z"
  }
}