GHSA-pfcq-4gjr-6gjm CVE-2026-40937
RustFS: Missing admin authorization on notification target endpoints allows unauthenticated configuration of event webhooks
- 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
-
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)
-
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)
-
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
-
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
-
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
-
Protocol smuggling via non-HTTP targets
- Only 2 target types implemented: webhook and MQTT (
event.rs:613enforces 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
- Only 2 target types implemented: webhook and MQTT (
-
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
-
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
| Package | Vulnerable | Fixed 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
Advisories
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why 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 |
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