CVE-2026-55873 SeaweedFS Authorization Bypass – S3Tables Metadata Enumeration

Technical summary

The vulnerability stems from a failure in authorization logic within SeaweedFS's SigV4 request handling for S3Tables operations. When a SigV4-signed request targeting the S3Tables service is received, the system lacks proper identity validation and collapses account-less S3 identities into a default administrative account context. This causes authorization checks to fail open, granting unintended access to privileged operations. The issue is classified as an authorization bypass (CWE-863) with limited blast radius: only read operations exposing bucket metadata are affected. The flaw exists in affected versions' routing and permission enforcement layers; versions 4.34+ implement corrected identity resolution and stricter authorization boundaries.

Business impact

This vulnerability creates a controlled but meaningful information-disclosure risk. Attackers with valid S3 credentials—including contractors, third parties, or compromised service accounts with minimal privilege—can enumerate hidden administrator resources without legitimate business access. For organizations using SeaweedFS to isolate sensitive table buckets or maintain confidentiality of bucket naming conventions, this represents a breach of access control boundaries. The risk is contained because no data exfiltration, modification, or service disruption is possible. However, the disclosure of ARNs and bucket names can facilitate follow-up attacks or reveal organizational structure. Organizations managing multi-tenant or highly regulated workloads should prioritize awareness of this issue.

Affected systems

SeaweedFS deployments running versions 4.08 through 4.33 that expose S3Tables functionality are affected. The vulnerability applies only to requests signed with AWS SigV4 targeting S3Tables; native SeaweedFS S3 operations do not trigger the flaw. Organizations using SeaweedFS in air-gapped or non-S3Tables configurations face no risk. Impact is limited to authenticated users with existing S3 credentials; unauthenticated or anonymous access does not exploit this issue. Verify your installed version against the vendor's official release history and assess whether S3Tables is enabled in your deployment architecture.

Exploitability

Exploitation requires valid AWS credentials with at least basic S3 read permissions. The attack is straightforward: an authenticated user crafts SigV4-signed requests to the S3Tables API and observes responses containing admin-owned bucket metadata. No special tools, race conditions, or timing attacks are required. However, the vulnerability is not remotely exploitable by unauthenticated attackers; it represents a privilege escalation within a credentialed context. The barrier to exploitation is low for insiders or accounts with compromised credentials, but the scope is limited to metadata enumeration. This profile places it in the medium-risk category and explains the CVSS 4.3 score reflecting low immediate severity tempered by mandatory authentication.

Remediation

Upgrade SeaweedFS to version 4.34 or later to receive the upstream fix. Before upgrading, audit S3Tables access logs (if available) to identify any suspicious enumeration activity from low-privileged accounts. If immediate upgrade is not feasible, restrict S3Tables API exposure to trusted networks or IAM principals only, and monitor for anomalous requests from unexpected identities. Consider disabling S3Tables functionality entirely if your deployment does not require it. Test the upgrade in a staging environment first to ensure compatibility with existing workloads.

Patch guidance

Consult the SeaweedFS project's official release notes for version 4.34+ to confirm the fix and any compatibility notes. Prioritize patching in environments where S3Tables is actively used and where multiple IAM identities have S3 access. Coordinate with your infrastructure and application teams to minimize downtime during the upgrade. Verify post-patch behavior by testing SigV4-signed S3Tables requests with low-privileged test credentials to confirm that bucket enumeration is no longer possible. Monitor release channels for any follow-up security advisories.

Detection guidance

Review CloudTrail or access logs for unusual patterns of S3Tables API calls from low-privileged IAM users, particularly ListBuckets or DescribeBucket operations. Look for requests originating from accounts that should not have administrative bucket visibility. Set up alerts for SigV4-signed requests from service accounts or contractor credentials accessing S3Tables endpoints. If your SeaweedFS deployment includes detailed audit logging, search for authorization bypass attempts or identity-collapse events. Baseline normal S3Tables usage patterns so that anomalies stand out.

Why prioritize this

While this is a medium-severity vulnerability limited to metadata disclosure and requiring authentication, it should not be overlooked. Information about bucket names and ARNs can enable lateral movement, reconnaissance, or compliance violations if sensitive naming conventions are exposed. Organizations with strict data classification policies, regulated industries (finance, healthcare), or multi-tenant architectures should treat this as a near-term fix. For environments where S3Tables is not used or where access is already tightly controlled, the risk is proportionally lower. Patch timelines should reflect your organization's sensitivity to information disclosure and the privileges of compromised accounts in your threat model.

Risk score, explained

The CVSS 4.3 score reflects a medium-severity profile: authentication is required (PR:L), the attack vector is network-accessible (AV:N), no user interaction is needed (UI:N), and the attack has no privileges escalation or system impact (I:N, A:N). The sole impact is confidentiality loss (C:L) through metadata enumeration. The score is appropriate because it captures that the vulnerability is exploitable by insiders or low-privileged users but cannot be weaponized for widespread data theft or system compromise. Organizations should not dismiss a 4.3 score as negligible; in many regulatory and security frameworks, any information disclosure of privileged metadata warrants expedited remediation.

Frequently asked questions