CVE-2026-80346 in StarRocks
Summary
by MITRE • 08/26/2026
StarRocks performs no privilege check when a legacy synchronous materialized view is dropped. Every other statement type routed through AuthorizerStmtVisitor calls into Authorizer before execution, but visitDropMaterializedViewStatement returns immediately with a comment stating the check happens in execution logic. That holds only for asynchronous materialized views: LocalMetastore.dropMaterializedView calls Authorizer.checkMaterializedViewAction inside a branch taken when the resolved table is a MaterializedView. A legacy synchronous materialized view is stored as a rollup index on an OlapTable rather than a MaterializedView, so the other branch runs, reaching AlterJobMgr.processDropMaterializedView and MaterializedViewHandler, neither of which contains any Authorizer call. The former locates the target by scanning every OlapTable in the named database for a matching rollup index, and the latter validates only table state and name conflicts. Any authenticated account can therefore drop a legacy synchronous materialized view belonging to any database, holding no grant on the view, the base table or the database, and the drop is indistinguishable from an authorized one.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/26/2026
The vulnerability in StarRocks represents a critical authorization bypass within its query execution engine, specifically affecting the handling of legacy synchronous materialized views. This flaw stems from an inconsistency in how privilege checks are applied across different statement types processed by the AuthorizerStmtVisitor class. While most statements routed through this visitor correctly invoke the Authorizer component prior to execution, the logic for dropping a materialized view contains a significant oversight. The visitDropMaterializedViewStatement method returns immediately after parsing, relying on an internal comment that claims authorization checks are deferred to the execution phase. This design assumption holds true only for asynchronous materialized views, where the LocalMetastore.dropMaterializedView function explicitly calls Authorizer.checkMaterializedViewAction when it identifies the target object as a MaterializedView instance. However, this safety mechanism fails completely for legacy synchronous materialized views due to their distinct internal storage architecture and subsequent processing path.
Legacy synchronous materialized views in StarRocks are not stored as independent MaterializedView objects but rather as rollup indexes attached to an underlying OlapTable. Consequently, when a drop operation is initiated against such a view, the system does not recognize it as a standalone materialized view entity during the initial resolution phase. Instead of following the branch that triggers the authorization check for asynchronous views, the execution flow enters an alternative path designed for standard table alterations. This path leads to AlterJobMgr.processDropMaterializedView and subsequently MaterializedViewHandler. Neither of these components contains any invocation of the Authorizer class or checks for user permissions. The process primarily focuses on locating the target rollup index by scanning all OlapTables within the specified database and validating basic constraints such as table state and name conflicts, completely ignoring access control policies.
The operational impact of this vulnerability is severe, allowing any authenticated account to drop legacy synchronous materialized views belonging to databases or tables for which they hold no privileges whatsoever. An attacker with minimal read-only access can execute a DROP MATERIALIZED VIEW statement against targets owned by other users or administrative accounts without triggering any denial errors. The unauthorized deletion proceeds indistinguishably from an authorized operation, leaving no specific audit trail that differentiates it from legitimate maintenance activities performed by privileged administrators. This lack of distinction complicates forensic analysis and incident response efforts, as the system logs do not flag these events as potential security violations based on permission mismatches.
This flaw aligns with CWE-269, which describes Improper Privilege Management, specifically where a user is able to perform actions beyond their assigned permissions due to flawed access control logic. Furthermore, it relates to CWE-862, the Missing Authorization check, as the execution path for this specific statement type fails to verify that the actor has the necessary rights before proceeding with destructive operations. From an ATT&CK perspective, this vulnerability facilitates lateral movement and privilege escalation within a database environment by allowing unauthorized modification of schema objects. It can also be classified under data destruction techniques if used maliciously to remove critical analytical structures.
To mitigate this risk, immediate patching is required to ensure that the drop operation for legacy synchronous materialized views routes through the same authorization verification logic as asynchronous views or standard table drops. The Authorizer component must be invoked before AlterJobMgr.processDropMaterializedView executes any destructive changes. Additionally, developers should review other statement types in the visitor pattern to identify similar gaps where execution logic assumes prior validation that does not occur for all object types. Implementing comprehensive unit tests that cover privilege checks for both synchronous and asynchronous materialized views will help prevent regression of this issue. Regular security audits focusing on authorization paths for DDL operations are also recommended to maintain robust access control integrity across the database engine.