SeaweedFS 4.40: four tenant-isolation flaws across S3, SFTP and TUS

Four published SeaweedFS vulnerability records form one important architectural story. CVE-2026-77298 concerns a role trust-policy bypass in direct OIDC authentication to the S3 interface, CVE-2026-77317 concerns unsafe path-prefix comparison in SFTP, CVE-2026-77368 concerns missing JWT scope revalidation during TUS session operations, and CVE-2026-77611 writes an ACL to a different object from the one used for authorization.

These are not four variants of one function. They sit in different protocols and require different conditions, but each breaks the same invariant: a principal should read or change only the resource that was evaluated by the same policy. The corresponding fixes landed in 4.40. Because a newer line is already available, teams should install the latest supported release; if an approved change window does not allow that, deploy at least 4.40 after regression testing.

The CVE records were indexed on 27 August. The related GitHub advisories and patches had been prepared earlier, and release 4.40 was published on 20 July. Today’s catalogue date therefore does not mean that the vendor only wrote the fixes today. It means administrators now have a coherent set of identifiers, affected ranges and risk scores that can be matched to inventory.

CVE-2026-77298: a valid OIDC token without the complete trust decision

SeaweedFS provides an S3-compatible API among its interfaces. In the affected direct OIDC path, the token was cryptographically validated and mapped to a role, but the code did not evaluate that role’s trust policy. The same token presented through the STS flow would have been rejected. The issue was therefore not missing signature verification; it was an inconsistency between two entrances to the same permission model.

That distinction matters. A signature answers whether a token came from the expected issuer and remained unmodified. It does not, by itself, decide whether a particular issuer, client, subject and set of conditions may assume a role. The trust policy is the second decision. Skipping it can grant a user permissions attached to a role they should not obtain.

According to the CVE record, versions through 4.39 are affected, 4.40 contains the fix, and the CVSS 4.0 score is 8.7 (High). Practical impact depends on OIDC configuration and role policies. A deployment without direct OIDC authentication to S3 does not expose this path. A deployment with one narrowly scoped role may face less impact than a platform where tokens map to administrative roles or broad bucket namespaces.

CVE-2026-77317: a string prefix is not a directory boundary

The SFTP ACL check compared paths as literal prefixes. If a tenant was permitted to access /tenants/alice, a plain starts-with test could also accept /tenants/alice2. That answer is true for strings but false for a directory tree: the two paths are sibling namespaces.

This is a classic confusion between a name and a structure. A correct check should canonicalise a path and then require either equality with the permitted directory or a separator immediately after the permitted prefix. It must also account for .., repeated separators, encoding and links where those concepts exist in the relevant layer.

The CVE covers versions 3.88 through 4.39 and has a CVSS 3.1 score of 8.1 (High). The advisory describes cross-tenant reading or overwriting of files where path beginnings collide. It is therefore insufficient to confirm that users “have separate folders.” Defenders must confirm how the application recognises the folder boundary on every operation.

CVE-2026-77368: authorising a TUS session only when it is created

TUS is a resumable upload protocol. In SeaweedFS 4.39, session creation checked the JWT allowed_prefixes claim against the target path. Later HEAD, PATCH and DELETE requests addressed a session identifier without reconstructing and checking the stored path’s scope. A user who knew another tenant’s session identifier could consequently interact with an upload outside the user’s own namespace.

The flaw illustrates the difference between authorising creation of a handle and authorising use of that handle. A session ID is merely a reference to state; it must not replace an access decision. A secure implementation binds the current identity and its current scope to the target resource stored in the session on every request.

The issue affects version 4.39 and deployments using both filer JWT authentication and TUS. Its score is CVSS 3.1 7.6 (High). Do not transfer that score mechanically to an installation without TUS. First establish whether the endpoint is active, reachable from an untrusted network and whether session identifiers could have appeared in logs, browser state, telemetry or error messages.

CVE-2026-77611: authorise a nested key, write an object at the root

The fourth flaw affects the S3 PutObjectAcl operation. The code authorised a request against a nested key the principal was entitled to access, but applied the entry update at bucket-root level. If an out-of-scope object had the same basename, its metadata could be overwritten.

