CVE-2026-77611: 
Wolfi vulnerability analysis and mitigation

CVE-2026-77611 is an authenticated S3 object-scope bypass vulnerability in SeaweedFS, a distributed storage system for files and blobs. An authenticated S3 principal with permissions scoped to a nested object key (e.g., target-bucket/allowed/protected.txt) can overwrite a different object outside that scope (e.g., target-bucket/protected.txt) by calling PutObjectAcl on the key it is authorized to access. The vulnerability affects all SeaweedFS versions prior to 4.40 and is fixed in version 4.40. It carries a CVSS v3.1 base score of 7.1 (High) (GitHub Advisory).

The root cause is an incorrect authorization logic flaw (CWE-863: Incorrect Authorization) in the PutObjectAclHandler within weed/s3api/s3api_object_handlers_acl.go. The handler correctly authorizes the incoming request against the full requested nested object key, but when writing the updated entry back to the filer, it unconditionally sets the updateDirectory to the bucket root (s3a.bucketDir(bucket)) rather than the actual parent directory of the nested key. As a result, a PutObjectAcl call on allowed/protected.txt resolves the entry name as protected.txt and writes it to the bucket root, overwriting protected.txt there with the full entry — including content, metadata, owner, and ACL — of the scoped object. The fix, introduced in commit 311bc3a, adds a new objectAclUpdateDirectory helper that correctly derives the parent directory from the full object key path using util.NewFullPath(...).DirAndName() (GitHub Advisory, Fix Commit).

A successful exploit allows an authenticated but low-privileged S3 principal to overwrite the content, metadata, owner information, and ACL of an object it has no explicit permission to modify, bypassing object-level action scoping configured via the static S3 identity file (-s3.config). The primary impact is a high integrity loss — arbitrary object data can be silently replaced — with a low availability impact if the overwritten object is critical to operations. There is no direct confidentiality impact, but unauthorized ACL replacement could grant the attacker read access to previously restricted objects. In multi-tenant or multi-principal deployments sharing a bucket, this could enable cross-user or cross-tenant data corruption (GitHub Advisory).

A working proof-of-concept (PoC) Python script using boto3 is publicly included in the GitHub Security Advisory, demonstrating the full exploit flow. Exploitation requires valid S3 credentials with Write and WriteAcp permissions scoped to a nested key, but no elevated privileges beyond that. The EPSS score is 0.0, indicating low current predicted exploitation probability, and the vulnerability is not listed in the CISA KEV catalog. No in-the-wild exploitation or threat actor attribution has been reported as of the disclosure date (GitHub Advisory).

1. Obtain scoped credentials: Acquire valid S3 credentials for a principal configured with Write and WriteAcp permissions scoped to a nested key, e.g., target-bucket/allowed/protected.txt*, via the SeaweedFS -s3.config identity file.
2. Upload attacker-controlled object: Use the scoped credentials to upload content to the authorized nested key (target-bucket/allowed/protected.txt) with the desired replacement content.
3. Confirm victim object exists: Using an admin account or out-of-band knowledge, verify that a victim object with the same basename exists at the bucket root (e.g., target-bucket/protected.txt).
4. Trigger the bypass via PutObjectAcl: Call PutObjectAcl on the authorized nested key (target-bucket/allowed/protected.txt) using the scoped credentials (e.g., scoped_writer.put_object_acl(Bucket='target-bucket', Key='allowed/protected.txt', ACL='private')).
5. Verify overwrite: Read the victim object (target-bucket/protected.txt) using admin credentials. The content, metadata, owner, and ACL will have been replaced with those of the attacker-controlled nested object, confirming successful exploitation (GitHub Advisory).

• Logs: SeaweedFS filer or S3 API logs showing PutObjectAcl requests from a principal targeting a nested key (e.g., allowed/protected.txt) followed by unexpected modification timestamps on a root-level object with the same basename (protected.txt).
• Logs: Audit entries showing a low-privileged principal successfully modifying an object outside its configured permission scope.
• File System / Storage: Unexpected changes to object content, metadata, owner, or ACL on bucket-root objects that share a basename with objects in subdirectories, particularly after PutObjectAcl API calls.
• Network: S3 API traffic containing PutObjectAcl requests from principals whose configured scope is limited to nested keys (paths containing /), especially if the request frequency is anomalous (GitHub Advisory).

Upgrade SeaweedFS to version 4.40 or later, which includes the fix in commit 311bc3a that corrects the PutObjectAcl handler to write updates to the object's actual parent directory rather than the bucket root. No official configuration-based workaround is provided; as an interim measure, administrators can restrict WriteAcp permissions for all principals to prevent exploitation until patching is feasible. Deployments using SeaweedFS S3 API with credential-based access control and object-level or prefix-level scoped actions are specifically at risk and should prioritize upgrading (GitHub Advisory, Fix Commit).

The vulnerability was reported by security researcher 123chen-jiahui and published by SeaweedFS maintainer chrislusf via a GitHub Security Advisory on August 21, 2026. No significant broader media coverage, vendor statements beyond the advisory, or notable community discussion has been identified at this time (GitHub Advisory).