How severe is CVE-2026-58372?

No CVSS score has been assigned to CVE-2026-58372 yet. Review the advisory details and affected package list to assess your exposure.

Which packages are affected by CVE-2026-58372?

CVE-2026-58372 affects the following packages: github.com/seaweedfs/seaweedfs (Go). Ecosystems affected: Go.

How do I fix CVE-2026-58372?

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 CVE-2026-58372 is resolved across your whole dependency graph.

How do I detect CVE-2026-58372 in my Go dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/seaweedfs/seaweedfs, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

How do I mitigate CVE-2026-58372 if there is no patch (or I can't update yet)?

Resolve every user-supplied path to its canonical form and reject anything that escapes the intended directory, and run the component under an account that has no read or write access outside the directory it legitimately serves.

Is CVE-2026-58372 actively exploited in the wild?

No public exploit code has been indexed for CVE-2026-58372 yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

What is the EPSS score for CVE-2026-58372?

CVE-2026-58372 has an EPSS (Exploit Prediction Scoring System) score of 1.1%, placing it in the 65th percentile of all CVEs. EPSS is maintained by FIRST.org and estimates the probability that a vulnerability will be exploited in the wild within the next 30 days. This score indicates relatively lower exploitation probability, though the CVSS severity should still guide your patching priority.

What type of vulnerability is CVE-2026-58372?

CVE-2026-58372 is classified as Path Traversal (CWE-22). This weakness type describe the underlying flaw category, which helps determine the potential impact and the right class of mitigation. This is a high-impact weakness class that often enables remote code execution or data exposure.

When was CVE-2026-58372 published, and has it been updated?

CVE-2026-58372 was published on June 30, 2026 and was last updated on August 18, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

🐹 Go

Not in CISA KEV

CVE-2026-58372 — seaweedfs

Fix: seaweedfs/seaweedfs@0345658

CVE-2026-58372 is a Path Traversal vulnerability in github.com/seaweedfs/seaweedfs. A fix is available for github.com/seaweedfs/seaweedfs — see the affected versions and patch details below.

SeaweedFS < 4.34 - Cross-Bucket Object Deletion via DeleteObjects Request-Body Keys

Also known asBIT-seaweedfs-2026-54917CVE-2026-54917 GHSA-w62w-66v9-vvgvGO-2026-6221

Published

Jun 30, 2026

Updated

Aug 18, 2026

Affected

1 pkg

Patched

1 / 1

Exploits

None indexed

Exploitation data as of Sep 26, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

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.
A successful exploit gives an attacker total control of the affected component, not partial access.

Exploitation and automatability from CISA’s SSVC triage for CVE-2026-58372.

EPSS Exploitation Probability

via FIRST.org ↗

1.1%probability of exploitation in next 30 days

Lower Risk0.00%

Lower risk than most CVEs65th percentile — riskier than 65% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

Real-World Exposure

1 pkg affected

🐹github.com/seaweedfs/seaweedfs

Real-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) 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).

Affected Packages

1 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
🐹Go	`github.com/seaweedfs/seaweedfs`	all versions	0.0.0-20260526080459-dd1b4287899e`go get github.com/seaweedfs/seaweedfs@v0.0.0-20260526080459-dd1b4287899e`

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/seaweedfs/seaweedfs, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
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 CVE-2026-58372 is resolved across your whole dependency graph.
Workarounds
Resolve every user-supplied path to its canonical form and reject anything that escapes the intended directory, and run the component under an account that has no read or write access outside the directory it legitimately serves.

Fixing This On Your OS

If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.

Red HatImportant

SeaweedFS is affected by a path traversal vulnerability in the S3 gateway's DeleteMultipleObjectsHandler, where ../ sequences in the object keys of a DeleteObjects request body allow an authenticated client to delete objects outside its authorized bucket scope. Red Hat build of Cryostat 4 bundles SeaweedFS as its…

Workaround published by Red Hat

Mitigation for this issue is either not available or the currently available options do not meet the criteria for vulnerability selection or Red Hat Product Security recommendation. Restricting S3 write access to trusted principals reduces the risk of exploitation.

Source: Red Hat security advisory for CVE-2026-58372 (CC BY 4.0)

Product	Fixed in	Advisory
Cryostat 4 on RHEL 9	`cryostat/cryostat-storage-rhel9:4.2.0-22`	RHSA-2026:68333

Frequently Asked Questions

## 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 seg

O3 Security · Impact-Aware SCA

Is CVE-2026-58372 in your dependencies?

Find it across Go, including transitive dependencies.

Scan my dependencies How O3 SCA works