Know every vulnerabilitybefore it knows you.
DevGuard continuously monitors your dependencies and alerts you when CVEs like this one affect your stack — with real-time threat intelligence built for developers.
GHSA-w62w-66v9-vvgv
Summary
The S3 API gateway and the Iceberg REST catalog gateway construct their routers with mux.NewRouter().SkipClean(true). With path cleaning disabled, a .. segment inside the URL survives routing, so a request such as:
GET /bucket-A/../evil-bucket/key
is matched as bucket=bucket-A, object=../evil-bucket/key. The captured object key is then joined into a filer path with util.JoinPath (S3) / path.Join (Iceberg), which collapse the .. server-side, so the actual read or write lands in evil-bucket.
The captured path variables were never validated for traversal segments before reaching the handlers, so bucket isolation depended on downstream checks rather than on the path itself.
Impact
- With authentication disabled (
enableAuth=false): direct cross-bucket read and write. An object key containing..resolves to and operates on a different bucket than the one named in the request path. - With authentication enabled (
enableAuth=true): an authorization confused-deputy. IAM evaluates the policy against the mux{bucket}variable (bucket-A) iniam.authRequestWithAuthType, while the I/O is performed against the traversed target (evil-bucket). A principal authorized for one bucket can therefore reach objects in another bucket it has no grant for. This breaks tenant isolation.
The same class of traversal applies to the Iceberg REST catalog's {prefix}, {namespace}, and {table} path variables.
%2e%2e-encoded and ..\ (backslash) variants are equivalent, because gorilla/mux URL-decodes captured variables and NormalizeObjectKey folds \ to / before the path is used.
Affected components
- S3 API gateway (
weed s3, and the S3 endpoint embedded inweed server) - Iceberg REST catalog gateway
Affected versions
All releases prior to 4.30.
Patched version
4.30 and later.
Proof of concept
With a bucket evil-bucket containing secret.txt, and a caller that only has (or needs no) access to bucket-A:
GET /bucket-A/../evil-bucket/secret.txt HTTP/1.1
Host: <gateway>
The response returns the contents of evil-bucket/secret.txt. The encoded form GET /bucket-A/%2e%2e/evil-bucket/secret.txt behaves identically.
Remediation
Upgrade to SeaweedFS 4.30 or later. The fix adds a validation middleware to both gateway routers that rejects any captured path variable containing a . or .. segment, a NUL byte, an embedded slash/backslash in single-segment slots, or an empty captured value, before any handler runs.
Workarounds
For deployments that cannot upgrade immediately, place a reverse proxy in front of the gateway that normalizes the request path and rejects requests whose path contains .., %2e%2e, or backslash sequences. Note that disabling auth removes the only remaining barrier, so do not rely on enableAuth=false deployments being protected by anything.
Resources
- Fix: https://github.com/seaweedfs/seaweedfs/pull/9687 (commit
dd1b428)
Credits
Reported responsibly by Denis Abashkin (@dadbravo).
The vulnerability can be exploited over the network without needing physical access. It is easy for an attacker to exploit this vulnerability. An attacker does not need any special privileges or access rights. No user interaction is needed for the attacker to exploit this vulnerability.
Exploitation attempts have been detected. Elevated vigilance and prompt remediation are advised.
The exploit probability is very low. The vulnerability is unlikely to be exploited in the next 30 days.
We did not find any exploit available. Neither in GitHub repositories nor in the Exploit-Database.
- CVE-2026-54917
SeaweedFS is a distributed storage system for object storage (S3), file systems, and Iceberg tables. Prior to 4.30, the S3 API gateway and the Iceberg REST catalog gateway construct their routers with mux.NewRouter().SkipClean(true). With path cleaning disabled, a .. segment inside the URL survives routing, so a request such as `GET /bucket-A/../evil-bucket/key`, is matched as bucket=bucket-A, object=../evil-bucket/key. The captured object key is then joined into a filer path with util.JoinPath (S3) / path.Join (Iceberg), which collapse the .. server-side, so the actual read or write lands in evil-bucket. This vulnerability is fixed in 4.30.
Alias, EPSS 0.77% - CVE-2026-58372
SeaweedFS before 4.34 contains a path traversal vulnerability in the S3 gateway DeleteMultipleObjectsHandler that allows authenticated S3 principals with write access to a single bucket to delete arbitrary objects in other tenants' buckets by supplying object keys containing ../ sequences in the DeleteObjects XML request body. Attackers can bypass authorization controls through a confused deputy condition, as the validateRequestPath middleware only inspects URL-captured path variables and never examines request-body keys, allowing the filer path to collapse directory traversal sequences and resolve deletions outside the authorized bucket.
Alias, EPSS 0.77% - EUVD-2026-40360Alias
- EUVD-2026-39535Alias
Browse More
Continuously monitor your dependencies and get alerted when vulnerabilities like this one affect your stack.
Checkout DevGuard