What is the CVSS score of CVE-2026-55189?

CVE-2026-55189 has a CVSS 3.1 base score of 7.7 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N. EPSS exploitation probability: 0.2%.

Which versions of RustFS are affected by CVE-2026-55189?

RustFS versions 1.0.0-alpha.1 through pre-beta.9 contain an authorization bypass in the FTP listener that allows authenticated users to access any data in configured buckets, bypassing their IAM…

How to fix or mitigate CVE-2026-55189?

Within 24 hours: Inventory RustFS deployments running versions 1.0.0-alpha.1 through pre-beta.9 with FTP listener enabled; disable FTP listener if operationally feasible. Within 7 days: Audit FTP listener access logs for unauthorized activity; verify no unintended data exposure occurred; confirm IAM policies are correctly enforced. Within 30 days: Monitor RustFS vendor advisory channels for patch release; plan and test upgrade to patched version once available.

RustFS CVE-2026-55189

EUVD-2026-39864 HIGH

Missing Authorization (CWE-862)

2026-06-26 GitHub_M

Authentication Bypass Rustfs

7.7

CVSS 3.1 · Vendor: GitHub_M

Severity by source

Vendor (GitHub_M) PRIMARY

7.7 HIGH

AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N

vuln.today AI

7.7 HIGH

Requires an authenticated FTP login (PR:L) over the network; bypassing the IAM authorization boundary is a scope change (S:C) with read-only data exposure (C:H, I:N, A:N).

3.1 AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N

4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (GitHub_M).

CVSS VectorVendor: GitHub_M

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Changed

Confidentiality

High

Integrity

None

Availability

None

Lifecycle Timeline

Analysis Generated

Jun 26, 2026 - 20:35 vuln.today

DescriptionCVE.org

RustFS is a distributed object storage system built in Rust. From 1.0.0-alpha.1 until 1.0.0-beta.9, when the FTP frontend is enabled, the FTP read and probe handlers dispatch directly to the storage backend without ever calling the IAM authorization function that the FTP write/list handlers (and the entire HTTP S3 path) use. As a result, any user who can authenticate to the FTP listener - including a user whose IAM policy contains an explicit Deny on s3:GetObject - can read (RETR) and stat (SIZE/MDTM) any object in any bucket, and probe any bucket (CWD), completely regardless of their IAM policy. This vulnerability is fixed in 1.0.0-beta.9.

AnalysisAI

Authorization bypass in RustFS (1.0.0-alpha.1 through pre-beta.9 builds) lets any user able to authenticate to the optional FTP listener read and stat arbitrary objects in any bucket, even when their IAM policy explicitly Denies s3:GetObject. The FTP read/probe handlers (RETR, SIZE, MDTM, CWD) dispatch straight to the storage backend and skip the IAM authorization check enforced everywhere else, breaking tenant/object isolation. There is no public exploit identified at time of analysis, no CISA KEV listing, and no EPSS score was provided.

Technical ContextAI

RustFS is a distributed, S3-compatible object storage system written in Rust. Beyond the HTTP S3 API it exposes an optional FTP frontend so clients can interact with stored objects over FTP. Normally every data-plane operation funnels through a central IAM authorization function that evaluates the caller's policy (Allow/Deny on actions such as s3:GetObject). This flaw is a CWE-862 Missing Authorization: the FTP write and list handlers and the entire HTTP S3 path correctly invoke that IAM check, but the FTP read handler (RETR) and probe handlers (SIZE, MDTM for stat; CWD for bucket existence) call the storage backend directly without it. The CPE cpe:2.3:a:rustfs:rustfs:*:*:*:* confirms the affected component is the RustFS application itself across the alpha/beta release line up to 1.0.0-beta.9.

RemediationAI

Vendor-released patch: upgrade RustFS to 1.0.0-beta.9, which adds the missing IAM authorization call to the FTP read and probe handlers. If you cannot upgrade immediately, the most effective compensating control is to disable the FTP frontend entirely and serve data only over the HTTP S3 path, which already enforces IAM (trade-off: any legitimate FTP-based workflows break and must move to S3 clients). Where FTP must stay enabled, restrict network access to the FTP listener to trusted hosts and tightly control who holds FTP credentials, recognizing that this only narrows-does not close-the bypass, since any authenticated FTP user can still read denied objects. Refer to the advisory at https://github.com/rustfs/rustfs/security/advisories/GHSA-3g29-xff2-92vp for details.