CVE-2026-101048 in Cloudreve
Summary
by MITRE • 09/27/2026
Cloudreve before 4.17.0 registers the administrative node test endpoints (POST /api/v4/admin/node/test and POST /api/v4/admin/node/test/downloader) without requiring the Admin.Write OAuth scope, unlike the node create/update/delete routes. An OAuth client that has been authorized by an administrator with only the Admin.Read scope can therefore submit attacker-controlled node definitions and cause the Cloudreve server to issue outbound requests to arbitrary URLs, enabling blind server-side request forgery, internal service probing, and delivery of signed Cloudreve slave-style requests to attacker-chosen endpoints.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/27/2026
The vulnerability identified in Cloudreve versions prior to 4.17.0 represents a critical authorization bypass within the administrative node management subsystem. Specifically, the API endpoints POST /api/v4/admin/node/test and POST /api/v4/admin/node/test/downloader fail to enforce the Admin.Write OAuth scope required for modifying system configurations. This inconsistency stands in stark contrast to other administrative routes such as create, update, or delete operations which correctly restrict access based on write privileges. Consequently, an attacker possessing only the minimal Admin.Read scope can exploit this misconfiguration to trigger server-side network actions without elevated permissions.
From a technical perspective, the flaw allows for blind Server-Side Request Forgery (SSRF). By submitting controlled node definitions through these test endpoints, an authenticated user with read-only privileges forces the Cloudreve application server to initiate outbound HTTP requests to arbitrary URLs specified by the attacker. This mechanism bypasses standard access controls because the underlying code treats these specific test functions as safe for lower-privilege contexts or fails to validate the required OAuth scope before executing network I/O operations. The vulnerability effectively transforms a read-only administrative account into a vector for internal reconnaissance and external exploitation.
The operational impact of this flaw is severe, primarily due to its potential for blind SSRF and internal service probing. Attackers can leverage these outbound requests to scan internal networks, identify vulnerable services running on private IP addresses or localhost interfaces that are not exposed to the public internet, and potentially interact with metadata endpoints such as those found in cloud environments like AWS EC2 or Google Cloud Platform. Furthermore, because the vulnerability allows for signed Cloudreve slave-style requests to be delivered to attacker-chosen endpoints, it may facilitate further compromise of distributed storage nodes if they trust incoming connections from the main server without sufficient verification of intent or origin beyond basic authentication checks.
This issue aligns with CWE-269 Improper Privilege Management and CWE-918 Server-Side Request Forgery (SSRF). In terms of offensive security frameworks, it maps to ATT&CK technique T1557 Adversary-in-the-Middle or T1046 Network Service Discovery depending on the specific exploitation path taken. The lack of consistent OAuth scope enforcement across related administrative functions highlights a systemic design flaw in how privilege boundaries are defined and enforced within the application logic.
Mitigation strategies must prioritize immediate upgrading to Cloudreve version 4.17.0 or later, where this authorization gap has been addressed by enforcing strict Admin.Write requirements for all node-related operations including testing configurations. In environments where an upgrade is not immediately feasible, network-level controls such as web application firewalls should be configured to restrict outbound connections from the server IP address to only known and necessary destinations. Additionally, implementing egress filtering rules that block access to internal RFC1918 addresses can significantly reduce the risk of successful internal service probing via this SSRF vector until a permanent patch is applied.