SeaweedFS EUVD-2026-66770

Exploitation requires: (1) a valid SeaweedFS S3 API credential with at least PutObjectAcl permission on a nested object key (e.g., prefix/filename.ext); (2) the deployment must use the static S3 identity file to configure object-level action scoping that grants access to a nested path; (3) a target object must exist at the bucket root sharing the same basename as the attacker's scoped nested key (e.g., root-level filename.ext). Exploitation is limited to overwriting objects at the bucket root whose basename matches the attacker's allowed nested key - it cannot overwrite arbitrary keys. Attackers cannot read unauthorized data. Unauthenticated principals cannot exploit this flaw. Deployments where all principals have full bucket access, or where no root-level objects share basenames with nested keys, are not exposed.

CVSS 7.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L) reflects a network-exploitable, low-complexity flaw requiring only a valid low-privilege S3 credential. The high integrity score is well-founded: successful exploitation completely replaces the target object's content, metadata, and ACL, which in a multi-tenant or namespace-isolated deployment constitutes a serious authorization boundary violation. The availability impact is rated Low because the overwrite destroys the target object's data as a side effect. There is no confidentiality impact - the attacker cannot read data they are not authorized to read. EPSS data was not provided in source intelligence; without it, probabilistic exploitation likelihood cannot be quantified. The absence from CISA KEV and the lack of any reported POC code suggest opportunistic exploitation is currently low, but the vulnerability is mechanically straightforward once an attacker understands the path confusion. The fix commit and advisory are public, which lowers the barrier to reverse-engineering an exploit. Deployments using SeaweedFS with fine-grained S3 identity file scoping across nested key hierarchies are at material risk.

An attacker operating as a low-privilege S3 tenant scoped only to tenant-uploads/report.csv calls PutObjectAcl on that key with a crafted ACL body. The handler authorizes the request correctly, but resolves the write-back directory to the bucket root and overwrites report.csv at the root level - replacing a different user's or administrator's object with the attacker's own content, metadata, and ACL grants. No exploit code is publicly known, but the exact path resolution error is exposed in the public fix commit, making the attack trivially reconstructable.