Seaweedfs
Monthly
Incorrect authorization in SeaweedFS S3 API's PutObjectAcl handler allows an authenticated low-privilege S3 principal to overwrite objects outside their permission scope. Versions prior to 4.40 compute the write-back directory from the bucket root rather than the actual parent directory of the nested key, meaning a principal scoped to `allowed/protected.txt` silently overwrites `protected.txt` at the bucket root - clobbering its content, metadata, owner, and ACL. No public exploit code identified at time of analysis, and this CVE is not listed in CISA KEV.
Incorrect path authorization in SeaweedFS SFTP server (versions 3.88-4.39) allows an authenticated low-privilege user to cross configured ACL boundaries and access or overwrite sibling tenants' files. The SFTP permission check used a bare string-prefix comparison, so a user scoped to /tenants/alice was also permitted access to any path beginning with those same characters - such as /tenants/alice-archive or /tenants/alice2 - without requiring a directory-component boundary. No public exploit code has been identified at time of analysis, though the public fix commit and advisory together fully document the vulnerable pattern, materially lowering exploitation difficulty for authenticated users.
Authorization bypass in SeaweedFS versions 4.39 and earlier allows authenticated federated users to assume IAM roles they are explicitly denied through the standard STS path. The S3 API's direct bearer token authentication path validates the OIDC JWT signature but skips trust policy enforcement, which the STS AssumeRoleWithWebIdentity path correctly applies. A federated user with a valid OIDC token can present it directly to the S3 API and obtain the mapped role's full S3 permissions - including object read, write, and delete - even when the role's trust policy explicitly rejects their identity provider. Version 4.40 patches the issue; no public exploit code has been identified at time of analysis.
SeaweedFS 4.39's TUS resumable-upload handler fails to re-validate JWT prefix scoping on HEAD, PATCH, and DELETE operations against existing sessions, enabling a low-privilege authenticated tenant to hijack cross-tenant upload sessions. An attacker holding a valid but restricted JWT token can PATCH arbitrary content into another tenant's in-progress upload by reusing the victim's session ID, causing the completed file to land at a filesystem path the attacker's token explicitly forbids. No public exploit has been identified at time of analysis; a vendor-released patch is available in version 4.40.
Server-side request forgery with response read-back in SeaweedFS distributed storage (versions prior to 4.24) lets anyone able to reach a volume server's gRPC port coerce the server, via the unauthenticated VolumeServer.FetchAndWriteNeedle RPC, into fetching arbitrary attacker-chosen URLs and returning the response. Because the volume server gRPC plane is unauthenticated by default and the documented JWT hardening does not cover this RPC, an unauthenticated remote attacker (CVSS:3.1 AV:N/PR:N, base 9.3) can reach loopback, RFC 1918, link-local, and cloud metadata endpoints such as 169.254.169.254 to steal IAM credentials and pivot to internal services. No public exploit identified at time of analysis, and it is not in CISA KEV; the fix landed in version 4.24.
Cross-tenant authorization bypass in SeaweedFS filer JWT path authorization allows any authenticated tenant to read and write data belonging to sibling tenants whose path names share a string prefix. Versions prior to 4.24 are affected: a scoped JWT issued for /tenant1 inadvertently passes the authorization check for /tenant1234, /tenant1-old, and any other path that begins with the same character sequence, because the check used Go's raw strings.HasPrefix rather than a path-component boundary comparison. No public exploit code has been identified at time of analysis, but the bypass is mechanically trivial for any holder of a valid scoped token and the exact attack patterns are documented in the fix's test suite.
Authentication bypass in SeaweedFS filer before 4.24 exposes the SeaweedIdentityAccessManagement gRPC service without any credential check whenever jwt.filer_signing.key is left unset, which is the default. Any client able to reach the filer's gRPC port can invoke CreateUser, CreateAccessKey, PutPolicy, and related IAM RPCs to mint their own access keys and obtain S3 administrative control over the storage cluster. Rated CVSS 9.8; no public exploit identified at time of analysis, though the upstream fix commit and PR are public.
Cross-tenant object deletion in SeaweedFS before 4.34 lets an authenticated S3 principal holding write access to just one bucket destroy arbitrary objects in other tenants' buckets through the S3 gateway's DeleteMultipleObjectsHandler. By embedding ../ sequences in object keys inside the DeleteObjects XML request body, an attacker exploits a confused-deputy gap where path validation never inspected body keys. Publicly available exploit code exists (reported by VulnCheck) and a vendor patch shipped in release 4.34; the flaw is not listed in CISA KEV.
Cross-bucket read/write in SeaweedFS before 4.30 lets remote attackers escape a bucket's namespace because the S3 API gateway and the Iceberg REST catalog gateway build their gorilla/mux routers with SkipClean(true), letting a literal '..' segment survive routing before downstream path joins collapse it server-side. A request like 'GET /bucket-A/../evil-bucket/key' is routed as bucket=bucket-A but resolves to evil-bucket, allowing an actor to read or write objects in buckets they should not reach. There is no public exploit identified at time of analysis; the issue is fixed in 4.30 via PR #9687.
Unvalidated JSONP callback reflection in SeaweedFS before 4.30 enables cross-origin reads of cluster topology, volume server URLs, gRPC ports, file identifiers, and directory listings from unauthenticated endpoints reachable in the default deployment configuration. The shared `writeJson` helper in `weed/server/common.go` concatenates the `callback` query parameter verbatim into `application/javascript` responses with no allowlist validation, no `X-Content-Type-Options: nosniff` header, and no CORS policy, allowing attacker-controlled pages to load these endpoints via script tags and receive cluster metadata through the injected callback. A public proof-of-concept exists; the vulnerability is not in CISA KEV; the CVSS 4.0 score of 2.3 reflects constrained direct impact due to required user interaction and high attack complexity, though the leaked reconnaissance data elevates chained-attack risk.
seaweedfs v3.68 was discovered to contain a SQL injection vulnerability via the component /abstract_sql/abstract_sql_store.go. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
Incorrect authorization in SeaweedFS S3 API's PutObjectAcl handler allows an authenticated low-privilege S3 principal to overwrite objects outside their permission scope. Versions prior to 4.40 compute the write-back directory from the bucket root rather than the actual parent directory of the nested key, meaning a principal scoped to `allowed/protected.txt` silently overwrites `protected.txt` at the bucket root - clobbering its content, metadata, owner, and ACL. No public exploit code identified at time of analysis, and this CVE is not listed in CISA KEV.
Incorrect path authorization in SeaweedFS SFTP server (versions 3.88-4.39) allows an authenticated low-privilege user to cross configured ACL boundaries and access or overwrite sibling tenants' files. The SFTP permission check used a bare string-prefix comparison, so a user scoped to /tenants/alice was also permitted access to any path beginning with those same characters - such as /tenants/alice-archive or /tenants/alice2 - without requiring a directory-component boundary. No public exploit code has been identified at time of analysis, though the public fix commit and advisory together fully document the vulnerable pattern, materially lowering exploitation difficulty for authenticated users.
Authorization bypass in SeaweedFS versions 4.39 and earlier allows authenticated federated users to assume IAM roles they are explicitly denied through the standard STS path. The S3 API's direct bearer token authentication path validates the OIDC JWT signature but skips trust policy enforcement, which the STS AssumeRoleWithWebIdentity path correctly applies. A federated user with a valid OIDC token can present it directly to the S3 API and obtain the mapped role's full S3 permissions - including object read, write, and delete - even when the role's trust policy explicitly rejects their identity provider. Version 4.40 patches the issue; no public exploit code has been identified at time of analysis.
SeaweedFS 4.39's TUS resumable-upload handler fails to re-validate JWT prefix scoping on HEAD, PATCH, and DELETE operations against existing sessions, enabling a low-privilege authenticated tenant to hijack cross-tenant upload sessions. An attacker holding a valid but restricted JWT token can PATCH arbitrary content into another tenant's in-progress upload by reusing the victim's session ID, causing the completed file to land at a filesystem path the attacker's token explicitly forbids. No public exploit has been identified at time of analysis; a vendor-released patch is available in version 4.40.
Server-side request forgery with response read-back in SeaweedFS distributed storage (versions prior to 4.24) lets anyone able to reach a volume server's gRPC port coerce the server, via the unauthenticated VolumeServer.FetchAndWriteNeedle RPC, into fetching arbitrary attacker-chosen URLs and returning the response. Because the volume server gRPC plane is unauthenticated by default and the documented JWT hardening does not cover this RPC, an unauthenticated remote attacker (CVSS:3.1 AV:N/PR:N, base 9.3) can reach loopback, RFC 1918, link-local, and cloud metadata endpoints such as 169.254.169.254 to steal IAM credentials and pivot to internal services. No public exploit identified at time of analysis, and it is not in CISA KEV; the fix landed in version 4.24.
Cross-tenant authorization bypass in SeaweedFS filer JWT path authorization allows any authenticated tenant to read and write data belonging to sibling tenants whose path names share a string prefix. Versions prior to 4.24 are affected: a scoped JWT issued for /tenant1 inadvertently passes the authorization check for /tenant1234, /tenant1-old, and any other path that begins with the same character sequence, because the check used Go's raw strings.HasPrefix rather than a path-component boundary comparison. No public exploit code has been identified at time of analysis, but the bypass is mechanically trivial for any holder of a valid scoped token and the exact attack patterns are documented in the fix's test suite.
Authentication bypass in SeaweedFS filer before 4.24 exposes the SeaweedIdentityAccessManagement gRPC service without any credential check whenever jwt.filer_signing.key is left unset, which is the default. Any client able to reach the filer's gRPC port can invoke CreateUser, CreateAccessKey, PutPolicy, and related IAM RPCs to mint their own access keys and obtain S3 administrative control over the storage cluster. Rated CVSS 9.8; no public exploit identified at time of analysis, though the upstream fix commit and PR are public.
Cross-tenant object deletion in SeaweedFS before 4.34 lets an authenticated S3 principal holding write access to just one bucket destroy arbitrary objects in other tenants' buckets through the S3 gateway's DeleteMultipleObjectsHandler. By embedding ../ sequences in object keys inside the DeleteObjects XML request body, an attacker exploits a confused-deputy gap where path validation never inspected body keys. Publicly available exploit code exists (reported by VulnCheck) and a vendor patch shipped in release 4.34; the flaw is not listed in CISA KEV.
Cross-bucket read/write in SeaweedFS before 4.30 lets remote attackers escape a bucket's namespace because the S3 API gateway and the Iceberg REST catalog gateway build their gorilla/mux routers with SkipClean(true), letting a literal '..' segment survive routing before downstream path joins collapse it server-side. A request like 'GET /bucket-A/../evil-bucket/key' is routed as bucket=bucket-A but resolves to evil-bucket, allowing an actor to read or write objects in buckets they should not reach. There is no public exploit identified at time of analysis; the issue is fixed in 4.30 via PR #9687.
Unvalidated JSONP callback reflection in SeaweedFS before 4.30 enables cross-origin reads of cluster topology, volume server URLs, gRPC ports, file identifiers, and directory listings from unauthenticated endpoints reachable in the default deployment configuration. The shared `writeJson` helper in `weed/server/common.go` concatenates the `callback` query parameter verbatim into `application/javascript` responses with no allowlist validation, no `X-Content-Type-Options: nosniff` header, and no CORS policy, allowing attacker-controlled pages to load these endpoints via script tags and receive cluster metadata through the injected callback. A public proof-of-concept exists; the vulnerability is not in CISA KEV; the CVSS 4.0 score of 2.3 reflects constrained direct impact due to required user interaction and high attack complexity, though the leaked reconnaissance data elevates chained-attack risk.
seaweedfs v3.68 was discovered to contain a SQL injection vulnerability via the component /abstract_sql/abstract_sql_store.go. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.