CVE-2026-72524 in Doris
Summary
by MITRE • 09/14/2026
Incorrect Authorization vulnerability in Apache Doris allows an authenticated user to bypass privilege checks and access or modify data they are not authorized to.
This issue affects Apache Doris: from 3.1.0 through 3.1.*, from 4.0.0 through 4.0.7, and from 4.1.0 through 4.1.3.
Users are recommended to upgrade to a fixed release (4.0.8 or 4.1.4), which fixes the issue.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/14/2026
The vulnerability identified in Apache Doris represents a critical failure in access control mechanisms, specifically categorized under CWE-269: Improper Privilege Management. This flaw allows an authenticated user to bypass standard privilege checks, thereby gaining unauthorized access to or modification capabilities for data resources that should be strictly restricted based on their assigned roles and permissions. In the context of distributed SQL databases like Apache Doris, which are often deployed in enterprise environments handling sensitive business intelligence and analytics workloads, such a breach undermines the fundamental principle of least privilege. The attacker does not need to exploit complex memory corruption or injection flaws; rather, they leverage logical errors within the authorization layer to execute operations that should be rejected by the system's security policy.
From an operational perspective, this vulnerability poses severe risks to data integrity and confidentiality. An adversary with low-level access could potentially exfiltrate sensitive customer information, alter critical analytical datasets leading to incorrect business decisions, or even disrupt service availability through destructive modifications. The impact is amplified in multi-tenant environments where different departments or external partners share the same Doris cluster but are expected to have isolated data views. If authorization checks can be bypassed, the isolation boundaries between these tenants collapse, potentially violating regulatory compliance requirements such as GDPR, HIPAA, or SOX which mandate strict access controls and auditability of data interactions.
The technical root cause likely resides in how Apache Doris evaluates user permissions against requested operations during query execution or metadata management tasks. While specific implementation details may vary depending on the version, typical scenarios for this class of vulnerability involve race conditions, insufficient validation of session context, or flawed logic in role-based access control (RBAC) enforcement modules. The ATT&CK framework maps this behavior to techniques such as T1078: Valid Accounts and potentially T1546: Event Triggered Execution if the bypass allows for persistent backdoors, though primarily it aligns with unauthorized privilege escalation or lateral movement within the database layer itself. Attackers can exploit this by crafting specific queries that trigger the flawed authorization logic, effectively tricking the system into treating an unprivileged user as having higher clearance levels.
This vulnerability affects multiple recent releases of Apache Doris, specifically versions from 3.1.0 through 3.1.*, and from 4.0.0 through 4.0.7, as well as 4.1.0 through 4.1.3. These ranges indicate that the flaw has persisted across several minor updates, suggesting a systemic issue in the core authorization engine rather than an isolated bug introduced in a single patch cycle. Organizations running these versions are at immediate risk if they allow external or internal users to connect directly without additional network-level restrictions or proxy-based filtering.
To mitigate this vulnerability, organizations must prioritize upgrading their Apache Doris instances to version 4.0.8 or later, with specific recommendation for version 4.1.4 and above where the issue has been resolved. Immediate action is required as automated exploitation tools may emerge rapidly once public details are confirmed. In addition to patching, administrators should review existing user roles and permissions to ensure that no unnecessary broad privileges have been granted while waiting for upgrades. Implementing strict network segmentation to limit database exposure to only trusted application servers can also reduce the attack surface. Furthermore, enabling comprehensive audit logging is crucial post-upgrade to monitor for any anomalous access patterns that might indicate prior exploitation of this flaw before the patch was applied. Regular security assessments and penetration testing focused on authentication and authorization flows should be integrated into the development lifecycle to prevent similar logical flaws in future releases.