Skip to content

GHSA-pfcq-4gjr-6gjm CVE-2026-40937

RustFS: Missing admin authorization on notification target endpoints allows unauthenticated configuration of event webhooks

High crates.io
Severity
8.3 / 10
High · CVSS 3.1
Exploit chance (EPSS)
0.29%
Chance of exploitation in the next 30 days. Higher than 21.88% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-862 Missing Authorization
Fix
None yet
No fixed version published

Description

Missing Admin Auth on Notification Target Endpoints in RustFS

Finding Summary

All four notification target admin API endpoints in rustfs/src/admin/handlers/event.rs use a check_permissions helper that validates authentication only (access key + session token), without performing any admin-action authorization via validate_admin_request. Every other admin handler in the codebase correctly calls validate_admin_request with a specific AdminAction. This is the only admin handler file that skips authorization.

A non-admin user can overwrite a shared admin-defined notification target by name, causing subsequent bucket events to be delivered to an attacker-controlled endpoint. This enables cross-user event interception and audit evasion.

What Was Proven Live
  1. Authorization bypass on all four endpoints (03_readonly_user_bypass.py)

    • PUT, GET list, GET arns, DELETE all return 200 for readonly-user
    • Control routes (list-users, kms/status) correctly return 403
    • Unauthenticated requests correctly rejected (403 Signature required)
  2. SSRF via health probe (04_ssrf_listener_landing.py)

    • HEAD request from rustfs container to attacker-controlled listener
    • No host validation: only scheme check (http/https)
  3. Target hijacking and event exfiltration (05_target_hijacking.py, 06_full_event_exfil.py)

    • Readonly-user overwrites admin-configured target URL by name
    • Subsequent S3 events delivered to attacker-controlled endpoint
    • Captured event body includes object keys, bucket names, user identities, and request metadata
  4. Audit evasion (05_target_hijacking.py)

    • Readonly-user can delete unbound targets
    • Readonly-user can overwrite bound targets (silently redirecting events)
Escalation Vectors Tested But Not Viable
  1. Self-referencing webhook to admin API (13_self_referencing_test.py)

    • Webhook sends unsigned POST with event JSON body
    • Admin endpoints require SigV4 auth -- unsigned request rejected
    • "Confused deputy" via self-referencing does NOT work
  2. Protocol smuggling via non-HTTP targets

    • Only 2 target types implemented: webhook and MQTT (event.rs:613 enforces this)
    • No Redis, Kafka, AMQP, or other protocol targets exist
    • CRLF injection in webhook config fields sanitized by reqwest
    • MQTT uses rumqttc (pure Rust binary protocol client), no raw TCP injection
  3. MQTT target for RCE

    • No unsafe code in MQTT handler
    • rumqttc 0.29.0 has no known public CVEs
    • No Command::new, template engines, or deserialization of broker responses
  4. Unauth access

    • Endpoints correctly reject unauthenticated requests (403)
    • Endpoints correctly reject invalid credentials (403)
Prior Art

No existing advisory covers notification target endpoints. 11 published GHSAs on rustfs/rustfs cover different handlers. Closest:

  • CVE-2026-22042 (ImportIam wrong action constant) -- same bug class, different file
  • CVE-2026-22043 (deny_only short-circuit) -- different bug class
Recommendation

Submit via GitHub PVR. The finding is well-supported with live PoC, code references, and clear root cause. The fix is straightforward (add validate_admin_request calls to event.rs handlers). Core submission should reference 2-3 focused PoC scripts (readonly bypass, target hijack, event exfil), not the full set of 13 exploratory scripts.

Koda Reef

Patch

This issue has been patched in version https://github.com/rustfs/rustfs/releases/tag/1.0.0-alpha.94.

Affected versions

crates.io

PackageVulnerableFixed in
rustfs
<= 0.0.2
No fix yet

How to fix

No fixed version has been published yet. Until one is, remove or replace the package, or turn off or isolate the affected feature. This page updates when a fix ships.

Severity breakdown

CVSS 3.1 8.3

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

Attack vector
Network
Attack complexity
Low
Privileges required
Low
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
Low

Weakness

CWE-862: Missing Authorization

The product does not perform an authorization check when an actor attempts to access a resource or perform an action.

How to prevent it
  • Architecture and Design: Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
  • Architecture and Design: Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
  • Architecture and Design: Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
  • Architecture and Design: For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page. One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
  • System Configuration, Installation: Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.

References

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-mm2q-qcmx-gw4w
RustFS: ListServiceAccount authorizes against wrong admin action, enabling cross-user enumeration and root service account takeover
High Also affects rustfs
GHSA-mx42-j6wv-px98
RustFS has an authorization bypass in multipart UploadPartCopy enables cross-bucket object exfiltration
Medium Also affects rustfs
GHSA-v9fg-3cr2-277j
Rust has Critical Stored XSS in Preview Modal, leading to Administrative Account Takeover
Medium Also affects rustfs
GHSA-w5fh-f8xh-5x3p
RustFS: Missing Post Policy Validation leads to Arbitrary Object Write
Critical Also affects rustfs
GHSA-r54g-49rx-98cr
RustFS Logs Sensitive Credentials in Plaintext
High Also affects rustfs
GHSA-fc6g-2gcp-2qrq
RustFS has SourceIp bypass via spoofed X-Forwarded-For/Real-IP headers
High Also affects rustfs
GHSA-333v-68xh-8mmq
RustFS's RPC signature verification logs shared secret
High Also affects rustfs
GHSA-xgr5-qc6w-vcg9
RustFS has IAM deny_only Short-Circuit that Allows Privilege Escalation via Service Account Minting
Critical Also affects rustfs
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor