CVE-2026-116016 in yudao-cloud
Summary
by MITRE • 10/24/2026
yudao-cloud through 2026.09 contains an authorization bypass vulnerability that allows authenticated users to evade row-level data scope restrictions by sending a data-permission-enable header set to false. Attackers can add this header to /admin-api requests, which DataPermissionRpcWebFilter trusts, to read or modify other departments' and users' records within the same tenant.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/24/2026
The vulnerability identified in yudao-cloud versions up through 2026.09 represents a critical failure in server-side access control mechanisms, specifically targeting row-level data security policies. This flaw allows authenticated users to bypass granular permissions designed to restrict data visibility based on organizational hierarchy or departmental boundaries. The core technical issue stems from the improper validation of client-supplied headers within the application's request filtering layer. Specifically, the DataPermissionRpcWebFilter component is configured to trust a custom header named data-permission-enable without sufficient integrity checks or server-side verification against the user's actual privilege level. By manipulating this header and setting its value to false, an attacker can effectively disable the row-level security filters that would normally restrict access to records belonging to other departments or users within the same tenant context.
From a technical perspective, this vulnerability is classified under CWE-285, which describes Improper Authorization, specifically manifesting as a failure to enforce proper restrictions on authenticated users regarding data scope. The attack vector relies on HTTP header manipulation, where the client injects malicious parameters into standard administrative API requests directed at /admin-api endpoints. Because the application framework processes these headers before applying security policies, the presence of the disabled flag causes the system to skip critical authorization checks for subsequent database queries or resource accesses. This bypass is particularly dangerous because it does not require privilege escalation in terms of user roles; a low-privileged authenticated user can leverage this flaw to access high-sensitivity data that should be strictly isolated by business logic rules.
The operational impact of this vulnerability is severe, leading directly to unauthorized information disclosure and potential integrity violations within multi-tenant environments. Attackers who exploit this flaw can read confidential records belonging to other departments or individual users, violating privacy regulations such as GDPR or HIPAA depending on the data type involved. Furthermore, if write operations are similarly affected by the disabled permission filter, attackers could modify or delete critical business data owned by others within the same tenant. This undermines the fundamental isolation guarantees expected in SaaS applications and enterprise resource planning systems built on this framework, potentially leading to significant financial loss, reputational damage, and regulatory penalties for the organization hosting the application.
In terms of threat modeling, this vulnerability aligns with MITRE ATT&CK technique T1078, Valid Accounts, as it leverages legitimate credentials but abuses their permissions through logic flaws rather than credential theft. It also relates to T1530, Data from Cloud Storage Object, in scenarios where the data scope bypass leads to exfiltration of stored information outside authorized boundaries. The exploitation is straightforward and does not require complex chaining with other vulnerabilities, making it a high-risk issue that can be automated by threat actors scanning for misconfigured authorization headers.
To mitigate this vulnerability, immediate remediation efforts should focus on hardening the DataPermissionRpcWebFilter logic to ensure that data permission settings are derived exclusively from server-side state or secure session attributes rather than trusting client-supplied HTTP headers. Implementing a whitelist approach for allowed header values and enforcing strict validation rules can prevent unauthorized toggling of security features. Additionally, developers should adopt a defense-in-depth strategy by verifying row-level permissions at the database query layer using parameterized queries with explicit tenant isolation checks, ensuring that even if application-layer filters are bypassed, the underlying data access remains restricted according to policy. Regular code audits focusing on authorization logic and automated testing for broken object level permissions (BOLA) can further reduce the risk of similar flaws in future releases.