
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.
Vulnerability Overview and Attack Feasibility
- 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.
Attack Scenarios

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.
Internet-Exposed RustFS Assets Observed via Criminal IP
To assess real-world exposure, we analyzed externally reachable RustFS instances using service-identification queries tailored to RustFS characteristics.
Criminal IP Search Query: title: “RustFS”

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).

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 Status and Mitigation
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.
FAQ
Q1. Why was CVE-2025-68926 (RustFS hardcoded credential vulnerability) rated CVSS 9.8?
CVE-2025-68926 includes a structural flaw in which a hardcoded static authentication token was used during the gRPC authentication process in RustFS, and this token was valid across all deployment environments. As a result, attackers can access administrative functions without creating an account or performing additional authentication. If network access is possible, attackers can perform administrator-level operations such as deleting object data, modifying policies, and manipulating cluster configurations. Due to these characteristics, the vulnerability received a CVSS 9.8 (Critical) score, reflecting its high remote exploitability, low attack complexity, and broad impact.
Q2. Is applying the patch sufficient for the RustFS vulnerability? Why is Attack Surface Management (ASM) necessary?
Updating to RustFS 1.0.0-alpha.78 or later is a mandatory requirement for addressing CVE-2025-68926. However, if externally accessible instances running older versions remain, pre-patch environments may still be targeted. Therefore, it is important to accurately identify RustFS usage within the organization and verify whether any instances are externally accessible.
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 Remote Code Execution Vulnerability in the n8n Workflow Automation Platform (CVE-2025-68613).
In addition, by requesting a demo through the button below, users can directly review threat intelligence (TI) analysis of externally exposed assets and a Criminal IP demo.
This report is based on data from Criminal IP, a Cyber Threat Intelligence search engine. Sign up for a free Criminal IP account today to explore the search results mentioned in the report and delve into comprehensive threat intelligence.
Source: Criminal IP (https://www.criminalip.io/), NIST National Vulnerability Database(https://nvd.nist.gov/vuln/detail/CVE-2025-68926), The Hacker News(https://thehackernews.com/2026/01/threatsday-bulletin-rustfs-flaw-iranian.html), RustFS GitHub Releases(https://github.com/rustfs/rustfs/releases)
Related Article: https://www.criminalip.io/knowledge-hub/blog/31847

