RustFS CVE-2026-46685

Three concurrent conditions must hold. First, RUSTFS_CORS_ALLOWED_ORIGINS must be unset on the target deployment (default state per the vendor description) - deployments with this variable explicitly configured are not vulnerable regardless of the value. Second, the victim's browser must hold ambient credentials for the RustFS origin in one of the three specific forms described by the vendor: saved HTTP Basic Auth credentials stored by the browser for that host, a reverse-proxy SSO or session cookie scoped to the RustFS origin, or a TLS client certificate that the browser will automatically present to that origin. Victims who have never authenticated to the target RustFS instance via a browser cannot be exploited. Third, the victim must be induced to load a page under attacker control while those credentials are active (UI:P per CVSS 4.0). CVSS PR:N confirms the attacker requires no prior account or privileges on the RustFS server itself. Exploitation is bounded by the AT:P condition: environments where RustFS is accessed only by programmatic S3 clients (SDKs, CLI tools, server-side code) with no browser-mediated authentication flow are not exploitable through this vector, as no ambient browser credentials will exist.

The CVSS 4.0 score of 6.0 accurately reflects a moderate but conditionally high-impact vulnerability. The vector AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:L/VA:N describes a network-reachable, low-complexity attack that nevertheless carries two significant mitigating prerequisites: AT:P (the victim must have active ambient credentials for the RustFS origin in their browser) and UI:P (the victim must visit an attacker-controlled page). The high confidentiality impact (VC:H) is well-founded - successful exploitation yields full read access to cross-origin S3 object responses. No EPSS score was provided in the input data, precluding quantitative exploitation-probability assessment. The vulnerability is not listed in CISA KEV and no public POC exploit code has been identified, indicating this is not a mass-exploitation scenario at present. Real-world risk is highest for organizations that expose RustFS to internal or semi-trusted networks where users authenticate via browser-cached HTTP Basic Auth or SSO cookies, and where social-engineering lures are plausible (e.g., phishing emails to employees). The tag 'Authentication Bypass' is partially misleading: this is not a bypass of RustFS's own authentication mechanism but rather a bypass of the browser's same-origin policy, which serves as an implicit cross-origin access control boundary. The CVSS integrity impact of VI:L is plausible if the attacker can issue state-changing S3 API calls (e.g., DELETE or PUT) cross-origin, though the primary demonstrated risk is confidentiality.

An attacker registers a convincing domain and hosts a page containing a few lines of JavaScript that call fetch('https://storage.target.internal/sensitive-bucket/confidential.pdf', {credentials: 'include'}) and POST the response body to an attacker-controlled collection endpoint. The attacker sends a phishing link to an employee who previously authenticated to the internal RustFS instance via a reverse proxy SSO portal, leaving a session cookie scoped to the RustFS origin in their browser. When the employee visits the malicious page, the browser - observing the reflected Origin and Access-Control-Allow-Credentials: true headers from the unpatched RustFS server - forwards the SSO cookie and exposes the response to the attacker's JavaScript, completing silent exfiltration. No public POC code has been identified; however, the attack requires only standard Fetch API calls available in any modern browser.