CVE-2026-55874 in SeaweedFSinfo

Summary

by MITRE • 07/08/2026

SeaweedFS is a distributed storage system. Prior to 4.34, the S3 API gateway does not reject dot-dot path segments in the X-Amz-Copy-Source header used by CopyObject and UploadPartCopy, allowing an authenticated identity scoped to one bucket to read objects from other buckets through server-side copy. This issue is fixed in version 4.34.

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Analysis

by VulDB Data Team • 07/08/2026

SeaweedFS represents a distributed storage system architecture that provides scalable object storage capabilities through its S3 API gateway interface. The vulnerability resides within the gateway's handling of specific HTTP headers used during object manipulation operations, particularly affecting the X-Amz-Copy-Source header implementation. This security flaw exists in versions prior to 4.34 and demonstrates a critical path traversal weakness that bypasses normal access control mechanisms. The system's authentication and authorization framework fails to properly validate path segments within the copy source specification, creating an unauthorized data access vector.

The technical execution of this vulnerability leverages the CopyObject and UploadPartCopy S3 API operations where the X-Amz-Copy-Source header contains a specially crafted path that includes dot-dot sequences. These path traversal elements allow an authenticated user with access to one bucket to reference objects in other buckets by manipulating the copy source parameter. The system processes these requests without proper validation of the path components, enabling cross-bucket data reading through server-side copy operations. This represents a classic path traversal vulnerability where the security boundary between storage buckets is violated through improper input sanitization.

The operational impact of this vulnerability extends beyond simple unauthorized access to encompass potential data exfiltration and privacy violations across multiple tenants within the same SeaweedFS deployment. An authenticated attacker can exploit this weakness to read objects from buckets they should not have access to, potentially exposing sensitive information stored in different storage compartments. The server-side copy operation amplifies the risk because it occurs entirely within the system's internal processing without requiring explicit data transfer to the attacker's control point. This vulnerability directly violates fundamental security principles of isolation and access control that are essential for multi-tenant distributed storage systems.

The fix implemented in version 4.34 addresses this issue through enhanced input validation of the X-Amz-Copy-Source header, specifically rejecting dot-dot path segments that could enable cross-bucket access. This remediation aligns with established security practices for preventing path traversal attacks and demonstrates proper defense-in-depth principles. Organizations using SeaweedFS should immediately upgrade to version 4.34 or later to mitigate this vulnerability. Security teams should also implement monitoring for unusual copy operations and validate that all authentication scopes are properly enforced across bucket boundaries. The vulnerability classification aligns with CWE-22 Path Traversal and relates to ATT&CK technique T1074 Data Staging, as it enables unauthorized data access through legitimate system interfaces.

This vulnerability highlights the critical importance of input validation in distributed storage systems where multiple tenants share infrastructure resources. The issue demonstrates how seemingly benign API operations can become attack vectors when proper security controls are not implemented at every layer of the system architecture. Organizations should conduct comprehensive security assessments of their distributed storage deployments to identify similar path traversal vulnerabilities in other components and ensure that all cross-domain access controls are properly enforced. The remediation process requires careful validation to ensure that legitimate use cases for copy operations continue to function while eliminating the unauthorized access pathways that this vulnerability creates.

Responsible

GitHub M

Reservation

06/17/2026

Disclosure

07/08/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

very low

Sources

Do you want to use VulDB in your project?

Use the official API to access entries easily!