CVE-2026-54917: Cross-Bucket Path Traversal and Authorization Bypass in SeaweedFS S3 and Iceberg Gateways

SeaweedFS is a highly scalable distributed storage system designed to support object storage (S3), file systems, and Iceberg tables. Within its architecture, the S3 API gateway and the Iceberg REST catalog gateway serve as translation layers, converting high-level object queries into low-level operations processed by the SeaweedFS distributed filer. These gateways rely on the gorilla/mux library for HTTP routing and parameter parsing.

To preserve raw path structures for specific storage use cases, both gateways historically initialized their routing engines with mux.NewRouter().SkipClean(true). Disabling canonical path cleaning prevents the routing engine from resolving relative directory navigation tokens, such as double dots (..), before matching incoming URIs. This configuration leaves the gateways exposed to path manipulation attacks.

When a request contains a directory traversal sequence, the router matches the catch-all pattern and forwards the unmodified path to the application logic. This behavior violates tenant isolation boundaries, as the relative segments remain intact during the routing and authorization phases. The complete bypass allows any authenticated tenant to access assets across the entire cluster.

The root cause of CVE-2026-54917 lies in a logic discrepancy between the router's path parameter extraction and the backend's path resolution mechanisms. In a standard configuration, relative path elements are normalized at the edge; however, with SkipClean(true) active, the raw traversal tokens bypass edge validation entirely.

When an attacker issues a crafted request, the router assigns the first segment as the {bucket} variable and the remainder as the {object} variable. Because the IAM authorization check is evaluated solely against the extracted {bucket} variable, the gateway validates and permits the request under the assumption that the caller is accessing their own authorized resource.

Following authorization, the gateway constructs the physical storage path by joining the bucket root with the unsanitized object key. The backend filer relies on Go's path.Join or util.JoinPath (which call filepath.Clean) to finalize the path structure. This execution collapses the relative directory sequences, shifting the target of the operation to an unauthorized destination.

Prior to version 4.30, the S3 API gateway lacked validation checks to verify whether captured route variables contained relative directory traversal sequences. The system's standard variable sanitization function, NormalizeObjectKey, was designed only to convert backslashes and collapse duplicate slashes.

// Vulnerable path resolution logic
func (s3a *S3ApiServer) toFilerPath(bucket, object string) string {
    object = s3_constants.NormalizeObjectKey(object)
    return fmt.Sprintf("%s/%s", s3a.bucketDir(bucket), object)
}

To resolve this vulnerability, the maintainers implemented path validation middleware to intercept incoming requests before handlers process them. This middleware verifies that neither the bucket name nor the object key contains elements capable of traversing directories.

// Patched object key validation checks
func IsValidObjectKey(object string) bool {
    if object == "" {
        return true
    }
    if strings.ContainsRune(object, '\x00') {
        return false
    }
    object = strings.ReplaceAll(object, "\\", "/")
    for _, seg := range strings.Split(object, "/") {
        if seg == "." || seg == ".." {
            return false
        }
    }
    return true
}

This validation logic ensures that any route variable containing null bytes, directory traversal patterns, or structural separators is rejected immediately. The corresponding middleware throws an HTTP 400 Bad Request error before downstream operations are triggered.

Exploiting CVE-2026-54917 requires that the attacker possess valid S3 API credentials for at least one bucket on the targeted SeaweedFS deployment. Because standard client libraries automatically normalize directory traversal sequences before transmission, attackers must manually construct the raw HTTP requests.

To execute the exploit, a script manually computes and appends the S3 AWS Signature Version 4 (SigV4) headers. The raw HTTP request line is written directly to the socket to prevent the client runtime from removing the traversal characters. The request includes the traversal sequence inside the path parameter, targeting an unauthorized bucket.

# Signature generation logic requires signing the unnormalized canonical URI
wire, canon = build_paths(bucket, target_bucket, key, variant)
payload_sha = hashlib.sha256(body).hexdigest()
headers = sign_v4(method, host, port, wire, canon, ak, sk, region, payload_sha)

When the S3 gateway receives this request, it decodes the URI and authenticates the user for the legitimate bucket. After authorization, the backend resolves the path traversal to perform read or write operations against the target bucket, completely bypassing tenant isolation boundaries.

The impact of this vulnerability is critical, as it allows complete horizontal privilege escalation across tenant boundaries. Any user with read or write credentials for a single bucket can access, modify, or delete files across all other buckets on the system.

This bypass undermines the data confidentiality and integrity guarantees of multi-tenant SeaweedFS deployments. Attackers can exfiltrate raw database backups, sensitive system files, or proprietary data objects, or overwrite existing objects with malicious payloads.

This flaw has been assigned a CVSS v3.1 base score of 10.0, reflecting its low complexity, network-based attack vector, and the lack of high-level privileges required to compromise tenant isolation. Because the flaw affects multiple protocol gateways, it represents a systemic vulnerability in the access control layer.