This is a split between the authorization object and the mutation object. In code review, both inputs may appear reasonable: the request carries a bucket and key, while a write function receives a name. The mistake becomes visible only when reviewers prove that the path used by the permission engine is exactly the same normalised identifier handed to storage.

Releases before 4.40 are affected, and the score is CVSS 3.1 7.1 (High). This is not a general arbitrary-file write. It requires a specific combination of ACL-changing permission and a basename collision. In a multi-tenant environment, however, the ability to alter access control of an out-of-scope object is enough to treat the case as a material integrity incident.

Four distinct bugs, one security test

All four cases can be reduced to one question: is the resource used for the authorization decision identical to the resource on which the operation runs?

OIDC omitted one part of the decision: the role trust policy. SFTP treated a textual prefix as a structural boundary. TUS hid a once-checked path behind a session identifier. PutObjectAcl checked the full key but wrote its name in a different directory. These patterns belong in architectural reviews well beyond SeaweedFS.

A test matrix needs more than “allowed” and “denied.” Include adjacent names (alice and alice2), the same basename in separate directories, handles created by different principals, token renewal mid-session, role expiration and two alternative flows leading to the same role. Every protocol should terminate in one policy layer or prove that its decisions are equivalent.

What administrators should do now

Begin with an inventory of server versions, container images and deployment tooling. A Helm value does not always identify the digest actually running. Identify the processes and endpoints that really serve S3, SFTP, filer JWT and TUS. Then determine which of the four prerequisites are reachable in your configuration.

Deploy the latest supported SeaweedFS release—which is now newer than 4.40—or at least 4.40 when that is the approved remediation target. Before changing it, back up metadata according to the vendor procedure and test client compatibility, particularly OIDC role mapping, ACL operations, upload resumption and SFTP directory restrictions.

Do not treat removal of public routing as complete mitigation in a multi-tenant environment. A principal with a legitimate account, token or path in one tenant can still be the threat actor. Segmentation reduces reachability, but it does not restore missing object-level enforcement.

Until the update, disable unused protocols, remove direct OIDC-to-S3 flow in favour of a correctly controlled path, restrict TUS and SFTP to trusted networks and narrow role scopes. These are temporary measures. Each changes functionality and should be validated against a configuration copy.

Looking for signs of boundary violation

For OIDC, compare direct S3 authentication with STS decisions: one identity should not obtain a role through one path and receive a denial through the other. Log issuer, client, subject, role and policy outcome, but not complete tokens. Look for broad roles used by subjects that did not satisfy the trust policy.

For SFTP, review operations where the granted directory and actual path share a textual prefix but have a different first segment after that boundary. For TUS, correlate the session owner, target path or hash, and the principal making later method calls. A change of principal between creation and mutation needs investigation.

For S3 ACLs, compare the authorised full key with the metadata entry that was actually changed. Look for basename collisions and ACL changes at the bucket root during requests for nested objects. Preserve logs, role configuration, object metadata and image identifiers before rotating them.

Merely finding an affected version does not prove exploitation. Conversely, the absence of an HTTP error does not prove safety because the operations described may have succeeded from the client’s perspective. Incident assessment must combine reachability, principal permissions and a change to a concrete resource.

Primary facts and Breachroad conclusions

Vendor sources and CVE records describe affected versions, required configurations, flaw classes and the 4.40 fixes. The CVSS values come from those records. Recommendations about a common policy layer, boundary-focused test matrix, log correlation and selecting the latest supported release are Breachroad’s defensive conclusions derived from the documented mechanisms.

GitHub Advisory views may temporarily show an incomplete “patched version” field even though the CVE records, commits and release information identify 4.40. A vulnerability-management process should retain that discrepancy as a data-quality signal rather than close the finding only because one aggregator left a field empty.

Primary sources

Access boundaries most often fail at protocol seams, not in one obvious function. Our cybersecurity training for technical teams teaches engineers how to design and test these invariants across cloud, API and AI systems. If you need independent validation of a live deployment, web and API penetration testing can cover object authorization and tenant isolation within a controlled scope.