CVE-2026-77368: 
Wolfi vulnerability analysis and mitigation

CVE-2026-77368 is an authenticated cross-prefix Insecure Direct Object Reference (IDOR) vulnerability in the SeaweedFS filer's TUS resumable-upload handler, classified as an Authorization Bypass Through User-Controlled Key (CWE-639). It affects SeaweedFS version 4.39 and is fixed in version 4.40. A low-privilege tenant who obtains another tenant's TUS session identifier can hijack that session to write attacker-controlled content to filer paths their own JWT explicitly forbids, delete other tenants' sessions, or read upload metadata. It carries a CVSS v3.1 base score of 7.6 (High) (GitHub Advisory).

The root cause is that checkTusJwtAuthorization in weed/server/filer_server_tus_handlers.go only populated the scopedPaths list (used for JWT allowed_prefixes enforcement) during session creation (HTTP POST). For HEAD, PATCH, and DELETE verbs acting on an existing session by its UUID, scopedPaths remained empty, causing the prefix-check loop in checkJwtAuthorization to never execute and the function to return true — authorizing the request on JWT signature and method alone without verifying the session's stored TargetPath against the caller's AllowedPrefixes. The session UUID was incorrectly treated as an authorization boundary, but it is obtainable by a legitimate tenant from a leaked Location header, server logs, or a shared upload link. A self-contained Go integration PoC (test/tus/tus_idor_auth_test.go) was included in the advisory and reproduced end-to-end against a real cluster built from vulnerable 4.39 source (GitHub Advisory, Fix Commit ce82e3a).

Successful exploitation allows an authenticated low-privilege tenant to write attacker-controlled content to any filer path — including S3 /buckets/... paths — that their own JWT explicitly forbids, effectively bypassing multi-tenant prefix isolation. Additionally, the attacker can DELETE other tenants' in-progress upload sessions (denial of service against uploads) and use HEAD to read upload progress and declared size (information disclosure). The vulnerability is bounded by the requirement for a valid filer write JWT and knowledge of a target session UUID, but in multi-tenant deployments relying on allowed_prefixes as a tenant boundary, the impact is a cross-tenant arbitrary write (GitHub Advisory).

A working PoC was developed and reproduced end-to-end by the reporter (AdrianAcala) against a real SeaweedFS 4.39 cluster using Docker and curl, and a Go integration test is included in the fix commit. Exploitation requires a valid (low-privilege) filer write JWT and knowledge of a victim's TUS session UUID — the latter is obtainable from a leaked Location response header, server logs, or a shared upload link. The vulnerability only affects deployments with both jwt.filer_signing.key configured and TUS uploads enabled. No in-the-wild exploitation has been reported, and the EPSS score is 0.0. It is not listed in the CISA KEV catalog (GitHub Advisory).

1. Prerequisite: Obtain a valid low-privilege filer write JWT scoped to a permitted prefix (e.g., /buckets/allowed), and identify a SeaweedFS 4.39 deployment with jwt.filer_signing.key configured and TUS uploads enabled.
2. Obtain victim session UUID: Acquire another tenant's TUS session UUID from a leaked Location response header (e.g., from shared upload links, server logs, or network interception). The UUID is of the form /.tus/.uploads/<uuid>.
3. Confirm direct write is blocked: Verify that a direct PUT to the victim's path (e.g., /buckets/secret/victim.bin) with the attacker's token returns HTTP 401, confirming JWT enforcement is active.
4. PATCH the victim's session: Send an HTTP PATCH to /.tus/.uploads/<victim-session-uuid> with the attacker's JWT, including headers Tus-Resumable: 1.0.0, Upload-Offset: 0, Content-Type: application/offset+octet-stream, and the attacker-controlled payload body. The server returns HTTP 204 without checking the session's TargetPath against the attacker's AllowedPrefixes.
5. Content lands at victim's path: On upload completion, completeTusUpload calls CreateEntry at the session's stored TargetPath (e.g., /buckets/secret/victim.bin) with the attacker's content, achieving an arbitrary cross-prefix write.
6. Optional — DELETE or HEAD victim sessions: Use the same attacker token to send DELETE (cancels the victim's upload, HTTP 204) or HEAD (reads upload offset and size, HTTP 200) against other tenants' session UUIDs (GitHub Advisory).

• Network: Unexpected HTTP PATCH, DELETE, or HEAD requests to /.tus/.uploads/<uuid> from a tenant whose JWT allowed_prefixes does not match the session's target path; cross-tenant TUS session interactions visible in filer access logs.
• Logs: Filer access logs showing PATCH/DELETE/HEAD requests to /.tus/.uploads/ endpoints succeeding (HTTP 204/200) for tokens scoped to a different prefix than the session's TargetPath; absence of jwt path not allowed log entries for such requests (pre-patch behavior).
• File System: Unexpected or attacker-controlled file content appearing at tenant-restricted filer paths (e.g., /buckets/secret/) that the writing tenant's JWT should not permit; file timestamps inconsistent with legitimate tenant activity.
• Behavioral: TUS sessions being deleted (HTTP 204 on DELETE) by a principal whose JWT prefix does not match the session target; upload progress queries (HEAD) returning data for sessions belonging to a different tenant's prefix (GitHub Advisory).

Upgrade SeaweedFS to version 4.40, which resolves the issue by extending checkTusJwtAuthorization to resolve the session's stored TargetPath for HEAD, PATCH, and DELETE verbs and scope-check it against the caller's AllowedPrefixes, failing closed on any resolution error. The fix also splits JWT authentication from path authorization, enforces canonical UUID session IDs, and revalidates the pinned session before completing an upload. No configuration-based workaround is available for version 4.39; the only mitigation short of upgrading is to disable TUS uploads or remove jwt.filer_signing.key (which removes JWT enforcement entirely and is not recommended for multi-tenant deployments) (GitHub Advisory, Fix Commit ce82e3a, Fix Commit fa549e9).