SeaweedFS: Path traversal in the S3 and Iceberg REST gateways allows cross-bucket access

## 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`) in `iam.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 in `weed 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](https://github.com/dadbravo)).

CVSS 4.0

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N

Severity from

GitHub (reviewed advisory)

Weakness

CWE-22

Also known as

BIT-seaweedfs-2026-54917, BIT-seaweedfs-2026-58372, CVE-2026-54917, CVE-2026-58372, GO-2026-6221

• github.com/seaweedfs/seaweedfs/security/advisories/GHSA-w62w-66v9-vvgv
• nvd.nist.gov/vuln/detail/CVE-2026-54917
• github.com/seaweedfs/seaweedfs/pull/9687
• github.com/seaweedfs/seaweedfs/commit/dd1b4287899eed3dfd73c2f3b1de001996fda229
• github.com/seaweedfs/seaweedfs