CVE-2026-58372: SeaweedFS Path Traversal Vulnerability

CVE-2026-58372 Overview

CVE-2026-58372 is a path traversal vulnerability [CWE-22] in SeaweedFS versions prior to 4.34. The flaw resides in the S3 gateway DeleteMultipleObjectsHandler and enables authenticated S3 principals with write access to one bucket to delete arbitrary objects in other tenants' buckets. Attackers exploit the flaw by supplying object keys containing ../ sequences inside the DeleteObjects XML request body. The validateRequestPath middleware only inspects URL-captured path variables and never examines request-body keys, producing a confused deputy condition that allows the filer path to resolve deletions outside the authorized bucket.

Critical Impact
A low-privileged S3 tenant can destroy data across bucket boundaries, causing cross-tenant integrity and availability loss in multi-tenant SeaweedFS deployments.

Affected Products

SeaweedFS versions before 4.34
SeaweedFS S3 gateway (weed s3 service)
Multi-tenant deployments relying on bucket-scoped S3 authorization

Discovery Timeline

2026-06-30 - CVE-2026-58372 published to NVD
2026-07-01 - Last updated in NVD database

Technical Details for CVE-2026-58372

Vulnerability Analysis

SeaweedFS exposes an S3-compatible gateway that maps object operations to a backing filer. The DeleteMultipleObjectsHandler processes S3 DeleteObjects requests that carry a list of object keys inside the XML request body. Authorization is enforced by the validateRequestPath middleware, which examines the bucket and key extracted from the request URL. The middleware never inspects keys supplied in the XML body, so any ../ segment inside a body-supplied key is passed through to the filer path resolver. The filer collapses those traversal sequences using standard path joining, producing an absolute file path outside the authorized bucket. The gateway then issues delete operations against those resolved paths using the gateway's own privileges rather than the caller's bucket scope.

Root Cause

The root cause is inconsistent input validation across authorization surfaces. Path validation logic exists but is applied only to URL-derived path variables. Body-supplied object keys are treated as opaque strings and forwarded to path.Join operations that normalize traversal sequences. The absence of a shared segment-level validator lets .., embedded slashes, and similar characters reach the filer.

Attack Vector

An attacker authenticates as any S3 principal with write access to a single bucket they legitimately control. They then send a POST /<their-bucket>?delete request containing a DeleteObjects XML body with keys such as ../victim-bucket/critical-object. The gateway validates the URL path against the attacker's bucket, accepts the request, and forwards each key to the filer, which resolves and deletes objects in the victim's bucket.

// Security patch: weed/s3api/iceberg/path_validation.go
// isValidTablePath reports whether a "/"-separated table path (the part below
// the bucket) is free of segments that path.Join would collapse to escape the
// bucket directory. Empty segments (from leading/duplicate slashes) are ignored.
func isValidTablePath(tablePath string) bool {
	for _, segment := range strings.Split(tablePath, "/") {
		if segment == "" {
			continue
		}
		if !isValidNameSegment(segment) {
			return false
		}
	}
	return true
}

// isValidNameSegment rejects a single path-segment value (bucket prefix slot,
// table name, or one namespace part) that would be unsafe to embed in a filer
// path: `.`, `..`, embedded slash/backslash, or NUL.

Source: GitHub Commit 0345658

The patch introduces isValidTablePath and reuses isValidNameSegment to reject ., .., embedded slashes, backslashes, and NUL bytes before any filer path is constructed. Callers now also confirm the target bucket matches the authorized bucket.

Detection Methods for CVE-2026-58372

Indicators of Compromise

S3 POST requests to /{bucket}?delete where the XML body contains object keys with ../, ..%2F, or leading / characters.
Filer audit logs showing delete operations against paths outside the requesting principal's authorized bucket.
Sudden unexplained object deletions across multiple buckets attributable to a single S3 access key.
SeaweedFS weed s3 versions below 4.34 running in multi-tenant configurations.

Detection Strategies

Parse S3 gateway access logs and flag DeleteObjects bodies containing .. segments in <Key> elements.
Correlate S3 access key identity against the bucket paths of resulting filer delete events; mismatches indicate exploitation.
Deploy request-body inspection at the proxy or WAF layer for S3 traffic destined for SeaweedFS gateways.

Monitoring Recommendations

Enable verbose logging on the SeaweedFS filer and forward delete events to a centralized log platform for correlation.
Alert on high-volume DeleteObjects requests, particularly from tenants that historically issue single-object deletes.
Track object count baselines per bucket and trigger alerts on statistically anomalous drops.

How to Mitigate CVE-2026-58372

Immediate Actions Required

Upgrade SeaweedFS to version 4.34 or later on all filer and S3 gateway nodes.
Rotate S3 access keys for any tenant suspected of abusing the gateway.
Audit filer object inventories against known-good backups to identify unauthorized deletions.
Restrict S3 gateway network exposure to trusted tenants until patching is complete.

Patch Information

The fix is available in SeaweedFS release 4.34 and was merged via Pull Request 9931. Details are documented in GitHub Security Advisory GHSA-w62w-66v9-vvgv and the VulnCheck Advisory. The patch adds isValidTablePath segment validation and enforces that the resolved bucket matches the authorized bucket.

Workarounds

Place a reverse proxy or API gateway in front of the SeaweedFS S3 endpoint that inspects DeleteObjects XML bodies and rejects any <Key> containing .. or leading / characters.
Disable bulk delete operations by blocking POST /{bucket}?delete for untrusted principals until an upgrade is completed.
Segregate tenants across separate SeaweedFS clusters so that traversal cannot cross tenant boundaries.

bash

# Example NGINX request-body filter for SeaweedFS S3 gateway
location ~* /\?delete$ {
    client_body_in_single_buffer on;
    set $bad_body 0;
    if ($request_body ~* "\.\./") { set $bad_body 1; }
    if ($request_body ~* "%2e%2e%2f") { set $bad_body 1; }
    if ($bad_body = 1) { return 400 "Invalid object key"; }
    proxy_pass http://seaweedfs_s3_upstream;
}