CVE-2025-68926

RustFS is a distributed object storage system built in Rust. In versions prior to 1.0.0-alpha.78, RustFS implements gRPC authentication using a hardcoded static token "rustfs rpc" that is publicly exposed in the source code repository, hardcoded on both client and server sides, non-configurable with no mechanism for token rotation, and universally valid across all RustFS deployments. Any attacker with network access to the gRPC port can authenticate using this publicly known token and execute privileged operations including data destruction, policy manipulation, and cluster configuration changes. Version 1.0.0-alpha.78 contains a fix for the issue.

RustFS is a distributed object storage system built in Rust. In versions prior to 1.0.0-alpha.78, RustFS implements gRPC authentication using a hardcoded static token "rustfs rpc" that is publicly exposed in the source code repository, hardcoded on both client and server sides, non-configurable with no mechanism for token rotation, and universally valid across all RustFS deployments. Any attacker with network access to the gRPC port can authenticate using this publicly known token and execute privileged operations including data destruction, policy manipulation, and cluster configuration changes. Version 1.0.0-alpha.78 contains a fix for the issue.

Vulnerability Overview

Description

RustFS implements gRPC authentication using a hardcoded static token "rustfs rpc" that is:

1. Publicly exposed in the source code repository
2. Hardcoded on both client and server sides
3. Non-configurable with no mechanism for token rotation
4. Universally valid across all RustFS deployments

Any attacker with network access to the gRPC port can authenticate using this publicly known token and execute privileged operations including data destruction, policy manipulation, and cluster configuration changes.

CVSS 3.1 Score

Score: 9.8 (Critical) Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

• Attack Vector (AV): Network - Exploitable remotely
• Attack Complexity (AC): Low - No special conditions required
• Privileges Required (PR): None - No authentication needed (bypassed)
• User Interaction (UI): None - Fully automated exploitation
• Scope (S): Unchanged - Impact contained to vulnerable component
• Confidentiality (C): High - Complete data disclosure
• Integrity (I): High - Complete data modification capability
• Availability (A): High - Complete service disruption capability

Vulnerable Code Analysis

Server-Side Authentication (rustfs/src/server/http.rs:679-686)

#[allow(clippy::result_large_err)]
fn check_auth(req: Request<()>) -> std::result::Result<Request<()>, Status> {
    let token: MetadataValue<_> = "rustfs rpc".parse().unwrap();  // ⚠️ HARDCODED!

    match req.metadata().get("authorization") {
        Some(t) if token == t => Ok(req),
        _ => Err(Status::unauthenticated("No valid auth token")),
    }
}

Issues:

• Static token hardcoded as string literal
• No configuration mechanism (environment variable, file, etc.)
• Token visible in public GitHub repository
• Identical across all installations

Client-Side Authentication (crates/protos/src/lib.rs:153-174)

pub async fn node_service_time_out_client(
    addr: &String,
) -> Result<NodeServiceClient<...>, Box<dyn Error>> {
    let token: MetadataValue<_> = "rustfs rpc".parse()?;  // ⚠️ SAME HARDCODED TOKEN!

    // ...

    Ok(NodeServiceClient::with_interceptor(
        channel,
        Box::new(move |mut req: Request<()>| {
            req.metadata_mut().insert("authorization", token.clone());
            Ok(req)
        }),
    ))
}

Issues:

• Client uses identical hardcoded token
• No secure token distribution mechanism
• Token cannot be rotated without code changes

Service Integration (rustfs/src/server/http.rs:520-521)

let rpc_service = NodeServiceServer::with_interceptor(make_server(), check_auth);
let service = hybrid(s3_service, rpc_service);

The check_auth interceptor is applied to all gRPC services via NodeServiceServer::with_interceptor, protecting all 50+ gRPC methods in node.proto with the same weak authentication.

Reproduction Steps

Environment Setup

Test Environment:

• RustFS Server: localhost:9000 (HTTP + gRPC hybrid service)
• RustFS Console: localhost:9001
• Container: rustfs/rustfs:latest (Docker Compose deployment)
• Default credentials: rustfsadmin/rustfsadmin

Tools Required:

• grpcurl v1.9.3+ (gRPC command-line client)
• RustFS proto files: crates/protos/src/node.proto

Step 1: Verify Authentication is Enforced

Test 1.1: Request without authentication token

$ grpcurl -plaintext \
    -import-path /private/tmp/rustfs/crates/protos/src \
    -proto node.proto \
    -d '{}' \
    localhost:9000 node_service.NodeService/Ping

Expected Result: ✅ Authentication failure

ERROR:
  Code: Unauthenticated
  Message: No valid auth token

Test 1.2: Request with incorrect token

$ grpcurl -plaintext \
    -H 'authorization: wrong-token-12345' \
    -import-path /private/tmp/rustfs/crates/protos/src \
    -proto node.proto \
    -d '{}' \
    localhost:9000…

