CVE-2026-55874: Cross-Bucket Path Traversal in SeaweedFS S3 API Gateway

The S3 API Gateway in SeaweedFS is a critical component that exposes an Amazon S3-compatible interface on top of the distributed SeaweedFS Filer backend. This gateway maps S3 operations, such as object uploads, downloads, and copies, to the underlying hierarchical file storage. Because the gateway handles authentication and authorization, it acts as the security boundary enforcing isolation between different S3 buckets and their associated user policies.

The vulnerability, designated as CVE-2026-55874, is an implementation flaw in the way the S3 API Gateway processes server-side copy requests. Specifically, the vulnerability resides within the handlers for the S3 CopyObject and UploadPartCopy operations. These operations allow clients to duplicate existing objects inside the storage cluster without downloading and re-uploading the data, which optimizes network performance.

By failing to perform proper path validation on user-controlled headers during these copy operations, the S3 API Gateway exposes a path traversal interface. An authenticated user who is restricted to a single bucket can read any object across the entire SeaweedFS deployment. The vulnerability represents a serious breakdown of the multi-tenancy model in SeaweedFS environments that rely on S3 bucket-level isolation.

The root cause of CVE-2026-55874 is the improper limitation of a pathname to a restricted directory (CWE-22) when parsing the X-Amz-Copy-Source header. In a standard S3 copy operation, the destination of the copy is defined by the HTTP request URL, while the source is declared in the X-Amz-Copy-Source request header. The S3 API Gateway performs access control checks against the destination path specified in the URL to ensure the client has writing privileges.

Once authorization is verified for the destination bucket, the gateway parses the X-Amz-Copy-Source header to resolve the location of the source object. Prior to version 4.34, the parser divided the header value into two parts: the bucket name and the object key. However, the gateway only checked whether these extracted strings were non-empty, neglecting to validate or sanitize them for directory traversal sequences.

When these components are handed off to the SeaweedFS Filer backend, they are concatenated into a single path using filesystem path resolution helpers. Because the object key parsed from the header can contain path traversal segments like .. or %2e%2e, the resulting path collapses past the root of the source bucket. This behavior allows the path to resolve to folders belonging to other buckets, making it a classic confused-deputy attack.

The vulnerability is primarily located in the path validation logic of the S3 API Gateway. In vulnerable versions of SeaweedFS, the validation of copy sources was insufficient, especially in the handler for multipart upload copy operations (CopyObjectPartHandler).

The following code comparison highlights how the vulnerability was introduced and subsequently remediated in the official patch. The fix ensures that both the parsed source bucket and the source object key conform to strict naming and path constraints before any filesystem operation occurs.

// Vulnerable implementation in weed/s3api/s3api_object_handlers_copy.go
// Prior to the patch, the copy part handler used a simple non-empty validation
if srcObject == "" || srcBucket == "" {
    glog.Errorf("CopyObjectPart: Invalid copy source - srcBucket=%q, srcObject=%q", srcBucket, srcObject)
    s3err.WriteErrorResponse(w, r, s3err.ErrInvalidCopySource)
    return
}

The patch introduces the ValidateCopySource helper, which is called by both the standard single-object copy handler and the multipart copy handler. This helper executes the standard bucket and object validation routines against the extracted values to block traversal segments.

// Patched implementation in weed/s3api/s3api_copy_validation.go
func ValidateCopySource(copySource string, srcBucket, srcObject string) error {
    // ... basic parsing logic ...
 
    // Reject '.' and '..' segments to ensure the source object remains constrained
    // within the boundary of the authorized source bucket.
    if !s3_constants.IsValidBucketName(srcBucket) || !s3_constants.IsValidObjectKey(srcObject) {
        return &CopyValidationError{
            Code:    s3err.ErrInvalidCopySource,
            Message: "Copy source contains invalid path segments",
        }
    }
 
    return nil
}

By calling IsValidObjectKey on the parsed srcObject, the application leverages existing path validation logic that flags any key containing path traversal components. This blocks the resolver from executing path-collapsing operations on the backend filer.

Exploiting CVE-2026-55874 requires standard authenticated S3 credentials with write permissions to at least one bucket. The attacker must also possess knowledge of, or be able to guess, the names of target buckets and specific object keys on the SeaweedFS deployment. Because S3 bucket naming schemes are often predictable, target identification is highly feasible in real-world scenarios.

To initiate the exploit, the attacker crafts a PUT request targeting their own authorized bucket, setting the destination file to any path. The attacker then injects the directory traversal sequence into the X-Amz-Copy-Source header, pointing back from their bucket and traversing forward into the victim's bucket.

PUT /attacker-bucket/exfiltrated-file.dat HTTP/1.1
Host: target-seaweedfs:8333
Authorization: AWS4-HMAC-SHA256 Credential=AKIAIOSFODNN7EXAMPLE/...
X-Amz-Copy-Source: /attacker-bucket/../victim-private-bucket/sensitive-data.xml

When the S3 API Gateway processes this request, it verifies the attacker's write permissions on /attacker-bucket/exfiltrated-file.dat. It then parses the X-Amz-Copy-Source header, leading the backend filer to fetch the data from the resolved path /buckets/victim-private-bucket/sensitive-data.xml. Once the server-side copy completes, the attacker can retrieve the exfiltrated object directly from their own bucket using a standard GET request.

The attack can also be mounted using various encoding techniques to bypass simplistic edge filters. The gateway's parser is vulnerable to standard URL encoding (%2e%2e), alternative path separators (such as backslashes ), and nested directory segments designed to escape deep structures. The dedicated regression test suite added in the patch confirms that all of these variants were viable vectors before the patch.

The security impact of CVE-2026-55874 is classified as High, with a CVSS v3.1 base score of 7.7. The attack vector is Network (AV:N), and the complexity is Low (AC:L), meaning it can be reliably exploited without specialized environment configurations. The vulnerability requires Low privileges (PR:L), as any user with valid S3 credentials can act as the attacker.

Crucially, the Scope metric is Changed (S:C) because the vulnerability allows an attacker to cross security boundaries. By forcing the gateway to read data from a bucket outside their administrative scope, the attacker completely undermines the isolation of the SeaweedFS S3 environment. Confidentiality is impacted at a High level (C:H), as all objects stored in any bucket on the deployment are exposed to unauthorized reading.

Because the vulnerability is limited to read operations via the copy mechanism, there is no direct threat to Integrity (I:N) or Availability (A:N). Attackers cannot overwrite or delete files in target buckets through this traversal exploit. However, the exposure of highly sensitive files, such as database backups, configuration files, and application secrets, can easily serve as a stepping stone for further compromise.

The definitive remediation for CVE-2026-55874 is upgrading the SeaweedFS deployment to version 4.34 or later. The update introduces the necessary code changes in the S3 API Gateway component to strictly validate incoming copy requests. Deployments can be updated in-place without data migration, as the fix only affects the stateless gateway layer.

If an immediate upgrade is not feasible, organizations should implement virtual patching using a Web Application Firewall (WAF) or an API Gateway positioned in front of the SeaweedFS S3 interface. The WAF should be configured to inspect the X-Amz-Copy-Source header of all inbound PUT requests. Any request containing traversal sequences should be blocked immediately.

Additionally, security administrators should audit SeaweedFS S3 API logs for suspicious copy operations. Look for requests containing parent directory specifiers or percent-encoded variations in the S3 log metadata. Implementing continuous monitoring for unusual data access patterns from low-privilege accounts will help detect exploitation attempts in legacy deployments.