In late 2025, a critical authentication bypass vulnerability, CVE-2025–68926, was disclosed in RustFS, an open-source object storage solution. The vulnerability was assigned a CVSS v3.1 score of 9.8 (Critical) and originates from a structural design flaw in which a static authentication token was hardcoded directly into the source code. Due to this flaw, an attacker who can access RustFS's exposed gRPC management port can bypass authentication entirely and gain administrative access without valid credentials. Given that RustFS is commonly used to store backups, logs, and operational data, exploitation of a single vulnerability can directly lead to data integrity violations and service disruption.

This report analyzes the technical root cause of the hardcoded credential vulnerability in RustFS, outlines realistic attack scenarios, and examines how internet-exposed storage services can be abused as part of an expanded attack surface.

Overview of the Vulnerability and Attack Potential

  • Vulnerability ID: CVE-2025–68926
  • Affected Product: RustFS
  • Vulnerability Type: Hardcoded Credential (CWE-798)
  • CVSS v3.1 Score: 9.8 (Critical)
  • Impact: Authentication bypass, administrative access

RustFS internally relied on a non-rotatable static authentication token that was hardcoded on both the client and server sides. This token was identical across all RustFS deployments and could not be modified through configuration. As a result, once the token value became publicly known through source code repositories or public vulnerability analysis, any RustFS instance — regardless of deployment environment — became immediately accessible to an attacker.

This architecture exemplifies the inherent risks of hardcoded credentials: when authentication secrets are embedded in code, cannot be rotated, and are not managed by operators, credential disclosure equals full service compromise. The risk is further amplified when RustFS's gRPC-based management interface is exposed to the network, significantly lowering the attack barrier.

Realistic Attack Use Cases

None

Following public disclosure of the vulnerability, the attack scenario unfolds in a relatively straightforward manner. An attacker first identifies externally exposed RustFS gRPC services through internet-wide scanning. The attacker then obtains the hardcoded static authentication token from publicly available source code or vulnerability analysis materials and uses this token to authenticate to the gRPC port while impersonating a legitimate user.

Once authenticated, the attacker gains the ability to invoke management and storage-related APIs. This level of access enables administrative operations such as reading, modifying, or deleting object data, changing access control policies, and altering cluster configurations. In environments where RustFS is used to store backup or production data, such an attack can escalate beyond a simple service compromise, resulting in data loss and operational disruption, significantly amplifying the overall impact.

RustFS Systems Exposed to the Internet: Criminal IP Observations

Criminal IP Search Query: title: "RustFS"

None

As a result of the search, a total of 252 RustFS instances were observed to be identifiable and accessible via the public internet. These cases were confirmed through HTTP(S) responses indicating the presence of RustFS services, with the instances distributed primarily across China (108), Thailand (86), the United States (17), Germany (8), and Hong Kong (7).

None

In this case, the instance returned an HTTP 200 response on TCP port 443 (HTTPS). The <title> value and resource paths confirmed that the RustFS web console (/rustfs/console) was externally accessible. Further inspection showed that RustFS static management UI resources were being served via nginx 1.14.1, with no apparent network-level access restrictions. This demonstrates how a service designed for internal storage management can unintentionally become a publicly observable attack surface.

When combined with structural authentication flaws such as CVE-2025–68926, mere network accessibility becomes the decisive factor in exploitability.

Patch Progress and Defensive Actions

CVE-2025–68926 has been confirmed to be fixed in RustFS version 1.0.0-alpha.78, released on December 30, 2025. In this patch, the hardcoded static authentication token used in the gRPC authentication process was removed, and the authentication logic was modified. Related details can be verified through the official RustFS GitHub release notes and security advisories.

  • Affected Versions: RustFS alpha.13 ~ alpha.77
  • Patched Version: 1.0.0-alpha.78 (Released on December 30, 2025)

Detailed technical information and specific fixes related to the patch can be found in the official RustFS GitHub release notes and security advisories.

If applying the official patch is difficult or if updates are delayed, the following temporary mitigation measures are required:

  • Immediate update to the latest RustFS version is recommended
  • Block or restrict external access to the gRPC management port
  • Review authentication-related settings and token management mechanisms
  • Continuously monitor API access logs and abnormal activity

Due to the nature of hardcoded credential vulnerabilities, if a pre-patch version remains externally accessible, immediate exploitation is possible regardless of authentication controls. Therefore, network isolation and version upgrades should be prioritized.

Conclusion

CVE-2025–68926 demonstrates how a fundamental security design flaw, hardcoded credentials, can lead to critical consequences in core infrastructure such as object storage systems.

Organizations using RustFS or operating externally accessible storage services should go beyond simply applying patches and also review externally identifiable assets and service exposure status. From a threat intelligence perspective, combining vulnerability information with externally observed data can serve as an important criterion for assessing real-world attack feasibility.

For reference, readers may also consult the article on the MongoBleed (CVE-2025–14847): Critical Memory Leak in MongoDB and ASM-Based Mitigation