GHSA-w62w-66v9-vvgv
Fix: seaweedfs/seaweedfs#9687GHSA-w62w-66v9-vvgv is a Path Traversal vulnerability in github.com/seaweedfs/seaweedfs. O3 Security confirms whether GHSA-w62w-66v9-vvgv is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
SeaweedFS: Path traversal in the S3 and Iceberg REST gateways allows cross-bucket access
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
Exploitation and automatability from CISA’s SSVC triage for GHSA-w62w-66v9-vvgv.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Real-World Exposure
github.com/seaweedfs/seaweedfsReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
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).
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/seaweedfs/seaweedfs | all versions | 0.0.0-20260526080459-dd1b4287899e |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/seaweedfs/seaweedfs. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update github.com/seaweedfs/seaweedfs to 0.0.0-20260526080459-dd1b4287899e or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-w62w-66v9-vvgv is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-w62w-66v9-vvgv is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-w62w-66v9-vvgv. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-w62w-66v9-vvgv in your dependencies?
O3 detects GHSA-w62w-66v9-vvgv across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.