GHSA-gv5w-hfx8-8cwq: High severity go/github.com/seaweedfs/seaweedfs vulnerability
Impact When a filer JWT restricts a token to a set of path prefixes via allowedprefixes, the authorization check used a literal byte-prefix match (strings.HasPrefix). A token scoped to /tenant1 therefore also authorized requests to sibling paths such as /tenant1234, /tenant1-old, and /tenant1backup.
In a multi-tenant deployment this lets the holder of one tenant's token access another tenant's data. Because allowedprefixes gates both read and write tokens, the impact covers cross-tenant reads and writes. A valid scoped token is required, so this is an authorization bypass rather than a fully unauthenticated flaw.
Affected component - weed/server/filerserverhandlers.go (JWT allowedprefixes authorization check)
Patches Fixed in 4.24. The check now matches on /-separated path components after path.Clean normalisation, so /tenant1 authorizes only /tenant1 and its descendants — not /tenant1234 or other sibling paths.
Workarounds Where feasible, choose prefix names that are not string-prefixes of one another (e.g. keep a trailing separator convention). Upgrade to 4.24.
References - Reported by Kadir Arslan (https://github.com/KadirArslan)
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
go/github.com/seaweedfs/seaweedfsto a version that resolves this vulnerability.Fixed in 0.0.0-20260512171048-05ed5c9ae8a2 - Upgrade
Upgrade
weed/serverto a version that resolves this vulnerability.Fixed in 4.24 - Configuration
When using filer JWT allowed_prefixes, avoid prefix strings that are literal string-prefixes of other prefixes (to prevent matches like /tenant1 authorizing /tenant1234, /tenant1-old, /tenant1backup via HasPrefix). Prefer a trailing-separator naming convention.
filer JWT authorization (allowed_prefixes) allowed_prefixes = Choose prefix names that are not string-prefixes of one another (e.g., keep a trailing separator convention).
Event History
Frequently Asked Questions
Who can exploit this issue in a multi-tenant deployment?
An attacker needs a valid JWT whose allowed_prefixes scope includes a tenant path. If another tenant's path begins with the same literal bytes, the token holder may be able to read from and write to that sibling tenant path.
Are deployments without scoped JWT path restrictions affected?
The issue is in the authorization check for JWTs using allowed_prefixes. The provided information only identifies tokens restricted through allowed_prefixes as affected.
What can be done if upgrading is not immediately possible?
Avoid tenant prefix names where one name is a string prefix of another. For example, ensure paths such as /tenant1 and /tenant1234 cannot coexist under the chosen naming convention; upgrading to 4.24 is the documented fix.
How can I identify potentially exposed tenant paths?
Review allowed_prefixes values and tenant path names for literal prefix collisions. A scope of /tenant1 is potentially overbroad if paths such as /tenant1234, /tenant1-old, or /tenant1backup exist.