RustFS is a distributed object storage system built in Rust. In versions prior to 1.0.0-alpha.78, RustFS implements gRPC authentication using a hardcoded static token "rustfs rpc" that is publicly exposed in the source code repository, hardcoded on both client and server sides, non-configurable with no mechanism for token rotation, and universally valid across all RustFS deployments. Any attacker with network access to the gRPC port can authenticate using this publicly known token and execute privileged operations including data destruction, policy manipulation, and cluster configuration changes. Version 1.0.0-alpha.78 contains a fix for the issue.

RustFS is a distributed object storage system built in Rust. In versions prior to 1.0.0-alpha.78, RustFS implements gRPC authentication using a hardcoded static token "rustfs rpc" that is publicly exposed in the source code repository, hardcoded on both client and server sides, non-configurable with no mechanism for token rotation, and universally valid across all RustFS deployments. Any attacker with network access to the gRPC port can authenticate using this publicly known token and execute privileged operations including data destruction, policy manipulation, and cluster configuration changes. Version 1.0.0-alpha.78 contains a fix for the issue.

Vulnerability Overview

Description

RustFS implements gRPC authentication using a hardcoded static token "rustfs rpc" that is:

1. Publicly exposed in the source code repository
2. Hardcoded on both client and server sides
3. Non-configurable with no mechanism for token rotation
4. Universally valid across all RustFS deployments

Any attacker with network access to the gRPC port can authenticate using this publicly known token and execute privileged operations including data destruction, policy manipulation, and cluster configuration changes.

CVSS 3.1 Score

Score: 9.8 (Critical) Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

• Attack Vector (AV): Network - Exploitable remotely
• Attack Complexity (AC): Low - No special conditions required
• Privileges Required (PR): None - No authentication needed (bypassed)
• User Interaction (UI): None - Fully automated exploitation
• Scope (S): Unchanged - Impact contained to vulnerable component
• Confidentiality (C): High - Complete data disclosure
• Integrity (I): High - Complete data modification capability
• Availability (A): High - Complete service disruption capability

Vulnerable Code Analysis

Server-Side Authentication (rustfs/src/server/http.rs:679-686)

#[allow(clippy::result_large_err)]
fn check_auth(req: Request<()>) -> std::result::Result<Request<()>, Status> {
    let token: MetadataValue<_> = "rustfs rpc".parse().unwrap();  // ⚠️ HARDCODED!

    match req.metadata().get("authorization") {
        Some(t) if token == t => Ok(req),
        _ => Err(Status::unauthenticated("No valid auth token")),
    }
}

Issues:

• Static token hardcoded as string literal
• No configuration mechanism (environment variable, file, etc.)
• Token visible in public GitHub repository
• Identical across all installations

Client-Side Authentication (crates/protos/src/lib.rs:153-174)

pub async fn node_service_time_out_client(
    addr: &String,
) -> Result<NodeServiceClient<...>, Box<dyn Error>> {
    let token: MetadataValue<_> = "rustfs rpc".parse()?;  // ⚠️ SAME HARDCODED TOKEN!

    // ...

    Ok(NodeServiceClient::with_interceptor(
        channel,
        Box::new(move |mut req: Request<()>| {
            req.metadata_mut().insert("authorization", token.clone());
            Ok(req)
        }),
    ))
}

Issues:

• Client uses identical hardcoded token
• No secure token distribution mechanism
• Token cannot be rotated without code changes

Service Integration (rustfs/src/server/http.rs:520-521)

let rpc_service = NodeServiceServer::with_interceptor(make_server(), check_auth);
let service = hybrid(s3_service, rpc_service);

The check_auth interceptor is applied to all gRPC services via NodeServiceServer::with_interceptor, protecting all 50+ gRPC methods in node.proto with the same weak authentication.

Reproduction Steps

Environment Setup

Test Environment:

• RustFS Server: localhost:9000 (HTTP + gRPC hybrid service)
• RustFS Console: localhost:9001
• Container: rustfs/rustfs:latest (Docker Compose deployment)
• Default credentials: rustfsadmin/rustfsadmin

Tools Required:

• grpcurl v1.9.3+ (gRPC command-line client)
• RustFS proto files: crates/protos/src/node.proto

Step 1: Verify Authentication is Enforced

Test 1.1: Request without authentication token

$ grpcurl -plaintext \
    -import-path /private/tmp/rustfs/crates/protos/src \
    -proto node.proto \
    -d '{}' \
    localhost:9000 node_service.NodeService/Ping

Expected Result: ✅ Authentication failure

ERROR:
  Code: Unauthenticated
  Message: No valid auth token

Test 1.2: Request with incorrect token

$ grpcurl -plaintext \
    -H 'authorization: wrong-token-12345' \
    -import-path /private/tmp/rustfs/crates/protos/src \
    -proto node.proto \
    -d '{}' \
    localhost:9000…