CVE-2026-77611: SeaweedFS: Authenticated S3 object-scope bypass in PutObjectAcl allows overwriting a different object with the same basename
SeaweedFS is a distributed storage system for files and blobs. In versions prior to 4.40, an authenticated S3 principal with permissions scoped to a nested object key can overwrite a different object outside that scope by calling PutObjectAcl on the key it is allowed to access. The handler authorizes the request against the requested nested key but then writes the updated entry back to the bucket root rather than the key's actual parent directory, so an ACL change on allowed/protected.txt is instead applied to protected.txt at the bucket root. Because the update carries the full entry rather than only ACL metadata, an existing target object is overwritten with the content, metadata, owner information, and ACL of the scoped object, bypassing the object-level action scoping configured through the static S3 identity file. This issue is fixed in version 4.40.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
SeaweedFSto a version that resolves this vulnerability.Fixed in 4.40
Event History
Frequently Asked Questions
Who can exploit this issue?
An authenticated S3 principal whose permissions are scoped to a nested object key can exploit it. The affected authorization model is object-level action scoping configured through the static S3 identity file.
What must an attacker do to overwrite an object outside their permitted scope?
The attacker needs permission for a nested key and calls PutObjectAcl on that allowed key. If an object with the same basename exists at the bucket root, the operation can overwrite that root-level object.
What is overwritten on the target object?
The target is overwritten with the scoped object's full entry, including its content, metadata, owner information, and ACL. This is not limited to an ACL-only change.
How can I determine whether an environment is affected?
SeaweedFS versions prior to 4.40 are affected. Exposure requires use of S3 object-level action scoping through the static S3 identity file and nested object keys that can share a basename with objects at the bucket root.
What is the available remediation?
Upgrade SeaweedFS to version 4.40, which fixes the issue.